AgileEstimationScrumSoftware estimation

So … Does agile improve productivity?

Over the past fifteen to twenty years I’ve been invited numerous times to help organization move from traditional to iterative and agile software development. Without exception whenever I have a first board room meeting at any organization, I start the conversation with the same questions: why do you want to move to agile? What is it you are trying to achieve?

You wouldn’t believe the diversity of answers I’ve received from CEO’s, CIO’s, CTO’s, managers and project managers. Apparently, agile is conceived as the silver bullet to solve all of our problems. Almost automagically collaboration between people will improve, teams and projects will deliver the right functionality on-time, on-budget and without financial overruns. Of course, quality of design and code will improve on the fly, collaboration with the business, clients and other stakeholders will appear to be perfect, bugs will disappear without effort, testing in agile projects is a jiffy, and in the end everybody’s happier than the Minions in Pharrell Williams song.

But above all, the issue agile is supposed to solve is that the productivity of software development needs to improve. It seems that organizations automatically assume that just by going agile, Scrum, Kanban or similar approaches more software will be built in less time.

There is a number of observations to make from this assumption. First of all, I seriously doubt that any approach, agile or from other paradigms will actually improve productivity. I remember that the same assumption was coined before with model driven development, component based development, offshore development and rapid application development. Productivity isn’t only influenced by the mere application of any approach, but also by the organization’s culture, the amount of requirements change, the knowledge and experience of the people in the teams, factors from outside of the projects, such as external parties and suppliers, or the complexity of the application landscape and architecture. Hence, the application of waterfall, agile, RUP, Scrum or Kanban as such only influences the increase or decrease of productivity for a very small part. Besides that, agile is applied differently in each and every organization and project, which makes it hard to come up with a generic statement on productivity improvement.

Teams are not factories

Secondly, developing software, including analysis and testing, is creative work. A software development team is not a factory. And creative work is not something which is easily measured. For every problem, no matter how small, there is a multitude of solutions available. Teams struggle and have to be inventive to find the best, or at least a good-enough solution, a usable user interface, a well-crafted domain model, a suitable service design. And estimating creative work, and moreover comparing creative work to that of others is always hard. It’s like someone asking Vincent van Gogh how long it will take him to paint his next masterpiece. And even worse, then trying to compare that to the time it took Rembrandt to paint The Night Watch. The fact that a software development project is for a large part creative work makes it hard to estimate it exactly – the project manager’s nightmare. But to use that estimate to compare it with the work done in traditional projects is even harder. People use different techniques, work in different styles, technology has changed dramatically. Again, it is like comparing Van Gogh’s Sunflowers to Rembrandt’s Night Watch, solely based on the amount of hours it took them to create their product.

The weakest links

Thirdly, the slowness of a software development project is only partly due to the actual development. Most of it can be directly attributed to endless changes in requirements and new insights from those who need the software. Every software development project, also the agile ones, have some sort of a life cycle of creating work items. Ideas are converted into requirements, requirements into features, features into user stories or use cases, next code is delivered, tests are done and eventually a product comes out. As we all know, every process is as strong as it’s weakest link. Many people involved in the weakest links in the process of any software development project are hard to influence, such as the business, external parties or even DBA’s. No matter how good agile techniques are, they only partly influence these weaker links in your process. Meaning agile only partly influences productivity anyway. On top of that, every software product is unique. In this industry we never build the same product twice. Why would we? It a product is there already, no need to build it again? And since every product is different, how can we compare different projects?

Apples and oranges

Last but not least, to really find out whether productivity is improving, agile projects and teams need to be measured and compared with traditional projects and teams. This alone is hard enough as it is. Many organizations haven’t actually measured their projects well in the past, and still aren’t measuring their (agile) projects. And even if they do, measurement in agile projects is usually achieved by establishing the number of story points that teams realize during iterations or sprints. Unfortunately, story points are hard to compare for different teams, as any team, even in the same project, may estimate differently, even using the same scale. Let alone that story points are comparable over different projects or different organizations. 

And even if we would be able to measure and compare agile projects using some point scale, traditional projects and teams, if they are measured at all, are usually not measured in story points, but using other techniques, such a different variations of function points or techniques such as COCOMO. These techniques hardly compare to story points. In other words, comparing the outcome and productivity of traditional and agile projects is much like comparing apples and oranges.

Value in agile

Concluding, I’d say there’s very little proof that going agile, Scrum, Kanban, Lean or whatever, will for sure improve your productivity in software development. At least I haven’t seen much proof. Not in literature, and not in real life. At best, agile might improve your productivity. But it might as well slow it down too. I’ve seen both cases – I think.

All in all, if you are turning to agile just to increase productivity, think twice. However, that doesn’t mean that you shouldn’t move to agile. There is a lot of value in agile. Besides productivity, there are plenty of reasons to engage in agile, although hard to prove as well. I’ve seen teams who improve the quality of their code, I’ve witnessed organizations who benefitted largely from increased the flexibility agile offers, I’ve seen people really happy to be able to collaborate with people in other roles whom they’ve never worked with before, I’ve seen growing mutual understanding between business and IT, I’ve seen people creating more pride in their work, and even regaining joy and confidence in working at their employers. All things you could benefits from when adopting agile practices. But do those benefits solely rely on agile? Nope. It’s you.