Making the Business Case for Agility

Overview
Gather a bunch of agile practitioners in a room, and the conversation quickly turns to lively theoretical discussions and war stories. Yes, it is truly energizing to be around like-minded people, and we know this stuff really does work. But enthusiasm and anecdotes alone don't carry much weight when trying to convince executive-level management that transitioning to agility would be a good move.

Why Don't They Get It?
We miss opportunities to properly position agility when we try to appeal to senior management with the wrong type of information. We live and breathe the ground-level principles and practices of agility every day, but people in these positions are more likely to be measured according to (and thus, preoccupied with) things that leave them impatient with our explanations of agile concepts, project management frameworks, and engineering practices. When approached with such low-level information, the case for agility often comes across about as convincingly as a child's justification as to why she "needs" a pony. If we hope to be successful in promoting agility to people in the higher levels of an organization (whose support we'll most certainly need), we have to be able to articulate, in straightforward terms, why an agile approach to software delivery makes good business sense.

Review the Basics
Generally speaking, the production of anything involves the conversion of some kind of input into an output that is valuable to someone. An investment is made in raw materials, they are input to a transformation process, and the output is sold to customers who find value in it.

In software development, we don't transform iron ore into steel, or steel into beams. We take ideas and transform them into software that somehow represents the essence of those ideas and allows access to those ideas via features, so that people can manipulate them in ways that benefit them. We have to be careful when comparing software development to manufacturing, but I don't think it is a stretch to treat the ideas as the raw materials, the cost involved with bringing an idea to the state that it can enter the transformation process as the Investment, and the expense incurred in transforming that idea into a functioning feature as Operating Expenses, and the resulting working feature set, IF it provides valuable benefits to the customer, as Sales. This view is consistent with Throughput Accounting theory.

Spend Less, Make More, and Make it More Often
Although a lengthy discussion of Throughput Accounting and Achieved Value (versus "Earned Value") is beyond the scope of this post, the business argument for agility really is founded on these bodies of thought. In my view, the key points as they apply to what we're talking about here boil down to these:

• Work in progress, no matter how "complete", only represents an expense, and is of no value to a customer.
• Until something is sold, all we've done is spend money.
• Shorter cycle times facilitate decreases in Investment and Operating Expenses, and increases in Sales.

We know that reductions in Investment and Operating Expenses, together with an increase in Sales will result in increased Net Profit and Return on Investment. We've also seen that, in software development, expenditures associated with eliciting and preparing ideas for transformation into features constitute our Investment, the costs of transforming those ideas into features are Operating Expenses, and that Sales presumably result when we make valuable benefits available to our customers. In order to maximize the financial performance of the software development organization, then, we can draw some very direct conclusions:

• We should minimize expenditures associated with preparing ideas for input into the transformation process, as this will minimize our Investment.
• We should minimize the amount of partially-completed work that accumulates in association with a particular deployable set of features, as this will serve to minimize our Operating Expenses.
• We should produce what the customers actually value; otherwise, we won't have any Sales.
• We should maximize our opportunities to deliver our product, since Sales can only happen then.

The Connection
Getting to this point hasn't required us to invoke any agile terminology. We haven't even used the word "agile". All we've done is cite some basic relationships between Investment, Operating Expenses, and Sales, relate them to a high-level view of the economics of software development, and draw some obvious conclusions. The theory certainly runs deeper than what we've looked at here, but the proposition of making the software development organization more financially successful sets the stage for the discussion of specific agile principles and practices, and why they make sense. For example, it is much easier to propose lightweight requirements documentation, backlog prioritization, and the concept of "Last Responsible Moment" when it is understood that the real objective in doing so is to limit Investment. Similarly, it can be shown that cross-functional teams, limiting work to capacity, and continuous integration introduce system efficiencies that minimize partially-completed work, thus reducing Operating Expenses. And making the case for achieving "Done" in short iterations becomes a less arduous task when it is understood that the underlying rationale is to increase Sales.

And so...
The principles that are woven throughout the various agile frameworks and engineering practices have the effect of limiting Investment and Operating Expenses and producing revenue-generating value frequently, so that the organization can maximize its opportunities to realize Sales against a minimized investment with minimal operating expenses. That is the real message that needs to be conveyed to senior-level management. By establishing the proper business context, we can lay a foundation upon which we can build an agile organization and gain some powerful allies in the process.