Agile: Speeding up Technical Work Is not the Goal

Organizations are used to concentrating their technology workers in specialized units, such as IT or Product Development. This approach enables them to focus on their specialties and to establish their own methods and processes. As a side effect, it also creates a vendor-consumer dynamic. And once this dynamic is in place, managers on both sides start wondering, can the technical people work faster?

From a business standpoint, that’s a perfectly valid question. How can they produce more output for the same input? Where Waterfall is the reigning mind-set, managers look for efficiencies through standardization, automation, practice improvement, etc. Few notice their hidden assumption that the techies are working on the right things — the things most worth building.

Those managers are now hearing that they have another option: Agile. It’s being sold to them as The New Vehicle for Efficiency. Simple: just put a small cross-functional team together, remove some heavyweight process requirements, and give them a two-week deadline. They will churn out work faster, and show you progress on a regular basis.

This might have been a good way to get executives’ attention, but they’ve been sold on the wrong thing. Unlike Waterfall, Agile is a two-way relationship between the vendor and consumer (who is often represented by an internal authority). In healthy implementations, both sides don’t even think in terms of vendors and consumers; they see themselves as partners. Consider the four values at the foundation of the Agile mind-set:

People come first, before product and before process
Adaptation
Early and frequent value delivery
Customer collaboration

These values have nothing to do with efficiency or speed to completion. Rather, they are all about effectiveness: delivering what matters to the customer. In Agile, customer and developer collaborate toward an outcome that they both care about. They get there gradually, through early and frequent value delivery. They both assume that the outcome is not fully knowable and shouldn’t be determined up-front. If the outcome and the path to it are crystal clear and unchanging, the Agile path may be less efficient than a single pass.

Thus, adopting Agile in the name of efficiency or speed is risky business, because Agile is designed for something else — something which is fundamentally different and affects both parties. Both need to agree to use Agile, to embrace the same mind-set, and to apply it in a way that works for both. Otherwise, as many companies have discovered, all those sprints, standups, demos, user stories, and retrospectives make little business difference, and often create conflict and frustration.

This is not to say that Agile work is necessarily inefficient. Even though Agile does not ascribe the same importance to efficiency as it does to effectiveness, feedback, and embracing change, many Agile projects do turn out to be also faster and cheaper than their predictive counterparts. Unlike Waterfall, this doesn’t happen due to optimization at the team member and task level. It happens because the team starts fewer items, and what it does start it finishes quickly. Also, many teams have discovered that the self-imposed constraint of the small time-box forces them to produce simpler designs, incur less waste, and experience fewer nasty surprises.