I am a strong advocate of Agile development practices. I think they solve a lot of problems specific to the software development process, creating happier, more invested, more productive teams.

But we have all seen Agile projects go wrong. Generally Agile projects go wrong in more controllable ways than more monolithic projects, and you can normally end up with something useful out of them, even if it’s not all you originally hoped for.

But you should also be on the lookout for Agile projects that are starting to go really wrong. Ones where something uncanny has happened to them and they have become the kind of monsters their team members will talk about in hushed whispers for the rest of their careers.

Many, many projects have been successful despite suffering from the various Curses of Agile Undeath, especially as a good team can work around a bad process. But if you’re repeatedly running into some of these beasts, it can be worth reviewing your processes, to see if you can slay a few of them.

So, let’s go monster hunting!

Zombie Agile

The most common type of Agile monster, this is where the actual Agile spirit and values are dead, but you are still performing the ceremonies.

The project can shamble on, slowly decaying, but the ceremonies themselves have no effect on the project. Retrospectives slowly atrophy into moaning sessions, planning into an episode of “Guess The Random Number The Manager Wants To Hear”.

The main issue here is with the morale of the team. At best, they will walk away with a negative attitude towards the project. Worse, they may have developed a negative attitude towards the process, which will influence projects going forward. At worst, they will literally walk away and quit the company, because they have developed a negative attitude towards the team.

The way to slay this monster is to reassess the value of the ceremonies with the team. If you genuinely feel that, due to the status or nature of the project, some of the ceremonies have lost their value, Agile is flexible enough that you can stop doing them. If, on the other hand, there is something of value that those ceremonies are supposed to provide which they aren’t, you can restructure them to focus specifically on those issues.

Goblin Agile

Once even more common than the Undead, this is “Agile” that has no ceremonies, no planning, no real structure. Things are added and taken away from the project on impulse.

In response to any suggestion that it’s hard to know if you’re making progress or aren’t sure if certain things have been considered, the response is always “we’re doing agile”.

The obvious danger here is that something, somewhere will be going wrong, and nobody will have any idea. Also, for most developers this is a fundamentally stressful way to operate.

The solution to this is to bring in an authority on Agile practices to tell them where they’re going wrong, what risks they’re running, and how an actual Agile process can help them.

By bringing in a “Big Boss”, your rowdy gang of devs, testers and clients will respect, whether you use an external Agile consultant or an experienced member of the company, you can refocus the team on managing the risks that this particular approach creates.

Golem Agile

The mirror image of Goblin Agile, this is an agile project that has no agility. The Agile process is “understood”. It is engraved on a certificate and placed directly into the head of your project.

None will deviate from the Agile process. Your process is SCRUM. You will perform all the SCRUM ceremonies. This thing that would obviously be useful is not SCRUM, therefore you will not do it.

In some ways, this can be a highly useful approach, because a lot of best practices are used for a reason. But this “Agile” process isn’t Agile. The team can’t deviate from its rules, even if the rules are preventing them from producing their best work.

While you should never discard the process completely (except when you should), it is important to recognise when you are being constrained by your process.

A good Agile consultant can recommend various tweaks to your processes to ensure you’re getting value from your processes rather than just mindlessly following them. More importantly, they can give you the confidence to know that the tweaks you want to make are “acceptable”, and what the consequences might be.

“Were-Agile”

An Agile project that, when the moon is full (or some time-based condition like a senior management review) somehow morphs into a waterfall model.

When this occurs, it unexpectedly sprouts Gantt charts, a groan rises from its dev team, and velocity drops by multiple story points until the effect passes.

The solution here, as project lead, is to try and minimise the exposure of the team to this process, making sure they themselves don’t get bit. Don’t show them the Gantt charts, don’t discuss the stakeholders. Let them focus on adding value.

Work out what information you need from them, extract it, and then quarantine yourself from the process till the sun rises again.

Eldritch Agile

This is an entirely agile project, but their work is secretly surrounded by a Waterfall structure that they live in blissful ignorance of.

Only a few haggard and knowing souls are aware of the truth, which makes many of their decisions inexplicable to the other members of the team. We call these people “Project Managers”.

In many ways, this can be an entirely successful way to introduce Agile to a large company. The problem is when the protective Agile bubble pops, for example because of project delays or a change in project manager, the shock factor on the team can be extraordinary.

There are two aims you should be approaching here. One is to “civilise” more and more of the savage, pre-Agile landscape. Ideally, your entire organisation should be working in an Agile style, not just the software developers. So you have to slowly increase the size of your “Agile bubble” until it covers your entire organisation.

The other approach, which is not as good, but often more achievable, is to ensure that the bubble does not pop. This means that project manager must be able to either prevent delays, or manage stakeholders’ expectations to prevent them from micromanaging when delays happen.

Pragmatically, you would want apply both approaches. Indeed, protecting the team often involves educating the overall business on Agile methodologies and values, which can help with making the entire organisation more Agile.

Haunted Agile

This is a project still reeling from its last delivery. The ghosts of a release that cannot rest easy walk the scrum and kanban boards. This can include rollover work, bug fixes, and “follow-up” testing (in other words, finding the bugs you’ll then need to fix).

Often, the team will never officially acknowledge that these spooky requirements are appearing from a supposedly finished delivery. They will simply go about their work, secretly working around the fact that their coffee mug keeps floating across their desk.

The solution here is to exorcise your ghosts. Put aside one or more sprints to properly address the holdover issues, and adjust the release deadlines accordingly. Basically treat those sprints as if the entire team had fallen terribly ill or the office had caught fire, and thus the deadline needed to move. Then finish the work from the previous release that was left unfinished.

Conclusion

While this is obviously a tongue-in-cheek way to describe these issues, the problems above are serious concerns that you need to be watching for when running Agile projects.

The main signs that something is going very wrong on an Agile project generally are most visible from team morale. Developers may not know how to fix a project going wrong, but they know that something is going wrong.

And it’s your task to find out what and lay it to rest.

From goaties and ghosties

And long-leggedy beasties

And projects that go bump in the night,

Good Agile Practices, deliver us!

Traditional Scottish Poem, Adapted

Side note: While writing this, Youtube drew my attention to Dave Thomas’ Agile Is Dead article and associated conference speech. While the only influence on my post was being inspired to actually finish it, if you enjoyed my post, you should absolutely check out that video.