When Not To Use Agile SCRUM

Note: This is a bit of a technical post. I was planning on writing something absolutely useless as always but I got preoccupied at work. So here's a short article on something work-related instead.


SCRUM is an iterative, incremental methodology for project management often seen in agile software development, a type of software engineering. But seeing as you're already reading this, I assume you already half understand what it's supposed to be.

Personally, I think AGILE is the revival of the hacker ideal. By limiting the normal overhead that plagues more traditional project management, developers are empowered to be actually more productive. The system is not without drawbacks, but by God, it really works.

Now the problem with AGILE is what's also so good about it. Because it works for some cases, a lot of people tend to start assuming it will also work for a lot of other cases. Simple isn't always the best. Because if we'd always think simple, we'd still be using abacuses to read this blog entry, if that's even possible.

So when does AGILE not work? Here are some situations where applying it may be forcing the issue:

1. When there simply aren't enough people. AGILE/SCRUM is an overhead-saving tactic, but it doesn't mean it has no overhead of its own. For very small tasks or very small teams that can be easily coordinated through other more ad-hoc means, AGILE/SCRUM is overengineering (ridiculous as it may sound, it does happen)

2. When the budget/schedule is fixed. The thing with AGILE/SCRUM is that it relies on the idea that the cycles are sustainable, ideally for a lot of iterations. In reality, this is hardly the case. Very few products that stay in an evolutionary development phase for so long tend to survive financially. Clients want their product stable, finished, and perfect. Theoretically speaking, the first iteration should produce something usable already and the succeeding iterations are for evolving this first release. The problem with this is that one, the client/schedule is almost always greedy and will keep wanting more, and two, when the budget is fixed, you only get to have a finite number of cycles - which forces you to plan out in detail, which defeats the idea of SCRUM in the first place - which is to avoid the rigidness of planning. In the end, when you use AGILE for the highest level of project management, you are forced to either deviate from the dogma of AGILE, or extend beyond the budget, which is almost always a project killer.

3. When the requirements aren't managed well. The basic idea of AGILE is to code fast, show to the user, and let them tell us what they think of the system. In a positive scenario, for every iteration, only 20% of what was added gets to be modified. Anybody who's worked with particularly influential clients, of course, will say that never happens. Without strong grounds for locking down what is needed, a simple change in whim, point of view, or even contact person will combine with the AGILE ideology and cause utter chaos on your project. Large chunks of rework means additional resources being consumed by the project, which is exactly what you need to avoid if you need to keep things "simple".

As a conclusion, I'd just say that AGILE is a really good tool, but purists are most definitely wrong when they start saying that it's something that replaces traditional project management entirely. On most pure large scale scenarios in the corporate industry, relying solely on AGILE/SCRUM is a big no no. A lot of real-world factors, some not mentioned above, will affect the effectiveness of the methodology unless duly addressed by supplementary techniques.