Interlude: The Cost of Agile

 

Agile software development requires significant long term investments in developer skill. Most “Agilists” choose not to talk about it.

I had just begun working on part four in my three part blog post series Are You Still Using the Wrong Control Levers in your Agile projects?, when I found myself writing a section about agile project economics. The section was rather long, and didn’t quite fit with the rest of part four, so I decided to break it out, and make it a separate blog post instead. This is it! I do hope you enjoy reading it.

In case you wonder why there are four parts (five if you count this interlude) in a three part blog post series, well, requirements changed, and the scope increased…

Agile methods have great benefits, both in human, and economic terms. There are also costs. Thus, going agile, if it is done seriously, requires thinking a bit about the trade-offs that must be made.

Most companies don’t consider the trade-offs. What they do is they set up an “Agile transformation program”, and make the assumption that the cost of the program is equivalent to the cost of going agile. It’s not even close! The costs are much higher than that. Unfortunately, since most companies don’t pay those costs, they don’t get the correspondingly great benefits either.

Scrum is intended to be a wrapper around agile software development practices. A large part of the economic benefits of using agile, comes from the software development practices.

For starters, nearly every organization that goes agile chooses to use Scrum, but Scrum is not a complete agile method. It’s just a thin communications wrapper around a team that uses agile software development practices. If you want agile performance, you must identify core agile software development practices, and train developers to use them.

For a company that uses a lot of consultants in its projects, this training cost will quickly get prohibitively high, which means to go agile, such a company must shift from using consultants to using full time employees. They will also invest a lot of money in training their employees. This means they will not be able to grow or shrink their staff as quickly as before. People become long term investments instead of short time investments.

On the up-side, the company will have well trained staff that is a lot more flexible than before, and that can be utilized for competitive advantage. It does require top management to unlearn the way they currently think about managing their company, and learn new ways.

Few managers are interested in going back to school, no matter how useful it potentially is. It is worth remembering, from their perspective, they will have no idea if all the new stuff they have to learn is useful until after they have learned it, and tried it out. Most will not even know they have to learn new stuff.

Every Agile Team has Economists Onboard…They Just don’t Know It!

Any software development team, agile or not, can be seen as an economic engine: The inputs are requirements and coffee. The output is software functionality that has value (positive or negative) for users.

Who does the work of maximizing the value of the output from the economic engine?

If you are using Scrum, and have read the Scrum Guide, you might think it is the Product Owner.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
— The 2020 Scrum Guide

Note the word “accountable”. What it means is that the Product Owner does not necessarily do the actual work. The Product Owner is just the one who has to justify various decisions to the powers that be. In most Scrum projects, the Product Owner does assign business value to items in the Product Backlog. That is then combined with time estimates from developers and the result determines the actual priority. The idea is to produce the maximum business value per time unit, usually a two week Sprint.

Thus, estimates made by the developers also have a lot of impact on the business value of the output.

However, the developers make other economic decisions, without the involvement of the Product Owner.

For example, it is the developers who decide how high the cost of adding, changing, or removing requirements will be!

Wait, what? How do the developers do that? The developers decide how complicated the code is. They decide whether the code will be tightly coupled, with many dependencies, or loosely coupled, with few dependencies. They decide whether classes and methods are easy to understand and work with, or whether developers will have to spend hours, days, weeks, or even more, understanding how a piece of code works, before they can change it.

The developers also decide whether changing a piece of code is a safe operation, or if it is dangerous, with a high probability of introducing new bugs each time the code is touched.

Good developers make these decisions very deliberately, and use various tools and programming techniques to implement the decisions. Other developers usually don’t think much about it. They just write the code they need to solve their immediate problem. Of course, there is a very wide range between the extremes I have described, and most developers are somewhere in-between. No matter where they are on the scale, and how they approach software development, developers make decisions that have economic impact many times each day they work.

We already know that requirements will change often. That is why we chose to use an agile method in the first place. Thus, the decisions made by developers while writing code will be an important cost driver, up, or down, depending on the decisions made.

