Back in the heady days of 2010, I was a newly minted scrum master, fresh off my training seminar. I was excited by scrum’s potential, but I also took care to maintain some agnosticism. I always told people that scrum was the best production framework I’d seen, but that I would happily kick it to the curb as soon as I found something better. With several more years of experience under my belt, I’ve come to the conclusion that there are, in fact, better ways of managing development. And with that understanding came the further realization that I want to leave scrum behind.

---

By Reading This Post, You Will Learn:

• Why the sprint cadence is problematic from an operations standpoint
• A better approach to measuring productivity
• Why the intuition underlying sprints is flawed

---

Bruce Lee and the Fancy Mess of Martial Arts

When he developed his own martial art system, Jeet Kune Do*, Bruce Lee said he was motivated by what he deemed “the fancy mess of martial arts.” In Lee’s opinion, the major branches of martial arts – karate, kung fu, tae kwon do, and the like – had solidified what should have been fluid: combat.

Lee, no stranger to fist fights himself, knew from experience that real world combat was messy and unpredictable. And yet, martial arts training had become sterile: obsessed with fixed positions and sequential move sets. Martial arts students weren’t learning moves as a means of self-defense. They were learning moves as ends unto themselves. The tail, in Lee’s opinion, was firmly wagging the dog.

Lee’s view of the stagnation of martial arts served as an inspiration for me to turn a critical eye on my own realm of expertise: scrum. And it turns out that scrum, for all its popularity and effectiveness, has significant structural issues. Some are logistical, some organizational. But all have brought me to single conclusion: scrum is only a starting point for effective project management, not the be all end all.°

Haters Gonna Hate (But I’m Not a Hater)

I am not anti-scrum. It was an essential starting point for me as a project and process manager. It offered a means for me to provide value for employers and clients. It’s a great foundation for effective production. Further, it’s  great foundation for teams looking to improve their modus operandi.

That said, our goal should always be to increase efficiency, not to strictly adhere to dogmatic execution of a pre-defined framework.

A Note

This article assumes a basic knowledge of the scrum framework. Both describing and critiquing the framework in the same post would make for an excessively high word count.

By Design, Scrum Batches Work into Sprints

One of the key elements of scrum is the sprint: a defined time box of work during, in which a team completes a given commitment of user stories. The intuition of the sprint makes sense. Give team members small, incremental deadlines in order to space out work, and also to provide built-in points to review progress and re-calibrate priorities.

But batching is a bad practice. I cover the math in detail in my posts about kanban and heijunka, but the short version is that batching extends cycle times. For instance, let’s say you have a user story that, in total running time, took 5 days, from a dev picking it up, through coding and QA, to product owner verification, to closure. But, it’s in a two-week, ten-working day sprint. So it isn’t considered complete until the product owner reviews it on the last day of the sprint. What should have taken 5 days took 10. In other words your flow time efficiency is 5/10 or 50% – the story spent half of its production life span not doing anything.

Well Then Review the Story Earlier!

Now, of course, the counter-argument here is that the product owner simply can verify the story as soon as it’s ready for him/her. And that’s absolutely true. But, if your team is using velocity (points closed per sprint) as the primary unit of measurement, then as long as the story is closed within that sprint time box, the inefficiency will not be apparent. The team met its commitment, so further inspection is not required.

To put it another way, if the primary measure of a team’s effectiveness is velocity, you are obfuscating efficiency issues by aggregating those points in multi-week clumps. To put it still another way, if you base your ongoing sprint commitments against the velocities of prior sprints, you are letting inefficiencies fester. Your are comparing inefficient apples to inefficient apples.

Yes, a good scrum master should constantly be pushing his/her teams to improve its velocity. But velocity at the sprint and even the story level aggregates the impacts of multiple factors. And the devil, as they say, is in the details.

What You Should Do Instead

