So let me just say upfront that I’m a huge proponent of agile (little “a”) development practices. The Manifesto for Agile Software Development, and its aftermath, changed the way I thought about building software. As a company, agile software development is at the core of everything we do, and it is the inspiration for many of our values.

If you’re here reading this, I probably don’t need to tell you about the Agile Manifesto, or how radically it changed the world of software development. Ideas such as continuously and iteratively delivering working software, embracing changing requirements, building projects around individuals, working software as the primary measure of success, etc… were all somewhat heretical to the way most software was being built at the time.

A while after the Agile Manifesto arrived there was a flood of interest in different methodologies all rallying under the agile banner. Of these, the most successful up to this point has been Scrum. To be fair, Scrum predates the agile manifesto by a number of years, but it wasn’t until after the agile manifesto was released that interest in it really took off (Ken Schwaber and Jeff Sutherland were initial agile manifesto signatories).

And they were right, treating software development as a process that could be easily predicted, planned, and estimated up-front wasn’t working out.

And they were right, treating software development as a process that could be easily predicted, planned, and estimated up-front wasn’t working out. Many methodologies came along that tried to layer more and more process on, but what the agile manifesto seemed to be telling us was that we needed small teams of high performing individuals who could self-organize and focus on creating working software. The idea was that the closer to “the edge of chaos” a team could get, without losing order, the better off the end result would be. The translation…use as little process as you need, while still maintaining some control.

The idea seems obvious in hindsight, as all great ideas do. Process exists to control how things get done, but the more there is, the more it gets in the way. As little process as needed, and no more! Unfortunately many in the world of software project management weren’t looking for a really lightweight process that would allow more autonomy. They were looking for a new process, or had this new process forced upon them, and for them it became a rigid set of processes with only a single way to operate. Unfortunately the Scrum guide promotes this by stating “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”

The idea was that the closer to “the edge of chaos” a team could get, without losing order, the better off the end result would be.

Seeing this rigid adherence to rote process quickly led me into the trough of disillusionment on my own personal hype cycle with Scrum. I started to see Scrum as the dream of a micromanager, and detrimental to a high performing team. I imagined the process that went through Scrum master’s minds was something like… “I know what we will do, we will get the developers to overcommit to a bunch of stories, shove them into a ‘sprint’ (I still have issues with that term), put all of their progress up where everyone can see it, and then repeatedly ask them over and over what they are doing. Then at the end of the ‘sprint’, while they are working their butts off to wrap up their work, we will herd them into meetings to start thinking about how they can overcommit for the next sprint!”

As you know, that view of Scrum is clearly tainted. Scrum is a process, and like all processes, Scrum can be abused. But if that is the case, how can we criticize Scrum? You see, processes are hard to argue against because processes are often only as good as the people who implement them and all failures can be attributed to “not properly following the process”. So you get into a situation where arguing against a process is mostly futile, for people who use the process and have had success with it, you’re full of crap. For those who have used it and struggled, it is +1’s and high fives all day long.

That doesn’t change the fact that the above description was clearly hyperbolic. It doesn’t follow the spirit of agile or Scrum at all. Unfortunately though, this is how Scrum is leveraged in a lot of places, and sprints literally start to feel like sprints. Every week, week after week, running as fast as you can to keep up with unrealistic goals and deadlines. Most people that have experienced more than a handful of bad “agile” projects will bring up the term sustainable pace quite a bit. Cause at the end of the day, building software is more akin to a marathon than a sprint, we need to find a solid sustainable pace to get us through to the end.

…building software is more akin to a marathon than a sprint, we need to find a solid sustainable pace to get us through to the end.

So where does that leave us? I know what you’re thinking, “You said you didn’t like Scrum, then you said the process wasn’t to blame, and then you said we should develop software at a sustainable pace. How does this keep us from creating bad software?” Well, I’m glad you asked. As with any process, Scrum works only if the people that are guiding the process are operating with everyone’s best intentions in mind. If they aren’t, there are a number of ways in which Scrum can lead to very bad software™. But the process of Scrum itself tends to lead things in a certain direction, and if you’re not looking out for certain patterns, you can fall into the trap.

The Anti-Patterns

Here are a few anti-patterns I’ve come across in over 9 years of practicing Scrum:

• The “No Plan” Plan
• The Rabbit Hole
• Mandated Mediocrity
• Worst Guess
• Point Procrastination

