In the Part 1 of “The Fancy Mess of Scrum”, I talked about the flawed intuition behind sprints: how they batch work, obfuscate inefficiencies, and are superfluous in terms of extrinsic motivation. In this post I want to delve deeper into higher order negative externalities that sprints spawn – the consequences of the consequences.

By Reading This Post, You Will Learn:

Why scrum is a mismatch for game development from the word go due to art asset pipelines
How the need to allow time for QA and product owner review creates significant churn
The problem with having developers move ahead on stories in future sprints
How limiting developer throughput extends the flow time of feature development

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.

Batching Has Some Nasty Higher-Order Effects

The batching nature of sprints creates what my friends across the pond would call “knock-on effects” – unintended, negative consequences.

Problems Right Off the Bat

Let’s start with the simplest one: scrum is not neatly compatible with art asset creation. Character models, animation sets, and other asset creation pipelines (generally) do not cleanly match sprint cadences. So, if you try to pigeonhole art assets against a sprint cadence, you’re going to have team members who perpetually either can’t commit or who blow commitments.

Sure, you can make the tail wag the dog. You can mutilate asset pipelines so that they line-up with a sprint cadence, irrespective of the actual time the various processes take. But that’s just imbecilic: you’re forcing the reality to match the process rather than the other (and proper) way around.

So, right off the bat, sprint and game development have compatibility issues.

Churn

Moving on, let’s say you have a two week, ten working day sprint. Awesome! Your devs have ten days to reach their commitment.

But, wait – you can’t just give the product owner a sprint’s worth of work at 5:00 PM on the last day of a sprint and expect her to verify all of it (or assume it’s all defect free, for that matter). She needs at least a day or two to go through the stories thoroughly, among all her other responsibilities. So, in order to facilitate that review, the work needs to be ready a couple days in advance of the end of the sprint.

Okay, fine. So your 10-day development cycle is really an 8-day development. Big whoop. But hang on: if you run QA passes as part of your sprint (which you should), then QA also needs to check the work to ensure it’s defect free. That takes time as well. So your 8-day development cycle is now down to a 5- or 6-day cycle.

This dynamic creates two third-order effects.

Third Order Effect, #1

First, instead of having one deadline (the end of the sprint), you end up with two or three: the end of the sprint, the deadline for product owner review at t-minus two days, and the deadline for QA review at t-minus 5 days. And, in my experience, those micro deadlines create significant churn.

All of your developers rush to get all of their work slammed in for QA review right before the QA deadline. Naturally, the rush to get the work in carries with it a lot of defects, which makes for a hectic QA review/bug fixing process. Then there’s a similar slam of work right before the product owner review deadline.

It’s like doing arm curls with a water-filled weight. Rather than a smooth, continuous motion you’d have with a standard dumbell, you have a lurching arch with its own destructive momentum.

Third Order Effect, #2

Second, your developers are either sitting on their hands for half of every sprint, or they’re getting a head start on the next sprint. That sounds good, until you, once again, recognize that you’re already batching all of your work into two week chunks. So your cycle times are already protracted. If you start working on stories in advance of the next sprint, you are exacerbating that phenomenon.

A 5-day story has a 10-day development cycle in a two-week sprint. As discussed in Part 1, that’s already bad enough (a 50% flow time efficiency). And if you start that work early, that 10-day cycle becomes an 11-, 12-, or 13-day cycle. Or worse. Your flow time efficiency takes a nose dive.

What’s more, getting a head start on work, in turn, carries a fourth-order effect. If your developers are perpetually getting ahead of the next sprint, then it follows that QA and the product owner will accrue a backlog of stories to review. In as few as two sprints (I’ve seen it happen), that backlog might get so big that reviewing these logged jammed stories consumes an entire sprints worth of bandwidth for QA and the product owner. And then what do you have your devs do? Should they take a sprint-long smoke break or get even further ahead of the product owner?

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).

The Pantry Effect

Now, again, there is a counter argument: ideally, the work in a sprint gets finished, tested, and verified at an even, ideal burndown rate. But, the raison d’être of the sprint is to provide little deadlines along the way to keep production moving. And if there’s one universal truth about deadlines, it’s that work compresses in the direction of the due date. It’s just human nature.

Psychologist refer to this dynamic as “the pantry effect”: the more you have of something, the less self-regulation and discretion you demonstrate in it’s consumption. Lots of food in the pantry? Chow down. Lots of time to get work done? Then kick back.

But let’s say you are either so effective at keeping people moving or you have a team that is superbly disciplined at working at a steady clip, either of which is entirely possible. Well, if your team does move in a continuous, harmonious cadence, then a sprint production model is entirely superfluous. If your team is moving at a constant, sustainable velocity, then you don’t need the intermittent deadlines sprints provide. And so you should, once again, simply focus on minimizing the cycle times for each step of your development process.

But, even if that’s the case, you still need to reserve time for QA and product owner review. Even if the review work is evenly distributed across the sprint, it’s places an upper bound on the amount of work developers can pursue. And this still jacks up your flow time efficiency.

The Math of a Constricted Throughput

Okay, so lets assume your developers have a specific throughput of stories (R). For any given groups of stories (I), it takes T time to process the work (T = I/R, according to Little’s Law). If artificially restrict R by limiting what developers can process, and hold the amount of work (I) constant, then, mathematically speaking T must increase.

Example: Your developers could, absent sprint constraints, process 20 story points of scope in a two week sprint. Your product owner grooms at a sufficient pace to always keep 40 points of scope in the backlog on average. That means the total flow average flow time for individual stories, from when they enter the backlog to when they are processed, is 4 weeks. This is your theoretical flow time.

Now, lets say your constrict your developer’s bandwidth to 16 points per two-week sprint in order to facilitate product owner verification. If your product owner keeps grooming at the same rate and maintains 40 points of work, then average flowtime protracts to 2.5 sprints, or five weeks (40/16 = 2.5). Your flow time efficiency has dropped to 80% (2/2.5 = 80%).

Having My Cake and Eating It Too

If you’ve made it this far, you might be confused. I seem to be arguing both for and against restricting developer throughput. For, because it prevents developers from working ahead and then creating an every present backlog of verification work for the product owner (thus extending flow times). And against because it makes your flow time efficiency take a dump (thus extending flow times).

So which is it?

The answer, as one of my favorite professors liked to say in grad school, is “yes”.

This perplexing, damned if you do, damned if you don’t dynamic is exactly why I hate sprints. The creation of arbitrary micro-deadlines has nasty repercussions for efficiency. All in the name of creating urgency. We’re using sprint deadlines to keep them moving, while at the same time creating a managerial infrastructure that slows down flow times.

As the old saying goes, we’re cutting our noses to spite our faces.

Key Takeaways

Art assets don’t map neatly against sprint calendars, which means that scrum already has a lack of alignment with game development
Sprints need to account for the time required for QA and product owners to review stories
That requirement creates significant churn within sprints
It also means that developers will perpetually be under-utilized or they’ll get ahead of the next sprint; either option increases flow times

If You Enjoyed This Post, Please Share It

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

SaveSave

SaveSaveSaveSaveSaveSave

SaveSave

Breaking The Wheel

The Higher Order Consequences of Sprints: The Fancy Mess of Scrum, Part 2

By Reading This Post, You Will Learn: