Read time: 3 minutes
I’ve often heard complaints from software developers about product and project managers imposing schedules, usually at the feature level. Software predictability was never achieved with waterfall development. How was Agile going to provide predictability with schedules established even before requirements are understood? Evolving requirements based on feedback is a tenet of Agile development. Let’s look at why the business needs predictability, and the predictability they actually need.
I’ve had the opportunity to view this problem from the CEO perspective. It starts with the annual business plan expected by your company’s investor or board of directors. They must be convinced that the company will provide a competitive return on investment. Otherwise, investors will put their money elsewhere. The business plan shows how the company is going to achieve that objective over the next several years in terms of revenue, expense and profit growth.
The CEO enlists the executives to determine how they will meet financial objectives. They look to the sales VP to forecast revenue. Of course, the sales VPs first question is, “What will we have to sell, when will it be available and what will be the selling price?” Product management is expected to provide a roadmap in sufficient detail to convince the sales department that they can achieve their sales goals. Hence, the dreaded multi-year roadmap, usually at the feature level, that we know is out of date the day it’s published.
The Agile response of “The business needs to be more Agile” doesn’t cut it. Imagine telling the sales department that you’re not sure what they will get, but you have a great idea for a Minimal Viable Product (MVP) that will tell you what customers really want next year. For better or worse, our capitalist economic model demands multi-year projections, and it’s not likely to change. The business wants a full accounting for what product development will deliver based on their budget allocation. Agile needs to adapt to the business needs. The tail doesn’t wag the dog.
How do we do this since we know that software effort estimation can’t provide the accuracy expected by the business? Agile promised to increase predictability by making short term schedule predictions on a sprint level. However, that doesn’t address the multi-year predictability expected by sales and product management.
The first step is recognizing that at the top, nobody cares about software estimation challenges. Have you ever tried presenting Steve McConnell’s Cone of Uncertainty to the business side or executives? The reality is that manufacturing and sales departments don’t present Cones of Uncertainty. They make hard commitments and manage to them.
However, the sales department doesn’t commit to a specific customer sale three quarters from now. They commit to revenue in future quarters and manage a pipeline of opportunities that changes every week. Manufacturing commits to produce a number of products they already have experience in building. But software development is expected to commit to on-time delivery of specific features before they know the requirements!
The problem is that the software industry uses features and releases as proxies for value. This will never provide the accuracy expected by the business. The software industry must redefine the output of software development in terms of financial value rather than functionality. That is the basis for the Investment planning method described in my book, Unlocking Agile’s Missed Potential.
Teams work on “Agile Investments” with financial goals. The teams can determine the feature content necessary to achieve the financial goals.
Now I’ll let you in on a dirty little secret on another reason waterfall release planning persists. Many executives and managers believe that software developers must be put under pressure, or they will slack off. They have observed that they can push software development to accept additional scope without trading off schedule. They must have slack! Of course, we know the team has sacrificed completeness, robustness, and quality.
I would often explain to executives that by implementing Agile, they are accepting empowered teams that pull work from queues at their pace. The first question was invariably, “How do we know they’re working as hard as the can?” This is another problem to be solved. A topic in my book, and a topic for a future article. In short, Agile development done right by empowered teams that can set and meet their own goals is a motivator beyond anything that can be achieved through pressure.
This also explains why software development is always pushed to somehow measure software productivity, while other departments aren’t. Many of you engineering leaders have heard snide remarks like, “I was in at 8 AM this morning and the engineering floor was empty.” There is currently no measure of value of the output of software development. And software development will always miss schedules given the way output is currently measured at the feature level.
The first step to making Agile successful is acknowledging that the business expects and needs financial predictability and a plan to achieve it.
Author: Bob Webber
Related Content
#product-management
#agile
#predictability
#software-development
#ProductInnovationProcess