Why I Hate Scrum

The Problems

My current team has recently adopted Scrum and started with two-week sprints. Issues have already developed and it reminds me of why I hate Scrum.

For this particular rant, I’ll define Scrum as the methodology developed by Ken Schwaber and Jeff Sutherland and documented in “The Scrum Guide.”

In my humble opinion, Scrum is not agile and, in practice, not very flexible. It is not agile because of its emphasis on time blocks for planning, typically two weeks. More on that later. It is not flexible in practice because there are strong adherents to the cause (aka zealots) who insist on following whatever they believe to be Scrum to the letter. The disciples have taken over!

Now let’s take a look at what Scrum is. “Scrum is lightweight, simple to understand, difficult to master.” Oh right, that is just the kind of process I want to adopt: one that is difficult to master. Major strike one against Scrum in my book.

Let’s take a look at the basic terminology: a “daily scrum” and “sprints."

Apparently, a group of dirty men pushing against each other in a big pile is the metaphor for doing your daily routine of making sure the there are no blockers on the project. I prefer something a bet less sporty and a lot less aggressive: a daily standup. Same basic drill of what you did, what you are going to do and no blockers. But without the aggressive overtones.

Now on to sprints. In an industry where burn out from working extra hours is a problem, that is just what we want: a metaphor so management can tell everyone they just need to sprint faster. And then let’s put that in a two-week time box to regularly amp up the pressure to produce more. Looks to me like a great management technique to maximize free overtime from the staff. It’s amazing we don’t have a programmer’s union to clean this stuff up. I myself believe in 40-hour weeks and anything over that should be a rare emergency.

Done

I’m done with Scrum. “Done” is a key term in Scrum that generates no end of discussion. It starts with requiring those “performing the work and those inspecting the resulting increment must share a common definition of ‘Done’." Problem is that for many tasks that need to be accomplished, “done” depends on the task. Not to mention for other tasks, “done” is when the item is acceptable to the customer. “Done” combines with the two-week time box in a particularly nasty way. “A ‘Done’ increment is required at the Sprint Review.” 

So the conversation goes something like this:
“It takes 9 months to make a baby.”
“You have to break the process into two-week increments so we can show ‘done’ at each two-week sprint review.”

 Or the more typical:
“It will take three months to draft that document because we need to add the designs as they are prepared.”
“Then you have to divide the entire document into two-week increments to show that we have an always done document which is ready to deliver.”
“But its not deliverable until the end, so why pretend?”

I entirely agree that every task should have a definition of done. But the definition should be task related and it is entirely possible that determining what done actually looks like might be the first task that needs to be done. Figuring out "Done" is also difficult because the client may not have a good idea of what done looks like. So you may have to define “done enough for now." As one of my colleagues put it, the process for getting to done has to be “not insane." So obviously something that simple can fall apart pretty quickly.

Time Box

Next is trying to fit everything into the time box so we all finish together. The time box can actually vary, but two weeks is typical. The issues with this are pretty well known, so I’m not going into detail here. But some things go faster and some things go slower. When things are done, they are done. And you should be able to ship with the done feature at any time. Waiting for the end of a sprint and a sprint review means waiting to ship a done project. Again, IMHO, Scrum is not agile, it’s a two-week waterfall from hell.

Scrum Master

OK, topical times. I’m writing this at the time of the Black Lives Matters protests. “Master” is often seen in racist terms. Good reason right there to stop using that.

What is a “Scrum Master”? “The Scrum Master is a servant-leader for the Scrum Team.” OK, master/servant: take your pick racist or kinky sex metaphor. What the Scrum Master really is is the project manager stripped of the ability to manage the project. I want no part of that. Good leaders empower their team which is what I think servant/leader was trying to get at. But there are times when something needs to be done and a project manager can make the changes and get it done. A Scrum Master has to meekly explain to leadership that the next opportunity to save the ship will come in a week and a half at the next sprint review so you’ll just have to put up with the uncomfortable water around your feet until then. Yuck!

Formal Events

Scrum defines four formal events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. While I like the basic concepts, I don’t like the huge time sync associated with these events. I don’t like meetings and I like non-productive meeting even less. 

Sprint Planning brings with it all kinds of ways to figure out how long something will take in order to get the timeboxing straight. Waste of time. It’s still a guess and trying to figure out how to fit in the two weeks is just ridiculous. I have even heard of teams adding less important tasks to round out the sprint. I think tasks should be worked in order of priority, not in order of fitting into a time box. 

A daily standup is a really good idea. Calling it a “Daily Scrum” is not. 

Reviewing what is happening on a set schedule is a really good idea. Requiring everything to be “done” at every review is not. 

Sprint retrospectives do not need to be done with every sprint. They need to be done when there is something of note that you want to understand and decide how to do better. 

Team 

Scrum is infused with “team.” Maybe that is where they came up with the idea of using Scrum: rugby is a team sport. Everything should be owned by the team and the team should rise and fall together. Where is Ayn Rand when you need her? 

I believe in individual effort and that individuals should get credit for their efforts. This is one of my core beliefs and IMHO, Scrum tramples on that belief in a huge way. I believe team members should help each other and I do believe a team succeeds as a group. But I don’t really like the idea of well-performing team members covering for poor performing team members. That is a guarantee that those will performing team members will soon be working for a different company and you will have self-selected poor-quality team members. 

And the concept that every team member can do every other team member’s job demotes specialists to brick layers. 

Some effort has to be done to reduce the risk of a team member leaving (increase bus factor above 1) and cross-training is great, but it can only help so much. One of the best reasons I heard for pouring details into a Kanban is so that if you hire a replacement, they can figure out what to do. But that has to be weighed against the time spent to make sure all notes are clear: I often can’t figure out some of the obvious notes I made two weeks ago.   

