kHUB All Member Forum

 View Only

Save Agile - Stop Waterfall Planning

By Robert Webber posted 09-30-2022 15:21

  
Idea Generation in 21st Century


Read time:
5 minutes

Waterfall Planning


My last article on business predictability asserts that we in software development are at a disadvantage relative to sales and manufacturing because we can’t define our output in terms of value that the business understands. Would you believe me if I told you that there is a way that you can quantify the financial value of software increments below the release level and above the feature level? Stick with me.

I came up with a way after thinking really hard about how to assign “Cost of Delay (CoD)” to software. I will explain CoD in more detail in a future article but suffice it to say that it’s basically the profit or income lost by delaying a software release by one month. CoD was introduced in Don Reinertsen’s classic book, The Principles of Product Development Flow: Second Generation Lean Product Development. It’s a great book that models software development as a series of queues. Don’s keynote at the 2013 Construx Software Leadership on CoD changed my life.

The concept is brilliant. However, I wasn’t aware of anyone who had implemented it. And most clients hadn’t heard of it. How could this be? Reinertsen showed that prioritizing software projects by what he called “Weighted Shortest Job First (WSJF)”, which is CoD divided by cycle time, optimizes software development ROI. It was free money! Then I realized the implementation challenges.

The first challenge was the inability to associate income with software increments smaller than the large releases still being put out with waterfall planning, despite Agile development. Planning still starts with a mound of features of questionable value targeted for a release.

I turned the problem on its head. Let’s define the smallest increment of software that can generate revenue or reduce operational expenses as an "Agile Investment." Such an increment has a CoD by definition. Everything we do in software development should directly or indirectly provide a positive return on software. That’s the reason that software development organizations exist. “Software Value” now means income, which the business understands.

For example, a software release to enter a new market would be an “Investment.” Or a modular increment of software that could be priced and released separately would be an “Investment.” The term "Investment" was used to remind software development that they don't do software projects. They provide value that returns profit for the business.

The Agile Investment planning hierarchy looks like this:



Investment backlogs can be associated with virtual P&L centers comprised of cross-functional product teams that plan potentially deployable software increments to maximize WSJF. The smaller the increment, the shorter the cycle time, and the higher the WSJF. Scope creep? Backlog priority goes down as cycle time increases unless the requested functionality can be justified with a higher income forecast. Finally, a financial consequence for demanding new features that add little or no value. It’s now a different conversation with your business stakeholders. The Minimum Marketable Feature Set (MMFS) emerges because of the incentive to minimize development cycle time.

You can establish innovative virtual product teams formed around financial value without having to reorganize. Teams are no longer taking feature orders. They are creating business value. Managing to WSJF gives the business that financial predictability they have always been after. Teams can vary feature content and functionality as long as financial targets are met. And software productivity now accounts for the value side, instead of focusing on widgets per hour.

Teams plan for Investments to be released independently to maximize WSJF because cycle time includes deployment time in this model. Releases of bundled Investments are discouraged. In most cases, companies are still defining releases first and then stuffing them with features, despite adopting Agile development. I realized that if we continue to start planning with release assumptions, large releases will always exist, constraining the value of Agile development. Plan value, and view releases as a problem to solve. In fact, you can now calculate the opportunity costs of releases – the total cost of delay of completed Investments waiting for release. I call it the “Cost of not being Agile.”

Technical debt? It never got the respect from the business anticipated by calling it a “debt.” Surely, the business will want to retire debt! It doesn’t work that way. The business determines what to build next by where they get the greatest return on their investment. Now Technical debt Investments can be associated with income so they can be prioritized against business Investments based on WSJF. Turns out that it’s difficult to justify technical debt retirement based on efficiency improvement. Retire technical debt that reduces cycle time to reduce the total CoD of your Investment backlog. You can equate technical debt reduction with future income that the business understands.

Don Reinertsen’s Construx software leadership summit talk was the start of my journey. There were lots of details to work out, like how to practically calculate CoD for the typical S-curve income profile. And, how to establish income targets for the business based on target payback periods. I reviewed my methods with Construx clients over the years to ensure that WSJF prioritization is practical. My background as a VP of product management and CEO enabled me to relate the principles to business planning frameworks. The result is my recently published book, Unleashing Agile’s Missed Potential.

Now I’m on a mission to replace feature-level waterfall planning with Agile Investment Planning to enable Agile development the way it was conceived – empowered teams given the time to build software that delights customers. In waterfall development, under fixed schedules and content, we ended up building what customers would finally accept. Agile has the potential to deliver value beyond what customers can imagine.

Author: Bob Webber

Related Content

#product-management
#agile
#cost-of-delay
#investment-planning
#softwaredevelopment
​​​​
#ProductInnovationProcess​​

0 comments
38 views

Permalink