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