When is Agile a bad idea?
There are scenarios where Agile, and it’s frameworks (Scrum, Kanban, etc.) are great. But there are scenarios where it’s not such a good fit.
This article discusses some of the scenarios where Agile isn’t the best idea and won’t be the “silver bullet” that many are hoping for.
This article is part of a series. Go to the Contents page.
1. Retro-fitting Waterfall
Waterfall provides a series of tools and steps you can follow to execute the project, almost like a checklist.
New managers enter stage-left with the dictate “I want to do Agile”.
But what the organisation ends up doing is trying to wrap Scrum (for example) around the Waterfall process.
Often called Hybrid, but in reality translates as adding an iteration around the work, holding planning, review, retrospective and stand-ups. But still holding dear to project gates, Gannt charts, checkpoint meetings, board reports, and so on.
This does not address the mindset of Agile, it simply adds a bunch of meetings into an already cluttered diary. More meetings, leads to the feeling that all Agile does is waste more time, and we should have just stuck with Waterfall.
So the base of the new framework is weak, and will crumble. Generating a bad reputation for any future use.
So educate your audience. Be clear on what the problem is. Does the scenario represent one or more listed below? Or, quite possibly, other pitfalls.
2. Lack of Agile skills and experience
Someone has been on a course. Or read a book. They are now the one-eyed man, in the kingdom of the blind. But heck, let’s do Agile!
So they start telling people about iterations, and meetings (events), and this is how we will do it.
The first engagement with people who have not worked in an Agile environment will bring with it skepticism, and a long list of questions. They may be constructive questions, or more likely, cynical ones.
You have to win over your audience. And skills — and experience — are of paramount importance. Answering “the book says this…” will not inspire confidence. Implementing Agile and it’s various frameworks requires experience.
Scrum is a framework, not a methodology. It is not done “like this”, but is “guided”. It is the Scrum Guide, not the Scrum Book. How Scrum can address questions, scenarios — valid or otherwise — requires experience, not just skills
So bring in that experience if it doesn’t exist. By adopting Agile, people will gain experience and fill the void, but to start with bring the experience in to advise.
3. Using Agile as a Badge
To “be Agile”, the organisation needs to reflect the desire to at least move in the same direction. Having parts of the organisation stuck in a non-Agile mindset will distract at best, and destroy at worst.
Managing resources and the ability to capacity plan in a more Agile way will not be possible if resources are managed in a traditional sense.
The non-Agile parts of the organisation will be a ball-and-chain to those looking to work more Agile.
Senior management saying their organisation is Agile may feel good; sales people selling to customers and saying their organisation is Agile may sound good. But if unable to deliver with Agile it all falls apart, reputation is impacted, staff morale dives, and so on.
Do not use Agile as a badge.
An organisation should start changing the culture and gain support at all organisation levels before shouting that they have Agile from the rooftops.
Agile is a mindset and not a tool.
4. Multi-tasking Teams
Multi-tasking is often praised — but it kills productivity. Studies have been undertaken that productivity drops pretty much exponentially as the number of multiple tasks increase. It’s why Kanban (an Agile framework) is focused on limiting work in progress.
So if your team is working on too many multiple tasks, the chance of completing them will increase as the number increases. And it’s not linear! And not in a good way.
Whether focus time, context switching, stress, whatever the reason (and usually a mix), you want your team focused.
Agile requires an excellent understanding of the specific business case or customer needs, and going from one solution to the next, without the time to give suitable attention and consideration to the tasks required, will not bring great value.
Imagine a team multi-tasking, working to (or beyond) their limits — and then you drop the Scrum meetings (planning, review, retro and standups)?
You will lose the audience and Scrum will fail.
So consider what you are using Scrum for. What problem are you solving? Scrum may not be the silver bullet as the problem may not be related at all.
What is the actual problem you are solving?
5. Inter-dependency
Agile is all about continuous improvement. Do something simple. Review it. Make it better, often through iterations via Scrum.
However, if a team is dependent on other factors (people, projects, systems, etc.) it is not able to be Agile. It will be waiting for other things.
Agile projects should flow. Continuously. Always improving.
This is not possible if the team are constrained by external dependencies.
6. Rigorous Processes
Take a hospital as an analogy. You cannot learn from mistakes if you need to make some sick, to learn from, to improve from. Your career will be very short-lived! You cannot treat patients in an Agile manner.
So do you, or does your organisation, live by processes that must be followed and adhered to? Or can you experience, with the freedom to learn quickly and improve quickly?
If you are constrained by process, you cannot be Agile. Processes are of course important, but as per the Agile value, “Interactions and Individuals over Processes and Tools”.
A note that the quote includes the word over and not instead. Processes and tools help — but they must not hinder agility.
7. Customers do not collaborate
Agile is all about people and collaboration. If you are viewed as the supplier, who will be told what to do, do it, and return then you are not being Agile. Even if you are operating with iterations, or using a Kanban board, and so on.
Without frequent collaboration with the customer, you are not being Agile.
Setting customer expectations, and demonstrating the value of collaboration, is crucial to being Agile.
8. Over documenting
It’s a myth that “Agile doesn’t do documentation”.
But being Agile means doing enough documentation, at the time it’s needed. It does not state how much documentation is required.
So if you are working in an organisation that dictates more documentation than is needed, at the wrong time, or with a customer that expects more than allows you to work in an Agile manner, you are probably better off with Waterfall. Public sector organisations often require more than is needed, although this is changing as they adopt a more Agile mindset.
If you have to plan around gates, boards, high/low level documentation that requires formal sign-off through change boards, board meetings taht require reports, slide decks, and so on — consider whether Agile is the most appropriate manner to deliver your projects.
9. Highly defined projects
There are types of projects that are more suited to Waterfall, especially when the plan is known ahead of time.
- Do you care more about control and governance than innovation?
- Are your requirements fixed?
- Is the time-line fixed?
- Are the resources fixed?
- Is the plan agreed?
- Is it a roll-out that requires certainty?
Then this sounds more suitable to Waterfall than Agile.
If structure is important, and certainty is important — then consider Waterfall.
10. You know what you need, and need it
There are types of projects that just do not fit with Agile.
If you were building a Skyscraper from a blue-print, you probably don’t want to try-and-fix as you go. You could be half-way up and realise that you’re getting it wrong. Time to brush up your CV, as you will be looking for a new job!
You will even hire specialist architects to create the blueprint, and structural enginers to validate the design.
The construction company will, and should, build what they are told.
This would not be an Agile project.
Wrapping Up
Agile is not a silver bullet. Waterfall is not bad. Choosing the most appropriate approach for deliverying projects should be based on the various merits of each.