Utilize a continuous flow process: products owner(s) groom stories (with input and feedback from the team, and then add and prioritize them in the backlog. Available developers grab the story that’s at the top of the backlog, execute it, and repeat. Mangers evaluate performance by measuring the cycle time (how long a story spends in a given state) or the point velocity at each step.

For example, break up the entire life span of a story into logical activities:

1. Grooming
2. Ready for Development
3. In Progress
4. QA Review
5. Product Owner Review
6. Closed

Then measure the individual speeds of those activities. For example, if you wanted to analyze the Grooming activity:

• Calculate the cycle time: the average time to groom a story is 5 days
• Or measure the velocity: 40 points of scope move from “Grooming” to “Ready for Development” per week

Finally, focus on reducing those cycle times or (increasing those velocities) through better processes or better balancing of resources.

---

Resources That Informed And Influenced This Post

If you have ad blockers turned on, you may not see the above links. Breaking The Wheel is part of Amazon’s affiliate program. If you purchase products using the above links, the blog will receive a portion of the sale (at no cost to you).

---

But What about the Notion of Sprint Commitments?

First off, let’s review the rationale behind sprint commitments.

Rationale #1: Provide Accountability for the Team to Process a Given Amount of Work in a Given Amount of Time

This rationale is fair enough. But let’s take a discerning of view of the efficacy of that accountability. Knowingly or otherwise, by using a commitment model, you are attempting to leverage what psychologists call “self-consistency bias”. People prefer to act in accordance with their established view of themselves. So, if the team establishes a view that it will get a given amount of work done within a sprint, it will be more likely to complete that amount of work so as not to violate it’s own collective sense of self consistency.

But is a sprint goal really necessary to trigger that bias? You can just as easily utilize the same bias by getting the team to commit to a given velocity over time (or average velocity), or constantly compare the current velocity to recent velocities (eg, the past two weeks versus the two weeks before that).

Rationale #2: Provide a Deadline

Have you ever wondered where the term “deadline” comes from? The etymology is actually pretty grim. And literal. The American Civil War suffered no shortage of horror. But even in that context, the Andersonville prisoner of war camp stands out as especially atrocious. And that camp featured a line past which any prisoner would be shot on sight. Guess what they called it?

Even without that background, a deadline carries an implicit threat: get your work done by this date, or else. Or else a bad grade, or delayed payment, or penalty fees, etc, etc, etc.

But, here’s the problem with threats: if a threat isn’t carried out, further threats are meaningless. Your bluff has been called.

So, what happens if a sprint commitment is violated? Well, you can go the straight-up nuclear option of an abnormal termination  and revert all changes in the sprint. But show me dev studio, cash strapped and cranking to towards its next milestone payment, that’s really going to bite the bullet on that one. An abnormal termination is one of those ideas that makes sense in an academic, behavioral economics sense, but in actuality is cutting your nose to spite your face.

There are other options, of course. But my point is this: while deadlines can provide intrinsic motivation in the form of the self-consistency bias, they are only useful as extrinsic motivation if there is a distinct, painful, and certain consequence for failing to meet them. If you are not willing to drop that hammer consistently, the deadline tiger loses it’s teeth.

And if that is the case, then, again, why is a sprint commitment superior to a target velocity commitment?

Rationale #3: Upward Management

Commitments also serve as a check against management running rough shod over a team’s focus and bandwidth. The team elects to work on the things they can reasonably deliver in a particular window of time (which is as it should be), and management also commits to not screw around with the team’s priorities for that window of time (which is also as it should be).

Again, perfectly logical, but there are some implied problems here as well. First off, the need for a commitment device from managers is a damning allegation against those managers. The fact that we need some sort of buffer to control the impulses of product owners (and we often do) speaks to a severe lack of discipline on their part. It also implies a lack of understanding on their part of how damaging randomization is to developers’ productivity. And I’ve witnessed both failures multiple times.

The above isn’t something a rank-and-file scrum master or developer will be able to solve single-handedly. But sprint commitments seek to treat the symptom (randomization). We as managers or scrum masters, we always need to be focused on the root cause and finding was to alleviate them.

We’re tying our own hands

And in implementing this fix for a symptom, we also constrain our ability to respond to change (which, I’m told, is more important than following a plan). Especially in these days of multiplayer, micro-transactions, an live service, the needs of the organization might be more urgent than the next sprint will accommodate.

Instead of agreeing not to change the stories in a print, you can run a continuous flow process. Then, establish the rule that the product owner can’t tamper with any work that’s already in progress, but can re-prioritize the backlog at any time. Team members will simply pull whatever is at the top of the backlog when they are ready for more work.

This is the process I’ve used for a year and a half and it works incredibly well. Product owners feel like that have increased flexibility as far as tweaking priorities, but developers are still able to focus on one story at a time without fear of randomization

---

Further Reading If You Enjoyed This Post

Lean Development for Games – Game Planning With Science! Part 9

Video Game Art Pipelines – Game Planning With Science! Part 1

The Time Value of Fixes, Or: A Fix in the Hand is Worth Two in the Bush

---

But Wait There’s More

I’m not quite done grousing about sprints. Beyond the flawed mechanism of the sprint itself, there are negative second-, third-, and even fourth-order effects that you should consider. And that is what I’ll be addressing in my next post. Stay tuned.

---

Key Takeaways

• The sprint-based nature of scrum creates multiple operational issues
• Cycle times are arbitrarily extended, reducing flow time efficiency
• The various rationale for sprints are based on flawed premises
• A sprint-based system is not the only way to satisfy the tenants of agile

---

If You Enjoyed This Post, Please Share It

*Translated as the “stop fast method”

° With apologies to Spock for lifting his line from Star Trek VI

“The Flawed Logic of Sprints: The Fancy Mess of Scrum, Part 1” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.