Let’s say you’ve been seeing a surge of tweets and motivational quotes involving Agile and Scrum as the ultimate outlook on project management. You’ve even read the manifesto and are currently wondering if your project could benefit from it, but a healthy dose of scepticism is making you hesitant to apply such drastic changes to a formula you know so well, along with its numerous flaws.
You begin to research the implementation of the Agile methodology on products and/or, for example, SaaS companies similar to your own, in hope to find out whether Scrum can be applied to it, but find contradictory personal stories that can’t seem to agree on when to use Agile project management.
Well, we’ve decided to chime in with our own take on switching to the Agile methodology, so let’s not waste time.
The only absolute is that there are no absolutes
Does agile work for all projects?
The tl;dr version is No.
No, Agile can’t be crammed into any project, or at least not successfully. Simply put, it has its pros and cons. There are simply too many factors that could work against any chosen framework, resulting in a total disaster. With that being said, it easier to list the red flags against switching rather than a checklist of prerequisites, so that’s what we’re going to do.
Your project has a high level of certainty
Agile is needed when you’re dealing with a project that has a high level of uncertainty or when you’re aiming for innovation and maximum product quality, even at the cost of predictability. You don’t require Agile if your project requires and heavily relies on predictability, pre-production or pre-planning (although there are some natural uncertainties as with every project).
For example, there are surely some areas in construction working that Agile can contribute to, but are you’re not going to decide on or modify the shape of the building halfway through, simply to pivot your product due to rising competition. Such things are decided in advance, and that’s certainly not very Agile.
You’re using it as a fad
Do not, under any circumstances succumb to implementing Agile across your company simply because it is the new shiny thing. You’re most likely to commit one of the biggest failures – extracting some parts of Agile you deem worthy and disregarding the rest as something of no importance to you. Chances are, you haven’t consulted with a trained Scrum Master, who’d kindly explain that you can’t cherry pick Agile methods that work for you, just like you can’t pick which laws to obey.
Using Agile for the sake of it will not really help your organization. In fact, it will cause more harm than good, unless you go fully invested and committed. This requires a lot of research and preparation, and chances are you’ll fail at the implementation many times before the hype is over. Implementing Agile isn’t easy, nor is it a corner-cutting silver bullet.
The Agile method is enforced
It’s not like the entire company suddenly and simultaneously decides to switch to a vastly different framework. It’s usually spearheaded by employees or comes as a decision from the top. That’s perfectly natural, and the most natural outcome would be to survey the employees, collect their feedback and find appropriate ways to educate them on both the risks and benefits of the proposed system, while listening to their concerns and possible ideas how to tweak it for improvement.
What isn’t natural is shoving Agile down their throats as the perfect remedy that they absolutely have to believe in. Chances are, your unsatisfied colleagues won’t fully adhere to something they don’t fully believe in or haven’t been introduced to properly, and we all know that doesn’t increase productivity or motivation in any shape or form.
You can’t deliver incrementally
Everyone seems to be on-board but you run into a tiny little problem - your product cannot be delivered in increments. This means that you’re unable to create usable, testable pieces of the product after each sprint, but instead deliver the whole product at the very end. Returning to the construction analogy – you cannot use, test or upgrade parts of a building. Instead, you rely on timeboxes, with completed segments at the end of each, but that has very little to do with being Agile.
Your project is too short
Chances are, you’ve got a short project on your hands and it’s something you’ve done multiple times and are very familiar with the planning phase. You’ve also encountered various issues along the way and you either already know how to prepare for them or have eliminated them entirely. There is nothing to inspect and certainly nothing to adapt to. You’re set and ready to go!
Why use Agile then? It doesn’t suit a defined process, especially when its temporary requirements are rather short. Of course, this doesn’t mean you should get overly confident (some impediments may pop up when you least expect them), but if you truly believe you have it in the palm of your hand, don’t use Agile.
Don’t get us wrong, we are strong believers in the Agile methodology and wouldn’t change it for anything (unless something better comes along), but it’s perfectly okay not to use it either.
After all, if using Agile means shoehorning a vastly different methodology where it doesn’t belong, and forcing it upon people who don’t truly believe in it, you and your project are better of without it, as much as it hurts us to say it.
On the other hand, if you are apprehensive about using Agile for unconventional projects (such as making music), we'd also invite you to reconsider. You might just be surprised.