The “No Plan” Plan

Outside of sprint planning, very little work is done at a high level to guide or design the project. This leads to constant realignment, adjustment, and rework. Sure, the whole point of agile development processes are to adapt, but that doesn’t mean jerking the team this way and that because no one has a clear vision. I’ve also heard people say that agile means they don’t need to design anything. Starting without a plan has never led to success.

Feature Obsession (at the expense of technical debt)

There is an overriding obsession with every story having to deliver “user value” and being able to demo functionality. Because of this, there can be an incessant push to deliver feature after feature after feature without break. Unless someone in charge understands the costs, there is almost no value placed on reining in technical debt or any acknowledgement of the tradeoffs in accruing it. Once it starts to reach the level where it starts affecting the implementation effort of stories, you are much deeper in the project and stopping to dig your way out will probably put your project in peril! Without proper engineer practices, the whole system will fall apart. This has led some to call for a return to Extreme Programming practices. This lack of focus on good engineering practices is not endemic to Scrum, in fact Scrum doesn’t mention any particular development practices at all. This is why the term Flaccid Scrum came about, without good engineering practices, does Scrum work at all?

The Rabbit Hole

When you’re pushing stories into sprints, you’re basically saying “this is the work we are going to be doing over the next X weeks.” The idea is that this is a frozen set of functionality that we have agreed upon, and we cannot change it unless we meet with the product owner and decide to change things. The challenge is that as we work on stories, these stories uncover other work or challenges that need to be addressed as separate pieces of work. So where does this work go? In the next sprint? Does it push current stories back? Often it is easiest, and most efficient, for the development team to reorganize work in a way that makes the most sense, but this is rarely allowed or encouraged. This lack of control on the part of the practitioners  can lead to frustrated and demoralized teams.

Mandated Mediocrity

Nothing in Scrum measures quality. I mentioned the term Flaccid Scrum above, and it really has become a big problem in the Scrum world. Scrum doesn’t propose any quality metrics, and when combined with an obsession to complete points, means that if no one is obsessed with quality things will quickly spiral out of control. I’ve heard folks say that bad quality leads to bugs which will cause your velocity to drop, but I have a few issues with that. First, lack of focus on quality doesn’t always lead to bugs, it often just leads to rework or bad customer experiences. Secondly, development teams often take bugs personally and will go to great efforts to fix them quickly and quietly, which means that they sometimes aren’t accounted for properly. By the time the problem gets bad enough to measure as part of velocity, it could be a huge problem. Scrum imposes a process that is proudly business driven, and while I’m not saying we need to return to the days of the “inmates running the asylum”, if we are building software then we need to empower the software engineers to control a part of the process.

Worst Guess

Estimates don’t change the amount of time it takes to get the work done. Repeat after me, estimates don’t change the amount of time it takes to get the work done! Estimates are hard, and I mean really hard. Unless the work has been done before, estimates are often nothing more than guesses. Guesses are almost always wrong in the “it takes longer” direction, since the cause of the estimates to be wrong are unknowns that pop up during development. If we want them to not be guesses, then we have to spend time to make them more accurate, which probably means doing part of the work. This is almost never acceptable, which means that estimates are often way off, and cause a lot of stress on developers and business folks. Are estimates useful? Well, it depends on how you use them, as “order of magnitude” measures, maybe. Unfortunately many Scrum projects end up directly equating points to periods of time because people need to know how long things will take. I have to admit, I’m often guilty of that myself.

Point Procrastination

Rather than tackling the bigger, riskier items up front, teams will feel pressure to rearrange work in order to gather points to fill sprints and keep their burn-down charts looking good. Then you get closer to the end of a project, and for some reason things start getting more and more unpredictable. Another side effect of point obsession is that you can end up rewarding “sloppy but fast” developers and frustrating and pushing out “careful and measured” developers. In most cases, you’ll get what you optimize for. If you measure Scrum masters and developers on points, you’ll get points, but be careful what you wish for.

Wrap It Up Already!

Again, I know what you’re probably thinking, most of these anti-patterns arise because I’m not properly leveraging the process. This is probably true, but I’m more concerned with calling out issues I’ve seen and therefore encouraging folks to be on the lookout for these anti-patterns. Please let me know in the comments if you see anything I’ve missed!