One of the most disturbing trends I have seen over the last few years is the interchangeability of the terms Agile and Scrum. Most people believe that Scrum is a form of Agile. A lot of employers will advertise that they use Agile when in fact they actually use Scrum. If this doesn’t infuriate you, it likely means that you have no idea what Agile actually is, so keep reading.

Let’s start off by defining Agile. While I’m going to paste the content here, you can actually go view it yourself here.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That’s it. That’s most of Agile right there (the rest being here). It’s amazingly simple, concise and quite awesome. Over the years I’ve had the opportunity to develop software in situations that any lack formal processes. I’m happy to say that in those situations I have managed to figure out a way of doing things that can effectively be described by the four bullet points above.

Now, I’ve also had the opportunity to develop software in situations which are rife with formal processes that must be followed. Some of those situations were modeled on the infamous old school Waterfall methodology. Some of these situations were modeled on the fad driven and supposedly Agile like zombie beast known as the Scrum methodology. Both suffer from severe downsides. Both offer some upsides. Neither one is perfect, but neither one is absolutely terrible either.

Let’s be clear: I’ve spent the last three years working in an organization that makes use of Scrum for software development. Refreshingly, individual product teams at my employer have some level of control over how closely they follow Scrum (an approach which is actually modeled after the Agile principles). For example on my first team we made pretty heavy use of Scrum. We did sprints, planning poker, story points, burn down charts (for a time), grooming, retrospectives and three amigos among other things. In my current team we only do sprints, partial grooming and retros. Everything else is ignored.

Sadly the one part of Scrum we can’t ignore are the sprints, which just happens to be one of the worst parts about it. That’s because the every product team has to demo their work on the last day of their sprint. So whether you subscribe to Scrum or not, you are pretty much going to end up segmenting your work into two weeks chunks just to appease the powers that be who watch every single demo.

The reality is that the notion that every properly sized piece of work can be completed within a two week period is so idiotic I barely know how to begin my rant. While I believe in “Release Early, Release Often” (which is also embodied as part of the Agile principles), I am unwilling to setup an arbitrary time line that most be followed regardless of the circumstance. The reality is that a lot of the problems we are tasked with building solutions for can be broken down into smaller chunks of work that can be completed within a two week period. But the reality is also that there are larger more complex problems that simply cannot be broken down into smaller chunks and therefore are not easily ingestible by a Scrum like process.

After sprints, the next dumbest thing about Scrum has got to be the story points. If I could go the rest of my life without ever having to measure anything in terms of story points ever again, I might just die a happy man. What is a story point? Fuck if I know. It has no real intrinsic meaning. The team is supposed to determine it’s meaning. Meanwhile brain dead MBAs like to use them to compare performance between various product teams despite the fact that they are totally meaningless. On my first team at Paylocity I remember hearing my PTL complain on multiple occasions that our teams story point velocity was lower than that of other product teams. Why was he complaining? Because the people above him were complaining.

Of course the idiocy of story points feeds into the idiocy of the burn down chart, velocity and planning poker. On my first team we used to play planning poker with this app. By far my favorite part of that app was the fact that it was easily hackable (no server side security for point estimates) and the fact that people are so hopelessly addicted to this stupidity that they are willing to pay for the privilege of using this application.

As for the burn down chart, do I really even need to go there? It’s basically a graph of how story points are added and removed from a sprint as stories are pulled in from the backlog and completed by the developers. But since story points are intrinsically meaningless, the burn down chart is also meaningless. Thankfully at some point even my first team at Paylocity decided to give up on this particular mechanism.

So here is the real question: How is any of that crap Agile? The very first point made in the Agile Manifesto is:

  • Individuals and interactions over processes and tools

Scrum is the exact opposite of that. This leads me to my conclusion: Scrum is the antithesis of Agile. If you are doing Scrum, you are not doing Agile. Don’t believe me? Fair enough. I am just some random guy with a blog. There are lots of people who are far more eloquent than I am, who make a very compelling case for the same exact point.

Bottom Line: There is always a better way to do things. Sometimes doing things better requires less process rather than more. The inability to understand this is really a problem in the tech industry as a whole. We tend to rely on process in situations when we are surrounded by people who have tendency to not meet our expectations. Process becomes the hedge that we fall back on in order to save ourselves from the people. If I had the power and the choice, I’d prefer to surround myself with talented, dedicated and reliable people with the freedom to act rather than mediocre people who need to be herded like cattle.