The Agile Executive

A measure frequently considered by executives these days is the introduction of Agile as part of cost reduction initiatives. To succeed in attaining cost benefits through the higher productivity of Agile, the plan for introducing it needs to take into account the slippery slope that repeated cost cutting measures tend to lead to. In particular, the timing of rolling out Agile and the duration of the roll-out need to be carefully considered to avoid a possible cart-before-horse situations.

A cart-before-horse situation is likely to arise as a result of the following pattern:

1. An executive’s budget is under pressure.
2. Headcount reduction is carried out. Remaining employees are expected to somehow cope with the load.
3. Agile, with its promise of higher productivity and possibly hyper-productivity, is introduced as a counter-measure to the reduced headcount.
4. The remaining development resources are expected to acquire a new set of skills, to master the art of Agile.
5. The need to acquire Agile skills flies at the teeth of remaining employees needing to regain expertise that was lost by reduction in headcount. In many cases, the remaining development resources are already stretched too thin.
6. Staring at the choice between acquiring specific domain expertise in a critical area versus developing less concrete expertise in software methods, more often than not the remaining employees and the system around them will opt to concentrate on acquiring domain expertise. For example, if a product fails to satisfy a new security benchmark introduced by key customers, the need to respond to the security benchmark is likely to take precedence over studying estimation techniques for Agile.
7. Goto #1 above.

To preempt such cart-before-horse situation, the following principles need to be adhered to:

1. Don’t introduce Agile before “the system” adequately adjusted to a round of headcount reduction.
2. Do not carry out layoffs during the assimilation phase of Agile. In addition to cart-before-horse situation as described above, headcount reduction could jeopardize two critical pillars of Agile: empowerment and collaboration.
3. Establish a quantified baseline of productivity before starting an Agile roll-out. Measure Agile progress against the baseline.
4. Do not bet the Agile roll-out on linear improvement in productivity. A good Agile implementation is likely to improve productivity, but it is quite tricky to predict the shape of the Agile learning curve.

In practical terms, your organization needs to take a strong “medicine” up-front to break the vicious cycle that repeated staff reductions amidst an Agile roll-out are likely to create. The medicine should be strong enough to last through the period of time required for a meaningful assimilation of Agile. A good way to assess how long the period might be is to consider Agile as apprenticeship – one learns by “Agiling” with the masters.

You need to ask yourself the question “Can We Afford the Software We are Developing?” if business circumstances do not allow for reasonable adherence to the principles cited above.