I’ve been having difficulty recently with a trend I’m seeing on projects. What happens is this: we (an agile development team) engage with a client for a short period—typically 2-4 weeks—to investigate how we might work with them to solve their problem. During this period, we drive out lots of stories, do some technical investigation and estimation, and out of this we generate a high level release plan. All very good, you might think. But then, unfortunately, everything is mysteriously forgotten about except the release plan, which suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Well ok, it’s not quite that dramatic, but it certainly doesn’t feel very agile to me. Hopefully I can explain why.
To my mind, there are two primary objectives of this initial phase. Firstly, we get to know each other and think about how we want to work together. Secondly, we create a shared understanding of the project’s objectives, timescales and risk profile. Coming out of this process, everyone should have the same sense of “bigness” of the project, in terms of both size and complexity. The release plan is just a detail in the process.
An agile project—in fact any project—should focus on a set of outcomes. How we get there is less important than actually getting there. A CIO or business sponsor wants to solve a specific problem, by a specific date, and has an idea of how much money they are prepared to spend achieving that. By driving out a comprehensive list of stories, estimating them, and then rolling it all up into a Big Release Plan, you run the risk of focusing attention on the features (stories) and defining Success as the delivery of all these stories. This is exacerbated when the release plan is shown to people who weren’t part of the original exercise. They see the release plan and naturally assume that it is the primary “output” of the process.
In the manner of the Agile Manifesto, whilst there is value in delivering a list of features, I value achieving the outcomes of the project higher. This feels complementary to the other four agile manifesto values.
Two recent examples. On one project it became apparent that we were unlikely to meet a particular hard deadline given the current story backlog. The team worked with the client to find a way that they could still meet the project’s outcomes and deadline, by dropping or deferring around a third of the features. The client was delighted! The message was simple: I can meet your outcomes with only two thirds of the effort (i.e. cost) of the previous plan. Who wouldn’t want that? That conversation would have been dramatically different if the client had been wedded to the feature list as the definition of success of the project. Luckily he had the insight to remain focused on the overall objectives of his project, and they hit the date.
Another project had a stability issue in production. The (very critical) application would fail mysteriously every couple of days. They needed a solution now because they were losing business as well as being in danger of getting in regulatory trouble. The project manager simply asked the operations guys to manually restart the application every night as a standard operating procedure. At a stroke the initial problem was solved—the outcome was met—without a single line of code being written. Now the team could focus on solving the root cause, without being under pressure to produce a rush job.
“Scope” is a dangerous word, since it can be used to mean either features or outcomes, but never both. Does “cutting scope” really mean failing to meet objectives? Or were those features not really core after all? A project has to have a goal, otherwise you can’t know when you’re done. Without a goal, you will tend to define “done” in terms of execution of the story list. Similarly, it has to have a feature list, or you don’t know what you’re going to do to get there. So it is just as big a risk to have no clearly defined outcome (i.e. no vision or purpose for a project) as defining a fine-grained feature list up front. Next time you engage on a new project, make sure the entire team—and especially the sponsor—has a clearly articulated outcome for the project. And make sure you regularly review your direction to ensure you are still working towards those outcomes.
