Agile Business Analysis
Recently, a discussion emerged from the Beyond Agile community asking where business analysis and allied concerns such as user experience fit in an Agile development project. Should business analysts be sprinkled in the development team? Should a business analyst team be working a sprint or two ahead to feed the development team?
When we apply Agile techniques to a development project we eventually hit a wall where to make further improvements the scope of the work flow that somehow participates in the Agile initiative needs to be extended.
One idea is that the agile development group is extended to include additional roles. This approach has some distinct limitations.
- Agile work groups that depend on high collaboration to produce effective results must remain fairly small in size.
- To obtain hyper productivity cross-functional teams must have high cohesion. This generally means that they share a workstream that produces a single kind of output (e.g. software). However, as the cross-funtional domains become more disparate the ability or desire to do this diminishes. For example, a product marketer may contribute to a software project but really in most cases is not well positioned to develop software. Furthermore, while contributing to the software team, they are not doing product marketing, which means the organization loses something by having them join the team. If you try to remedy the problem by broadening the teams mission to producing software and product marketing, you dilute the teams ability to achieve a laser focus with the result of compromised productivity.
I believe that we need to encourage collaboration and share ideas broadly with the organization but I dont believe adding everbody to the team is the optimal or a viable long term solution.
I think we tend to go down this road because as developers we sometimes think our world is the center of the universe. In fact from a broad perspective the development team is almost never the center of the universe. One reason is that software is not business value. Yes in agile development we want delivery working software at the end of every iteration but working software is not business value. Software in production is not business value either. In most cases software participates in the conveyance of value but is not value itself. Typically software in production is part of a larger value stream. If we attempt to just optimize the software aspect of the value stream without consideration to the big picture, we may create bottlenecks elsewhere.
A different approach is to have corresponding iterations for business analysis etc. This is the right place to look for a long term solution but may be difficult to implement becuase it requires the cooperation of parties outside the development department.
At some point during our agile adoption program, we will recognize that to get further performance out of the development team something outside the team needs to change. The more we think of the software development team as part of a larger value stream, the more we start to position ourselve to do effective global optimization rather than local optimization.
The difficult part is that the scope of actual value stream is very likely outside the operational control of the IT or product development department. This means a broader discussion of how to optimize work across work teams needs to be opened up.
Agile development teams often find themselves acting as catalysts in organizations. By succeeding they introduce new classes of problems that when solved will help the overall organization make better decisions and increase throughput. However, they cant solve these problems alone. What we can do is anticipate the need to solve these problems and prepare our colleagues elsewhere in the organization to expect these problems to develop and be ready with practical incremental solutions that it will be easy for them to say yes to because they can easily see how the benefit from their local perspective.