The biggest, most central questions of a software project are the same as for any kind of project. They’re things like
- What does success look like?
- What does failure look like?
- How valuable is this project? How costly?
- What needs to be done? What is merely nice to have?
- Under what circumstances should we give up?
Really, the biggest question of any project is always “Should we be doing this?” If you’re not prepared to say no — if you’re not actively identifying the conditions that would lead to “no” — you’re no longer doing business, you’re practicing religion.
Just below those existential questions are the “what” questions:
- What problem are we solving?
- Of the problems we’re solving, which one do we want to solve the most?
- What needs to be done? What is merely nice to have?
- What do we have so far? What’s left before it’s viable?
It is tempting to treat the word “Agile” like a get-out-of-jail-free card; to decide that you do not need to answer these big questions if you are delivering small things all the time.
This temptation must be denied.
If we wanted to reinvent iterative development, all we’d have to do is acknowledge that the answers to all these big questions are uncertain, and may change over time. All the specific (and sometimes mutually exclusive) processes we associate with “agile” are the direct consequences of that potential for change. Because the definition of success might change, each iteration we add details to only a small part of the plan, leaving the rest free to change. Because the expected value might be wrong, we deliver frequently to validate our assumptions.
But these inevitable consequences are costly. If you knew — with 100 percent certainty — the answers to all the important questions about a potential software project, then a waterfall process would be faster, cheaper, and produce a more tidy outcome.
Iterative development is a way to minimize — but not eliminate — the price we pay because we cannot know those answers perfectly. The less certain we are, the more costly the iterative path to finding out, but iterative development still works even in highly uncertain environments where waterfall cannot.
In many ways, that’s a miracle. Agile transformations have been the stock in trade of consultancies for decades because the same few process ideas can handle a wide range of initial project conditions.
There is a danger, though: permanently uncertain projects. The simple daily and weekly activities of iterative development will look and feel much the same whether they are converging on some satisfying outcome, or wandering at random. You can have lots of velocity but no clear direction, and never get anywhere — and you can do it without noticing.
You can deliver small incremental improvements, iteration after iteration for years, and never create a coherent product that solves a weighty problem.
The moral is that “agile” does not free you from asking these big questions; no project can be sane without them. Instead, it makes you responsible for asking them over and over again, always refining and reacting to changing conditions. Every interation, the whole team should have a clear idea of where you’re going, what you learned last week, and what you’re trying to learn this week. The whole team should be able to recognize, with relief, the moment when a big question has a settled answer; and for each question that doesn’t, the whole team should know what they’re doing to try to settle it.