Pavley.com presents, the penultimate episode of ITSAM! Starring the algorithms of Scrum. The computational thinking that makes it possible to do “twice the work in half the time.”
Last episode, part 4, starred the story point as a data structure of enumerated values and its function as a signal of complexity. Story points are expressed as Fibonacci numbers, ratios of intuitively accelerating magnitude. The humble but nuanced story point is like the pitch of the teeth in the gear that runs your sprint iteration: The finer the pitch (smaller the story point values) the faster your productivity flywheel turns.
In this episode we turn away from story points and take a step back to discuss four unambiguously defined recipes that precisely describe a sequence of operations that drive the Scrum process. Scrum is often visualized as a set of nested loops and we’re going to do the same. These loops take an input state, the backlog, and transform it by iterations, into an output state, working software.
Ah, but there is a catch! People are not machines. We tend to mess with the sequence and order of Scrum operations and derail the efficiency of its algorithms and then wonder why “Agile is dead.”
The algorithms of Scrum
What an algorithm is and is not is critical to understanding how to Scrum. Get it right and the Scrum fly wheel spins faster and faster. Get it wrong and the Scrum fly wheel wobbles and shakes, eventually flying off of its axis.
At the surface, almost any well-defined and repeatable process is an algorithm. Counting on your fingers, singing Baby Shark, and the spelling rule i before e except after c are more or less algorithms. To be a true computational algorithm all variation has to be nailed down. If human judgement is required in implementing an algorithm, as in knowing the random exceptions to the i before c rule, the algorithm isn’t reliable or provable.
Jeff and JJ Sutherland, in their book Scrum: The Art of Twice the Work in Half the Time, don’t mention algorithms. Probably because what I’m calling algorithms don’t strictly fit the Wikipedia definition. But I believe if we refine these processes as close to true computation as we can get, Scrum works well. I believe it because I’ve seen it! So, let’s take a quick survey of each core algorithm in turn–we’re looping already.
The sprint (outer loop)
The outer loop of Scrum is the sprint. It’s a relatively simple Algorithm.
// pseudo-code implementation of a sprint loop
while value of epic count doesn't yet equal 0 {
play planning poker() with highest-priority epic
for each work day in sprint duration {
standup() with sprint backlog for 15 mins
}
demo()
if demo is not accepted {
throw sprint broken error()
}
retrospective()
}I like the idea of the sprint as algorithm because there isn’t a lot of room for human creativity. But there are a few hidden constraints!
- Scrum doesn’t want you to rest or waste time between sprints. Start the next sprint on the next working day.
- Scrum wants the whole team participating in the sprint.
- Scrum doesn’t want you to start new a sprint before the last one has completed.
- Most importantly: Scrum wants all development activities to take place inside the sprint. This constraint creates a huge headache for product management, UX design, and QA as they are commonly practiced.
One reason Agile is dead and Scrum’s hair is on fire is that anything that happens outside the sprint is not Scrum, does not go fast, and creates terrible stories.
For example, designing all your screens upfront with focus groups is not Scrum. Manually testing all your code after the demo is not Scrum. Skipping the demo, adding more engineers during the sprint, or asking engineers to work harder is not Scrum. The sprint loop with its constraints works really well if you don’t do any work outside the sprint!
Planning poker (pre-condition)
The first thing a Scrum team does on the first working day of a sprint is to plan. The core of that meeting is the planning poker algorithm. It takes patience and practice to get right.
// pseudo-code implementation of planning poker
while consensus is not true {
product ower explains story
team asks clarifying questions
for each developer in sprint team {
compare story to previously developed story
estimate work using story point value
present estimate to team
}
if story points match {
set consensus to true // breaks the loop
}
}The goal is to transform an epic into a prioritized backlog for the sprint. That means to break a vague unworkable narrative into a specific, measurable, achievable, realistic, and time-bound (SMART) story-and discovering new stories in the process. The result of planning poker is pre-condition, a state to which the backlog needs to conform, to enable a successful sprint.
In many Agile processes an epic is sometimes groomed or broken into stories before the sprint. It’s an honest attempt to get ahead of the game. But, honestly, breaking down an epic without the team playing planning poker means you get all the bad qualities of Waterfall–the qualities that Scrum was created to avoid.
Daily standup (inner loop)
Have you ever been stuck in a status meeting with no ending in sight and most of the participants in the room paying attention to their phones and not the person speaking? The daily standup algorithm was created to banish the status meeting from the realms of humankind.
// pseudo-code implementation of daily standup
accomplishments = List()
today's work = List()
impediments = List()
timer() start for 15 minutes
for each developer in sprint team {
announce() accomplishments, append to team accomplishments list
announce() today's work, append to team today's work list
announce() impediments, append to team impediment list
}
if timer() rings {
throw standup duration error()
}
}
timer() stopI personally think this algorithm works for all types of work, not just development. Without a strict, formal model to follow, status meetings become planning meetings, brainstorming meetings, complaint sessions, political battle grounds, ad in finitum.
High performing Scrum teams hardly ever drift from the classic daily status formula as described by Jeff Sutherland. Unfortunately, I’ve seen struggling teams given into temptation and turn a good daily standup into a bad trouble shooting meeting. Don’t do it! Go around the room, check the boxes, and follow up with a cool head after all the accomplishments, today’s work, and impediments have been collected (so you know to start with the most urgent issues).
Retrospective (post-condition)
I have to admit that the retrospective is my favorite part of the sprint process. If you do it well and stick to the algorithm a poor performing Scrum process naturally evolves into a high performing Scrum process.
// pseudo-code implementation of daily standup
keep doing = List()
stop doing = List()
change = List()
for each member in sprint team {
// includes product owner, devs, any other core team members
announce() what went well, append to the keep doing list
announce() what didn't go, append to the stop doing list
announce() what needs to change, append to change list
}Like the daily stand up it takes a surprising amount of resolve to stick to the plan and not turn the retrospective into a war crimes trial or a cheerleading exercise. Oddly, the other major problem with the retrospective is lack of follow-up! We get these great lists of things to repeat, to stop repeating, and to change but many times they go nowhere.
It’s important to drive the items on each list into SMART territory so that a manager can do something about them. Noting that “the backlog was not well groomed” or “the stories needed more refinement” just isn’t enough signal to result in a meaningful change. And, of course, there are issues that can’t or won’t change. They have to be worked around.
While the retrospective is very much like a computational algorithm your response to its findings has to be creative and bold. After every retrospective I expect a scrum master to barge into my office, interrupt whatever I’m doing, and hand me a list of what must change. It’s the one output of the Scrum process that an engineering manager can participate in and it doesn’t happen often enough!
As our heroes, the algorithms of Scrum, walk arm-in-arm into the sunset let’s review the basic tenet of we what learned: The more you treat the sprint, planning poker, the daily standup, and the retrospective like the gears in a clockwork engine, the faster that engine runs. There is plenty of room outside of these algorithms but resist the temptation to add value. You’ll probably be surprised at how Scrum works when you respect it and don’t try to fix it.
In our next and final installment of ITSAM I’m going to actually talk about management: If a manager’s job doesn’t involve giving orders, taking temperatures, and holding people accountable–what is her job? Why do we even need managers if we have Scrum?