Here’s the challenge: Has any Agile project ever kicked off without a Phase 0? I don’t think so, but I’d love to hear from readers who want to prove me wrong.
For those coming late to the party, there’s an ongoing debate in the Agile community about Phase 0. One Agile value is “no Big Design Up Front” or BDUF. That’s often translated in practice into: No planning, no user research, no concepting, no requirements specification. “Look at Flickr!” the purists say. “They thought they were doing online gaming! But photo sharing turned out to be the most desirable aspect and over successive iterations, the site evolved to what it is now.”
So an Agile project, in the most extreme view, starts with the most involved people sitting down in a Release Planning Meeting, brainstorming what they’d like, and putting features on story cards. Sort the cards, and start coding.
There are a few problems with this.
First, there’s the question of who’s in the room. In theory, the customer gets to define what goes on those cards. But who is the customer? There’s nearly always more than one. Who gets to represent them? How do they know what to say? In most real projects, the customer ends up being the product manager or some other surrogate. And without a process for them to learn what’s really needed by the real customers, they’re guessing at what the needs are. And that’s not good.
In fact, of course, even real, honest-to-goodness end users have to guess at what their needs are. It’s been a frustration to well-meaning developers since forever that you can’t just ask users what they need and get a reliable answer. Users are buried in doing the work—they don’t think about it in the large. They don’t have enough distance from it to see where the real roadblocks are. They assume things have to be a certain way because they’ve always been that way. So even if the end-users were in the room, the cards they wrote wouldn’t be reliable.
That’s from the user side. There’s also a problem from the design side. If a product or system was just a collection of features, writing them on individual story cards might be fine. But, of course, a system is more than that. Every time someone writes a story card, they have a whole concept in their mind of how that feature is going to fit into a larger system and how it’s going to help users do something useful in the world. Where’s that larger design represented? How is it shared? In fact, the most important conversation in the Release Planning Meeting—the overall design and goal of the system—is not acknowledged or represented.
So given these problems, how do real teams get around them? So far as I can tell, by doing some level of up-front design. Not “design” as software engineers use the term—they talk about the design of the software architecture—but design of the user experience. Whether it’s done by writing a Product Requirements Document, doing some user research, doing “product concepting”, everyone is starting with a clear idea of what they want to build and they engaged in a set of activities to get there.
Lately, when I do talks I’ve started to challenge the audience—who can give me a counter-example? Who thinks they’ve really started with no Phase 0 at all? So far, no one’s taken me up on it.
So now I’m asking you. Write me back if you think you really kicked off your project with no Phase 0 at all. I want to hear how it went.
Anybody?