Creating Software from a List of Things? Then Don't Call It Agile
In "Fixed Bid Agile Without Cognitive Dissonance," Elena Yatzeck looks at the problems of committing to projects with a fixed bid (price), vamping on a LinkedIn discussion thread with comments from tons of folks.
Elena explores different aspects of fixed—particularly price and scope—and points out that fixing and defining scope are the crux of the matter.
There are really two ways to think about scope—a list of things to be done or a list of goals to accomplish. Most of the projects I’ve seen—projects quoted for delivery from third parties and projects requested from internal teams—ask for a list of things to be done.
Somewhat rigorous companies will build a business case: “If [list of things] are done, then we will get $X value, and a price of $Y (to do those things) will result in ROI Z.” The team that is bidding (internally or externally) is usually engaged only at this point, and the conversation is often “How many of the items on the [list of things] can we get for $Y?”
When you’re delivering a pre-defined list of things, you aren’t using an agile process. You may be using agile development techniques—iterative delivery, pair programming, continuous integration, etc.—which will help you be more efficient at delivery, but you are not being agile because you are not adapting to change in what is needed. You’re just being more efficient in delivering a waterfall project.
As long as there is no opportunity for a team to change what it is building during the course of the project, it is not an agile process. As long as scope is defined as a list of things, then your project process is not agile, even if your team is using the mechanisms of agile development within the code creation cycle.
It is easy to measure the delivery of a list of things, and you can easily bid on your ability to deliver those things. Unfortunately, this leaves you with no confidence that you’ve delivered what the customer needs because the connection between that list and the underlying goals is at best suspect.
The logical next step is to define scope in terms of the goal that must be achieved. For example, a scope of “shopping cart abandonment rates will drop by 50%” is one that enables a true agile project. This definition places the onus and responsibility for achieving the goal squarely on the team. It also puts all of the risk on the team, which sounds very scary!
Consider the alternative approach—committing to the list of things. Where does the risk go? It falls into the ether, and that’s a big reason why so many projects fail—including agile projects.
Bidding on a project where you have to assess the risk that you can discover an effective way to achieve a particular goal requires a skillset beyond just building a list of things. If you don’t have those skills, don’t bid on that project. Go ahead and bid on the list of things project, but don’t call it agile.
