This is a journey that began in 2011 when I started a second career as a product development consultant. I wanted to leave behind the pressure of delivering software products and transition to a role that would allow me more time flexibility to pursue my interests. I wouldn't change anything in my first career. It provided me with a perspective from the engineering and business side to solve a software industry problem – the missed expectations of Agile development.

I would never have become a consultant if it wasn't for Steve McConnell, an icon of software engineering. I had read his books and admired how he updated proven software engineering practices for the current generation of software developers. I became a client of Steve's training and consulting company, Construx Software.

When I decided to leave the corporate treadmill, Construx was the only company for which I wanted to consult. Steve let me determine how I could best contribute and gave me the flexibility to focus on my interests. It gave me the opportunity to apply my knowledge and experience to help software companies build higher value software and release it faster. It also provided me with insight into what was really going on in Agile, and it wasn't the Agile I was reading about in books.

This was a period when everyone was “going Agile.” I saw larger companies stumble when they tried to apply a simplistic Scrum model designed for small organizations. Product development organizations had the biggest challenges. Where is the product owner who knows everything about everything in an international organization with a complex domain and diverse customers? And how can engineering do real Agile development when product management plans large releases with fixed schedules stuffed with features?

My consulting assessments always pointed out that organizations were not really doing Agile. A basic tenet of Scrum is that teams have time to incorporate feedback and correct defects during sprint development. Instead, teams were still driven by imposed schedules and barely had time to create basic functionality. Teams were demotivated from continually missing schedules. Sprints were not “potentially shippable.” Defects mounted up during sprints which led to major rework in a “hardening sprint.” Engineers were feature implementors instead of providing innovative solutions to problems conveyed to them in user stories and epics.

The value of releasing faster seemed obvious. Why did these organizations continue to use traditional Waterfall release planning methods with fixed schedules and content? Waterfall planning hadn't ever achieved the predictability they sought. How did they think that Agile roadmap commitments could be made prior to requirements development given that requirements were allowed to change?

Companies continue to use Waterfall planning because they are forced to make multiyear financial commitments. The sales organization needs to know the products and features they can sell before they will commit to revenue. And projects need financial justification based on delivery schedule and content commitments. Internal operations groups must budget with the expectation of increased productivity dependent on new features. Agile didn't address these issues. The somewhat flippant response of the Agile community was, “The business needs to be more Agile.” Even though Waterfall planning leaves a lot to be desired in terms of predictability, it is the only way product managers know how to plan.

Some companies implemented the SAFe Agile framework to integrate business planning and Agile development. However, SAFe just institutionalized feature‐based Waterfall planning. Product managers liked it because they didn't have to change the way they planned large releases at the feature‐level. SAFe included an option for Lean Canvas planning but is not widely used in larger organizations. It's difficult to get funding approved for market experimentation. The business wants to see the releases and features they are paying for before funding development.

I've experienced a few epiphanies in my career. One occurred at the annual Construx software leadership summit in 2011 that influenced this book. Donald Reinertsen, author of The Principles of Product Development Flow [1], was a keynote speaker. His book presents a queue‐based model of software development analogous to manufacturing organizations. The book includes a concept that can potentially change the way software is planned. It's called “Cost of Delay.”

Cost of Delay is a simple yet elegant perspective of the software development process: “How much more money would you make if you could release your software one month earlier?” Reinertsen went on to show that prioritizing projects based on something called, “Weighted Shortest Job First” (WSJF), would optimize income. WSJF is the Cost of Delay divided by the project cycle time. It essentially says that companies make more money when they limit functionality and release and earn income faster. I recognized that WSJF can facilitate the mythical “Minimum Marketable Feature Set” (MMFS) advocated by Agile. I say mythical because sales organizations refused to compromise on functionality. They wanted anything and everything that could possibly lead to a sale in any country.

Thus began the journey to this book. Cost of Delay and WSJF were great concepts, but they were not widely adopted. Companies found it difficult to calculate Cost of Delay for non‐linear post‐release income profiles. Reinertsen's formula works for linear income profiles with constant income per month. I recognized that WSJF had to be simplified and product managers need to have methods and tools to simplify the calculations for any income profile.

My conclusion was that most companies have not achieved the potential of Agile because they are not really doing Agile the way it was envisioned. They are still trying to force‐fit Agile into a Waterfall planning framework. This book enables these organizations to reap the benefits of their investments in Agile development by incorporating Agile planning and deployment. It also lets larger organizations replicate the powerful dynamics of a startup instead of the divisiveness and friction I observed between product management and engineering. The book describes how larger organization can build collaborative Agile product teams.

There is one other major influence that helped shape my solution. Tom Gilb has a long history of contributing to the software industry in the areas of software metrics, software inspections, and evolutionary development processes. Tom gave a talk on stakeholder value analysis at Construx in 2011. His method provides a way to dig down to what users really want before getting into requirements detail. It was the perfect fit for my proposed approach to Agile planning.

I want to thank Steve McConnell for his patience and support for this journey. Steve is a deep thinker who kept me on track by challenging many of my assertions. His philosophy of hiring smart people and letting them figure out how they can best contribute gave me the freedom to pursue my ideas. I also had the benefit of stimulating collaborations with other Construx consultants. Steve's recent book, More Effective Agile [2], is a useful and practical guide for engineering leaders that complements my work.

Don Reinertsen's book and principles provided the foundation for this new approach for Agile planning. He is an inspirational speaker with the analytical mind of an electrical engineer. I had the pleasure of talking to Don about some of my ideas at the Construx leadership summit he attended two years after his first talk. I highly recommend reading, The Principles of Product Development Flow. WSJF was a way to illustrate the value of reducing cycle time. The book contains much more. He goes on to show how cycle times can be drastically reduced by managing queues that build up in software development.

I have one other person to thank – my wife, Susan. In addition to being a great partner and mother, her PhD in Psychology and experience in leading change at high‐tech companies gave me insight into the “soft” side of software development that needs to be addressed to realize the full potential of Agile. We can put all the procedures and processes in place, but little happens without human motivation. This book explains how Agile can create high‐performance self‐directed teams, yet how it has been squandered by the constraints and controls from traditional development, especially those driven by the perpetuation of Waterfall planning.

And, of course, I want to thank Susan for infinite patience and support for the years I've spent developing and refining the Investment approach.

References

1. 1 Reinertsen, D.G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
2. 2 McConnell, S. (2019). More Effective Agile: A Roadmap for Software Leaders. Construx Press.