Welcome back! In part one, I expressed my dismay that Scrum was conceived with no formal role for management, especially not Engineering Management. I also claimed that Scrum is Agile, that Scrum is not dead, and that Scrum was created long before the hyperconnected Internet we now inhabit came into being. I found that Jeff and JJ Sutherland’s book, Scrum: The Art of Doing Twice the Work in Half the Time, helped me, after years of supporting Scrum, actually understand Scrum.
In this blog post I want to dig a little deeper into how Scrum works from an engineering perspective. When I told my team (in our internet chat room) that I was reading the Sutherlands’ book, one of the comments I got went something like this: “2x the work in 1/2 the time… that sounds too good to be true!”
And you know something? The that engineering manager was right: “Twice the work in half the time” is what a gonzo diet supplement promises. Any engineer with good critical thinking skills is going be skeptical of a process that promises to break the laws of Physics.
But Scrum is not snake oil. I’ve seen it work time and time again. I’ve also seen it fail. What separates a successful Scrum process from an unsuccessful one? And by what mechanism does Scrum accelerate work? Let’s find out!
As an engineer I think of any system, even a human run system like Scrum, in terms of data structures and algorithms. These are the building blocks that determine how a system will scale deal with bottlenecks. We can even apply Big O analysis to Scrum and see if we can predict where it will be efficient, O(1), and inefficient, O(n!).
Scrum at its heart is a computational model for work. In this model Scrum has three primary data structures and four primary algorithms.
| Data Structures | Algorithms |
| The prioritized backlog (a sorted queue) | Sprint (outer loop) |
| The team (an undirected graph) | Planning Poker (pre-condition) |
| Story points (a set of Fibonacci values) | Daily Standup (inner loop) |
| Retrospective (post-condition) |
The well-known properties of these data structures and algorithms help Scrum operate efficiently but also point to why Scrum is hard to scale.
The prioritized backlog
A sorted queue is very fast to access: no searching needed. You dequeue one end to get the current element and enqueue the other end to add a new element. As long as you don’t randomly access elements in the middle of the queue you are always assured to get the element with the highest priority–If the elements are added to the queue in order of priority during the sprint planning process. Access is O(1), aka constant time, whether there is one or one million stories.
This is why Scrum requires the backlog to be locked during the sprint: any addition or subtraction means that all your planning efforts were for naught. Changes to the backlog during the sprint is like randomly accessing the elements of a queue. It means that your story points are no longer relative, the team’s rhythm is broken, and predictability is compromised. This is why, if the backlog must change during the sprint, the sprint is “broken” and must be started over with a new queue of work to do. Range out of bounds error
I don’t know about you, but it’s hard to get the team, including the Scrum Master and Product Owner, to break a sprint. We all just sheepishly adjust the backlog. This is especially true when a high priority story becomes blocked and an engineer is sidelined. Instead of breaking the sprint and re-planning, the engineer is usually told to just grab the next story in the backlog–which ruins the whole queue. Access out of bounds error
Right here we can see a hint of a deep computer science basis to Scrum as it was originally conceived by Jeff Sutherland and his co-creators. We can also see why it’s important to stick to the original conception to get the benefits. If you’re not breaking sprints and if you’re access stories randomly during a sprint the efficiency of this part of the process jumps from 0(1), which is a good as it gets, to some other O(n) like O(n^2) or the dreaded O(n!). Take it from an Engineering Manager: you don’t want to go there!
In the next post we’ll take a hard computational look at the scrum team and prove that less team members is always better than more. If you want to speed up, remove members from the team!