Here’s why you should use Agile for small projects
I can’t tell you how often I’ve seen this model circulating LinkedIn — and I’ve used it on occasion as well. I’m talking about the version that has the methodologies scribbled into this model as sort of a guideline on what to use. In fact, you may have run into it once or twice yourself. From the face of it this picture seems to make a good point. Agile (Scrum / Kanban / XP) works best in projects where there is a fair amount of uncertainty in either technology or requirements (or both), but a Waterfall-based approach is more suitable for projects where there is little to no uncertainty — like small projects.
Despite its face value, I don’t agree with the conclusions drawn from this picture. In fact, I think it misrepresents what we’re trying to achieve with Agile software development. Let me tell you why.
Agile Software Development is built on the premise that software development is inherently uncertain. This uncertainty comes from a variety sources, such as feedback from stakeholders, the technology used, cognitive biases (in estimates, for example), a changing business-landscape and our limited ability to comprehend the interplay of variables involved in a project. The result of this uncertainty is that we will assume things throughout a project that will turn out to be wrong. Our estimates may be off, chosen technologies may not work out or perform well enough or we incorrectly assume what our stakeholders want (or need). There are basically two ways to deal with this; either we resist change and stick to our original assumptions (or push it to end of the project) or we accept it as a natural part of any project and correct our course when we discover incorrect assumptions. The former is a waterfall-based approach, while the latter is Agile-based.
My disagreement with this picture lies in two things.
First, I don’t agree with the premise that there are projects where you can reliably state, upfront and correctly, that all requirements and/or technology are entirely known. In other words, I don’t believe that its possible to predict — upfront — that a project will not be subject to change and that all assumptions about scope and requirements will hold up. “But what about small, short-lived projects?”, you may ask. This is a good point, and I guess that the ‘known/known’-quadrant in the picture was drawn with small projects in mind. It stands to reason that smaller projects will be subject to less change and fewer incorrect assumptions than very large, multi-team projects. But although this may be true, I don’t believe that the cost of incorrect assumptions is also less expensive in a small project. Maybe in absolute terms, but not in relative terms. A small project will have less margin for error, which means that incorrect assumptions must still be detected as soon as possible. If a project takes only two weeks, it will be very expensive to discover at the end that the customer wanted something different, or that the framework needs to be switched for something else because it doesn’t perform well. So even for a small project, you still want to have a process that detects failed assumptions as early as possible — which is exactly what we’re trying to achieve with Agile software development.
My second disagreement lies with the conclusion that a Waterfall-based approach is most suited for a project where there is little uncertainty. This feels akin to putting on blinders and ignoring sources of potential change, like valuable feedback from stakeholders throughout the project. Although there are certainly ways to involve stakeholders in a Waterfall-based approach, it is much harder to actually do something with their feedback without having to go back to the drawing board. And because a Waterfall-based approach tries to resist change (and stick to the plan), any stakeholder-involvement might easily turn into a charade: “Yes its a great idea you have, but we cant put it in scope because we didnt account for it”.
The bottom-line (for me) is that an Agile-based approach is always superior to an approach that doesn’t actively seek out and invite sources of change and ways to test assumptions as early as possible. For projects that are very large, but also for projects that are very small. The cost of a mistaken assumption that is discovered very late is equally expensive for any project, regardless of size and complexity.