One of the hyped benefits of agile software development practices is increased productivity. It is also the benefit that I am most skeptical of. Software productivity is notoriously difficult to measure. That is because there are no relatively standard units of measurement of output. Martin Fowler said this in 2003, and as far as I can tell it is still relatively correct. This is true regardless of whether you are using agile practices or not. In fact, the measurement of software output itself is an expensive activity, so in any normal case study it would be hard to prove. Since books have been written on this topic, I do not feel the need to delve deeper into this topic, except to say that all of the problems described in Fred Brooks’ famous Mythical Man Month still exist today, and there has not been a universally adopted solution.
Nevertheless, I am not totally willing to call bullsh*t on the productivity benefit. There are three completely anecdotal reasons for this:
1) Agile practices tend to focus less on documentation and more on producing working software. This leads to spending less time on speculative documentation that ends up being revised many times. Rather than guessing what users want, agile teams build it as quickly as possible, and get feedback, and revise it, until it IS WHAT THE CUSTOMER WANTS! So from a productivity perspective, it is less work to deliver what the customer wants, not what they thought they wanted or what we thought they wanted. Is this real measurable productivity? NO – but it sure as hell feels good to both the developer and the customer.
2) The shorter measurement cycles that agile favors help resources focus on the needful, rather than the fanciful. This means that developers are focused on working in the next feature. Management theories put forth by Elliot Jacques talk about time span – the individuals ability to plan into the future. Developers typically do not a have long time span. I have often experienced developers who became overwhelmed trying to figure out what order to work in, and ended up being unproductive or paralyzed by unscoped tasks. The rhythm of consistent pacing, tends to allow the team to relax around planning, because there are regular intervals of planning activity, broken by longer periods of uninterrupted development. Is this real measurable productivity? NO – but the developers will tell you that they are able to relax and focus on solving technical problems rather than worrying about deadlines and planning.
3) The agile principle YAGNI (Ya Ain’t Gonna Need It) reduces the investment in complex architecture, or over-engineered solutions, or premature optimization. The principle is less about improving the productivity of individuals, and more about improving the output of the team. It is a principle that allows the team to hold itself accountable to deliver the smallest, thinnest, cheapest version of each capability, rather than the most ornate, most performant, most scalable, most beautiful version. Agile principles direct us to deliver an acceptable solution with the least effort, rather than an acceptable solution that anticipates all future events. Is this real measurable productivity? NO – but as I learned early in my career – the best way to get more done is to figure out all the things that don’t need to be done and not do them.
When I evaluate these reasons, I recognize that the perceived increase in productivity may be much greater than any actual increase, but at the same time, perceived increase in productivity can improve morale and reputation in ways that by themselves lead to real increases in productivity. Agile life cycle projects often feel less like a “death march” than gated life cycle projects, and that alone can lead to increased productivity and motivation.