Not everyone would benefit from the various processes that implement the agile philosophy.
Besides the structural deficiency in the agile principles themselves; the various processes that tout their alignment to agile principles ignore one of the most foundational elements of any effective process: they pay no attention to introducing scientific process rigor into the experiments that are “Iterations”.
Leaving that gaping process hole aside, there’s also that even if your favorite flavor of ‘agile’ was perfect for the scientific rigor needed for your context, not all processes are suited to all companies in all contexts.
We fully expect this sort of nuance in other industries, even if we completely ignore it in software development. What works for McDonald’s wouldn’t and shouldn’t work for your local mom-and-pop burger joint, because their aims are different.
So too with Software Development. The aims, structure, and goals of an organization dictate what processes should be used to achieve those aims. Slapping some agile on a team because it’s the most popular methodology is the height of folly the bounds of which are only surpassed by the insistence that it’s the best we can do.
Those issues aside, even assuming for our purposes that agile really is the best we can do, here are three situations where it’s ill-suited for success:
- A known scope, known timeline project wouldn’t benefit from an ‘agile’ approach because the customer both knows what they want, and they have expectations on how to get there. A team ‘inspecting and adapting’ is a likely to be irritating to them as it is useless to the overall goal.
A corporate IT project falls in this category quite a bit, especially for a system rewrite. Now rewrites are terrible for other reasons, but if you’re trying to fit an ‘agile’ process into that situation, at best it will feel awkward, and at worst becomes a sort of Kabuki theater.
2. A variable scope, known timeline project fits better, to be sure, but it suffers from the “adapt” part of agile. If you have a known timeline all work has to be finished by (whatever that work is), then what matters is getting the most done in that amount of time. If agile is the art of “maximizing the amount of work not done”, then a situation where you want as much done as possible is antithetical to the agile way of thinking.
3. A true fixed-budget startup cannot afford the ‘trial and error’ nature of agile. You only get so many iterations before you fail, and you need something deeper than ‘inspect and adapt’ to survive.
If you find yourself in any of these situations, adapting an ‘agile’ process, especially one like Scrum, is going to feel kafka-esque at times, and any success you may achieve may be in spite of your choice to adopt an agile philosophy, and not because of it.