I also reject the concept that every team member should have an equal vote on everything. If I hire someone who is a seasoned expert with thirty years of experience and 5 folks straight out of college, I expect the expert to provide expert guidance, not be outvoted by the novices. I guess I’ve come to the conclusion that I really don’t like “self-organize” because what I see endless debate to bring about that “self-organization.” And since the teams disassemble and reassemble at a fairly rapid pace wherever I’ve been, I just don’t see the return on investment on all the “self-organization.” 

Which brings me to another point: I believe Scrum was deliberately set up to be leaderless because the leadership encountered at the time was clueless and did not function well. I think you just need to train up better leaders, not give up on the concept entirely. The Military is built entirely around building a leader and leadership and is very agile when needed, and when given the freedom to make on-the-spot decisions. Perhaps as an industry we should work more on what a good leader looks like than trying to invent methodologies that deliberately remove leaders and leadership as a quality. To me it seems entirely rudderless. 

Scrum is Not a Team Player 

Scrum works best when the team can deliver a discrete product with no dependencies. Because dependencies kill time boxed schedules. And require cross team coordination. In the Scaled Agile Framework (SAFe), you get to the time boxed scrum teams by having an “Architectural Runway” filled with “enablers." Great. Except how exactly do you build that “Architectural Runway”? Hmmm… 

Working Software 

Scrum is based around dropping working software every two weeks. For some projects (web front ends) a short identical cadence works well. For other projects (avionics) it doesn’t work at all. Most projects I have worked on don’t fit that model at all. You can usually show progress weekly, but rarely do I work on projects where something is potentially shippable every two weeks. “Look, the landing gear is here and working. Do you want to ship?” Mind you, I do love having working versions of subsystems at the earliest possible time and then mature their capabilities and add more subsystems. But the real problem I have with the working software model is that it gives short-shrift to planning and documentation. At best, you get something like a planning sprint. So you have two weeks to do planning then you can forget about that drudgery. And after that two weeks, don’t plan or document, just code, code, code. While I’m a firm believer that coding is the final design step, I don’t believe that code is the only design step. For almost any task, I expect to see some design before coding. 

And after coding you need to write enough documentation that the author could at least figure out where to start if a change is needed or the code needs to be reused. In fact, that is my classic answer to “what do we need to document”: If you can’t easily figure out the code the next time you go into it, document whatever you figure out. 

In fact, that is a major problem I see with a lot of open source projects: there is no high-level design or architecture so it is almost impossible to figure out how to use. Each API may be well documented, but then you can’t figure out when to use what API for which purpose. 

Hack and Hope 

The lack of written design that often occurs in Scrum leads to a software development methodology I refer to as “hack and hope." Instead of working to figure out a semblance of design to guide the group’s effort, there is a group grope called sprint planning. That results in some individual taskings and maybe a notional design. From here, go hack away at your problems and hope it comes together at the end. And since you are doing things two weeks at a time, not much reason to think in advance of what you will need in a couple of months. So suddenly when you finally figure out you need something ($, server, software, firewall port opened) the normal approval processes become blockers because you were hacking and hoping instead of doing sufficient foundational design. 

User Stories

I’m not even going there. Here is a smattering of why user stories aren’t the be-all and end-all.

• User Stories are bad… M’Kay?
• Why technical user stories are bad
• You’re doing Stories wrong!
• User Stories are Not Enough for a Great User Experience
• Not Everything is a User Story
• Enough with the User Stories already! 

What to Do Instead: RAD Rapids Revised 

I like to use my own methodology called Rapid Application Design (RAD) Rapids. It comes from a variety of techniques from the late 1990s and predates agile. I documented the second version in 2001. That’s a bit after scrum got started and is contemporaneous with the Agile Manifesto.   

But wait, you say, that paper doesn’t actually provide me with a methodology! That was a deliberate choice on my part. I want folk to pick the best tactics, techniques, and procedures (TTPs, OK I worked in DoD too long…) from among all of the methodologies and apply them as makes sense in your context. It was my belief that trying to state a single methodology was fruitless for two reasons: 

First, it will become outdated pretty quickly and I’m unlikely to try to keep it up to date. RAD Rapids is what I produced when I realized that my former paper which had an actual methodology was much too limiting. 

Second, if you state a methodology, adherents will begin to focus on enforcing the methodology as prescribed instead of flexibly applying its tenets to their current project. So I dumped the methodology and kept the tenets. 

Since 2001 many new TTPs have come out the help with software development. In my current project I have found the following to be most helpful: 

• Daily Standup – Pretty much like the description of a Daily Scrum. In our case, our Government product owner is usually in attendance. That is great!! At first, we were getting corrective guidance on the general direction of the project. Then our product owner became our blocker remover in chief. So we have extreme transparency: daily! However, the daily standup must be strictly limited by time (ideally no more than 15 minutes) and topic (only things that affect more than two of the participants should be discussed; those that involve only two can be handled outside the meeting). 
• Kanban – Having a priority list of things is extremely helpful. We are not time-boxed, so folk get things off the list as they finish their prior task. I’m still new to this particular TTP, but I like it so far. 
• Weekly Show & Tell – Not being time-boxed, our weekly review serves the same purpose as a Sprint Review. A significant feature is the “Show & Tell” where team members show off significant accomplishments. Even if the thing accomplished is not yet done. It really goes far to show progress, and it instills pride and confidence that the project is moving forward. The team member does the Show & Tell themselves, getting the individual credit for the work.