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