Of course there are many things a developer may do, or not do, that has an economic impact. It would be nice though, if we could identify key drivers that have a lot of impact. Early agile methods did just that. For example, eXtreme Programming identified refactoring as a key economic driver:

Refactoring is a discipline of design that codifies these recurring patterns of changes. These refactorings can occur at any level of scale. Few design decisions are difficult to change once made. The result is systems that can start small and grow as needed without exorbitant cost.
— Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change (p. 90). Kindle Edition.

In 2003, Tom and Mary Poppendieck described agile methods in terms of project economics, and did a very good job of it. They too, identified refactoring as a key economic driver:

…refactoring is a key method for avoiding waste in providing business value to customers. A well-designed code base is the foundation of a system that can respond to the needs of customers both during development and throughout the useful life of the system.

— Poppendieck, Mary; Poppendieck, Tom. Lean Software Development (Agile Software Development Series) (pp. 144-145). Pearson Education. Kindle Edition.

When developers refactor code, they can easily break code that does work. Automated refactoring functionality in development tools does reduce this risk, but more is needed:

A key tool that goes hand in hand with refactoring, and in fact makes refactoring possible, is automated testing.
— Poppendieck, Mary; Poppendieck, Tom. Lean Software Development (Agile Software Development Series) (p. 145). Pearson Education.

The idea of using automated tests to make refactoring safe, came from eXtreme Programming:

Refactoring, [automated] unit testing, and immediate feedback as you code are now an integral part of our toolset. Moreover, since we are “eating our own dog food” we use these practices in our day-to-day development.
— Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change (p. 18). Pearson Education.

Over time, agile mutated from a set of methods for software development to much more generic ideas about managing projects. In order to make agile more generically applicable, things that were specific to software development were excised and forgotten (or killed off and buried in the back yard, depending on your point of view).

Because the agile economic model was dependent both on management practices (vertical slicing), and software development practices (refactoring, Test-Driven Design, iterative development) it didn’t fit with methods that focused exclusively with management.

None of my “modern” books about working as a Scrum Master, or Product Owner, mentions refactoring. Well, one of them mentions that it is a term that is too technical to use:

You should avoid technical actions, such as “I want to create a database” or “I want to refactor that nasty piece of code.” These technical actions are solution oriented and should be done instead as part of a separate, more business-oriented user story.
— Don, McGreal; Jocham Ralph. The Professional Product Owner: Leveraging Scrum as a Competitive Advantage (p. 197). Pearson Education. Kindle Edition.

Beyond that, refactoring is not mentioned again. None of my more recently written agile project management books has anything sensible to say about project economics, at least when it comes to modeling the internals of a development team, or system of teams.

Most of the material I have found, focuses on looking at teams from the outside, using things like Net Present Value (NPV) and Weighted Shortest Job First (WSJF).

The one exception I have seen, is SAFe:

With continuous refactoring, the useful life of an Enterprise’s investment in software assets can be extended as long as possible. Users can continue to experience a flow of value for years to come. Refactors enable an emergent design, ensuring the system continues to meet future business needs.
— SAFe 6, https://scaledagileframework.com/refactoring/

Then again, the SAFe refactoring article is considered an advanced topic, not fundamental to making agile methods work. Also, while the SAFe article describes both small and large scale refactoring, it seems biased towards large scale refactoring, while the original agile methods preferred to make refactoring a part of the everyday work routine. EXtreme Programmers do large refactorings too, but they are relatively rare. Small scale refactoring is done every time an eXtreme Programmers writes a method.

I have never, ever, seen an argument for discarding the fundamental practice of refactoring. Instead, agilists just stopped talking about it, and about the economic impact of agile software development practices. This made agile much easier to adopt (and easier to sell), but it also reduced its value.

On the upside, the few companies that are willing to take agile methods seriously, can gain significant advantages by reducing the cost of change during both development and maintenance, and extending product lifecycles. It does require investing in developer skills, and creating work environments where developers like to work.