Badgile — The Horror Stories of Agile Gone Wrong

Badgile

Badgile is a word I use to describe a “bad” Agile process. I put quotes around bad because it is a strong word, processes by their nature are going to vary by team and situation, they should always be inspected and improved and my intention is not to claim I have the magic recipe for Agile. I have worked with my team to build what I think is a pretty great process, but I would never think to pick it up wholesale and impose it upon other teams in other organizations. A great process is about layering principles onto individual situations, what comes out is probably different variations per team even within the same organization. When I say bad or wrong, I mean indisputably bad, just a whole pile of stinky wrongness…

“Tell me about your development process”

One of the questions I always ask when I conduct an interview is for the candidate to describe their development process. This is often very revealing, the people I am interviewing usually have very little influence on the process (which is unfortunate, but a topic for another time) but the question can reveal many interesting indicators:

• Can the candidate verbalize the process (or lack thereof) clearly, even if the process itself isn’t clear?
• How do they feel about the process?
• Do they have influence?
• Are they frustrated?
• What have they done to try and improve it?
• Do they play the victim role?
• How would they change the process if it were up to them?

Of tangential interest to me is just hearing about another companies’ process, as someone who is a bit of a process geek I am just fascinated, and I must admit that I have been known to dig in further than I probably needed to on the really interesting ones. I don’t necessarily hold a bad process against a candidate, I can sympathize with them, and I tell them they are not alone. It gives me a good opportunity to sell what life can be like when an organization really embraces Agile.

“We’re Agile!”

Usually, the conversation goes something like this:

Me: “Tell me about your development process.”

Candidate: “We are an Agile shop!”

Me: “Great! Elaborate on that, walk me through the process.”

Candidate: “We have daily stand-ups, we do sprints.”

Me: “OK, would I be right in saying it is Scrum based?”

Candidate: “Yes, we are Scrum.”

Me: “OK, so is this Scrum “by the book”, has it been modified? Tell me more about it and what you think works and what doesn’t”

Candidate: [Pauses] “Scrum… Stand-up… Sprints…”

Me: “So how long are your sprints for example?”

Candidate: “3 weeks” — It is almost always 3 weeks, although more often than you’d think it is 8 weeks, or in some cases 4–6 months!

This is the point in the conversation that it might go off the rails a bit. Either the totality of the process is sprints and stand-ups, or you start hearing about other suspect practices about when things are getting tested (later), or how big is your team (45 people), or how it is decided what goes in the sprint (a Project Manager tells us), or that their stand-ups are an hour long each day (but hey we get great value from them). There are a lot of red flags that I hear and I plan to touch on those in future posts.

I often walk away from this part of the conversation really deflated, not a reflection on the candidate, but a reflection on how little progress many software development teams have made in the last 10 years. We’ve moved on from the long slog, disjointed, false sense of predictability that so many Waterfall projects represented, but often it has been replaced with poorly implemented and poorly understood Agile processes that are really no process at all. They just end up with a stressed out manager pulling at his or her hair and screaming at a team to improve their velocity.

The stories are real and to be honest I wouldn’t want to work in the majority of environments that are described to me. Software engineers are educated, creative, professionals, putting them in cages makes no sense at all, they need a process that helps them spread their wings. We need to be free-range not battery. Sadly a lot of software developers don’t even know they are living this life, they think long hours and failed projects are just an inevitable part of building software.

Stand-ups and Sprints Does Not An Agile Process Make

Here I am paraphrasing Aristotle (not Yoda), the point being that all too often teams are putting up an Agile facade and hiding behind it, but the sad thing is its not even a very good facade. Implementing an often ineffectual daily stand-up and a poorly managed meaningless sprint cycle does not make you Agile, it makes you Badgile! There are a lot of reasons teams struggle to put a good Agile process in place:

• Lack of understanding
• No buy-in from executives
• No buy-in from the team
• Lack of trust in the team
• Fear of change
• Apathy

The list goes on, there are a million excuses why it is hard to implement a successful Agile process, but what is worse than trying to implement an Agile process and struggling to do so is slapping stand-ups and sprints on a team, planting your flag and declaring that you have reached the peak of “Agile” and never once looking at your process again. You would probably be better off with a solid Waterfall process than a franken-Agile approach where the very process that is supposed to be helping you build better software becomes a tradition that is performed but brings no benefit.

If you are not inspecting your process and evaluating the benefits of each and every step then you become the walking dead, if you are lucky one day you might wake from it and look around and wonder why on earth you are doing the things you do. Question and analyze it all, even and especially the steps laid out by Scrum. Scrum and its many interpretations is a starting point, it is a great way to get launch into Agile, it provides some nice guardrails, but if after a year your process hasn’t changed you’re probably not Agile. If your teams don’t have variations in the way they work, you’re probably not Agile. Priorities change, organizations change, teams change, technologies change, all of these are reasons to inspect and adapt your process. This applies to everyone.

Change is hard, process change is harder, it comes with risk, but if you are changing for the right reasons then not changing at all is the real risk.

There is No Perfect Process

Look, I’m not saying I’m some kind of process genius (that’s for others to say), but you have to actually try if you want a chance at succeeding. People want to say they’re Agile, it’s cooler than saying they love Waterfall, but you can’t be The Fonz by just wearing a leather jacket (Stand-ups and sprints are the leather jacket in this metaphor and Agile is The Fonz.) The point is you are faking it, and whether you are trying to fool yourself or someone else it isn’t actually helping you create better software.

If you are reading this and you recognize yourself as Badgile, however you got there you can change it. It may not be easy, there may be a lot of challenges to face, but I implore you to try, for your sake, for the sake of your organization and for the sake of your team. Do what you can, get educated, start from Scrum, but really start from it. Understand the philosophy behind it, don’t just implement the ceremonies. If you get pushback, help educate those around you, you are not some lone wolf trying to implement some radical hippy process, you are following some of the best and most successful software companies in existence. You can be like those companies. If you try your best and can’t find a way to change things, my suggestion would be to look for somewhere that wants teams to flex their muscles and spread their wings, somewhere that throws open the doors and provides a culture of trust and freedom. I promise you it will be better!