If you've been following debate on the healthcare issues in the United States, Canada, or Europe, you may agree that things are off course. I've noticed that, in many cases, the entire discussion revolves around the wrong question. It seems like all coverage, analysis, and chit-chat is about the question "How will we pay for all this healthcare?" But, I think the question that needs to be answered is actually "Why does healthcare cost so much?" It is very interesting and very distressing that healthcare is so expensive. Wouldn't we be better off understanding why it costs so much and looking for ways to reduce costs rather than just laying out one plan after another to pay for these giant expenditure
I think the same thing can happen in software project management. If we don't ask the right question at the beginning of the project, then no matter how well we answer, it won't be helpful.
When I ask people the difference between agile and waterfall, I get a lot of answers. Some say "Agile is a mindshift where businesspeople and technologists work as partners." Others say "Agile is nothing but, mini-waterfalls." Still, others say that "Agile is about a human-oriented process."
But, I've come to realize that perhaps the biggest difference between agile and waterfall is the question being asked. The scope of the project and any judgments of progress are related to this very fundamental question.
The Waterfall Question—“When Will It be Done?"
If you've ever been on a waterfall project, you've heard this question. It is the most typical question for a project manager to ask a developer, business analyst, or tester. "When will that service be coded?" "When will that test script be executed?" "When will that use case be written?"
But, I am actually not talking about those questions. I’m talking about the more macro question, "When will this project be done?" This big question gets asked less often, but, it is on everyone's minds. "Will we get it done?" It is a question that can provide great focus. But, it is also a flawed question. It is flawed because it has a hole—a hole big enough to drive a cement truck through it.
The offending hole in the question is "What is 'it'?"
Sure, you can say "'It' is the project, defined by the scope," but, this is a huge problem. Even with abundantly clear requirements and scope, there is plenty of room for different interpretations. The executive reads one thing between the lines. The project manager reads another. And the end-user reads yet another. You can never get enough detail written down to assure that all misunderstandings are rendered impossible.
And that's assuming that requirements were documented fastidiously and that the team had time to do that. On most projects I've seen, teams have had to make compromises in their detail level of requirements, and so different perspectives run rampant.
"I'll know what I want when I see it."
Business users are somewhat famous for this remark. By saying this, they are committing to nothing until they can see the result and only then will they make a judgment as to whether "it" will work or not. In a waterfall project, the moment when a user can get his hands on the actual "it" is very late in the lifecycle and many decisions have already been written in stone. Too late to incorporate feedback! Sorry!
There is another problematic aspect to "it." Part of a project is the scope of what is required to be in the product for completion. But, another part is how your team will accomplish "it"—the workplan. How many perspectives are possible in that? Again, team members will build a workplan together that reflects what they think needs to be done for the product they believe the business needs. Can you see a few possible pitfalls here?
The team members might be wrong about the tasks, they might have misunderstandings about the work to be done, even amongst themselves, and, they might underestimate the effort involved. All of which will cause headaches later on for the technical team and the businesspeople.
So, predicting the answer to the waterfall question (the big question) becomes very difficult.
And, I'm sorry, but, I must add yet another complexity to "it." The "it" at the end of the project is a different "it" than at the beginning. As a very smart businessperson I once knew stated, "Don't give me what I wanted at the beginning of the project, give me what I want at the end!"
Business changes. It is very likely, if not downright guaranteed, that the business needs will change during a six-month project. It's a different "it." How do you plan for that? Change control? Phase two? That doesn't help anyone.
The Agile Question—How Much Can You Do By This Date?
OK, so we need a new question. And it would be nice if the nasty "it" word was not in the question!
In agile, let’s change the question to "How much can you do by this date?"
Let's look at the implications of this question. Now we are fixing the date and saying "Do what you can before then." Is it possible that I'll have one perspective on the definition of March 29 and you will have another? Not really. There is a slight danger that we could misinterpret what it means to be "done," but, that can be worked out pretty easily. This new question lets us work together on building the scope of the product and figuring "it" out over time. This becomes a very exploratory process, where the definition of scope is allowed to wander around a bit before it comes to rest just before the application goes live.
Are you thinking "scope creep?" Are you thinking the businesspeople will keep changing their minds back and forth (and back...and forth), forever keeping the project from ever reaching a conclusion? Sure, these things are possible under agile. They need to be managed. A good agile project manager watches for these symptoms and jumps on them to avoid serious consequences. There are specific agile practices to keep a team from falling into these traps and to notice them quickly.
But, is the agile question actually a motivational goal, the same way the waterfall question is? After all, couldn't your team just doddle along and then declare itself done when it bumps up against the date? Yes, of course, nothing stops any team from being irresponsible. But, in my experience, teams want to do a good job, and if team members want to do the wrong thing, no set of lifecycle rules will stop them.
So, in our experience, here is what happens when you ask the agile question "How much can you do by this date?" The team members look carefully at the set of requirements, in agile terms this is called a "backlog," and they take the highest priority items and commit to fulfilling those in the time period. Plus, the team breaks up the overall time period (let's call that the release) into smaller time periods (called sprints). Then, for each of the sprints, team members do the same thing—they decide how much they can do by the sprint end date and commit to that. Commit a little, accomplish a little. Then, they whittle away at the overall goal for the release end date by making smaller goals within the sprints.
Yes, it does happen that the team accomplishes less than it originally committed to for the release. But, ask almost any businessperson in almost any situation "Which would you rather have, all the features delivered late or most of the features delivered on time?" The businessperson will choose the second option most of the time. Business runs on budgets and dates. The people most concerned about the exact feature set are usually the technical people. Of course, businesspeople will insist "I want all those features delivered by this date and within this budget!" But, you know what that's called? It's called negotiation. Make your initial demands and then see what the other guy does. Trouble is, most of us technical people are terrible negotiators. So we give in too often.
The agile question "How much can you do by this date?" is the better question. It does involve a certain level of trust of your project team. But, it provides a better resolution of what "it" is, without assuming anything up front and by exploring "it" until "it" comes together at release time. And, the agile question also provides much better value to the business, by playing on its terms of fixed schedule and budget with a flexible set of features.
