The Development Team is Not the Center of the Universe

After doing Agile development for a while, we eventually hit a wall where to make further improvements the scope of work addressed within the Agile initiative needs to be extended.

Extend the agile development team to include additional roles. This approach has distinct limitations.

  1. Agile work groups that depend on high collaboration to produce effective results must remain fairly small in size.
  2. 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 throughout 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.

Coordinate incremental contributions from non-developers such as business analysts. 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 ourselves to do effective global optimization rather than local optimization.

The difficult part is that the scope of the 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 can’t 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.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.