Pivots: A Scrum pattern for design projects
In 2015, I worked with a team of seven amazing students and Olin’s new Library Director, Jeff Goldenson, on a summer design/build project called the “Olin Workshop on the Library” (OWL). The project was about designing new life into Olin’s library space and the resources it provides to students. We started with a mantra (a la Guy Kawasaki): “Make Olin’s culture manifest.” It was the highest performing team I’ve ever worked on, and at least part of that had to do with the process we committed ourselves to 100%. This post is a reflection on that process and an effort to distill some key lessons learned.”
The summer of 2015’s design/build project was fast-paced and intense. We had just nine short weeks to begin to transform Olin’s library into a more dynamic community hub of active learning and innovation. To manage the project we chose, as a team, to use Scrum for the reasons I’ve already outlined in another post. Along the way we discovered/created a very useful pattern that I’d like share here.
I’m calling the pattern “Pivots,” but it’s based on an existing pattern called the “Interrupt Pattern” devised by Jeff Sutherland. The interrupt pattern acknowledges that it’s impossible to anticipate all the work that will need to happen during the sprint. To handle unanticipated work, the team agrees to put an “interrupts” buffer in the product backlog and size it appropriately. If 30% of the work that happens during a sprint is unplanned, then maybe the interrupts buffer is worth 30% of the total points for the sprint. Every interrupt request (typically external requests of the team) must be approved by the Product Owner, sized by the team, and subtracted from the buffer. When the buffer is empty, no more requests can be accepted without breaking the sprint.
“Pivots” are slightly different, but the intention is still to make Scrum more flexible, particularly in a creative/design context with greater uncertainty. Because design work often contains significant ambiguity and might shift directions quickly, we need a mechanism to enable the work to shift a bit during a sprint. Similar to the interrupts pattern, we create a pivots buffer with the same rules as the interrupts buffer. Because the pivot is initiated internally, the team must decide if it’s worthwhile enough to execute and subtract the appropriate points from the buffer.
A key conceptual difference between a pivot and an interrupt is that interrupts are usually imposed on the team by someone external to the project, whereas a pivot is generated internally by the team or some subset of the team. This can mean that work further down the Product Backlog is impacted. For example, one side effect of a pivot is that other stories in the sprint may well become unnecessary depending on how well-defined and granular those stories were, to begin with. Though we haven’t implemented it yet, I could imagine taking those story points and adding them back into the pivots buffer as they become irrelevant to the project direction.
If all of this sounds like a way to redefine work during the sprint, well, it sort of is. The very goal of design work is gaining a deeper understanding of your problem or user through empathizing, prototyping, and iterating. And, sometimes those iteration cycles don’t align with your sprint timeline. I’ve found it far more productive to try to adapt Scrum (despite Sutherland’s admonitions that a desire to adapt Scrum is an indicator of deeper organizational troubles) than to abandon it altogether.
Bottom line: it can be a struggle to make Scrum work really well in creative contexts, but I still firmly believe that the basic emphases on transparency, accountability, shared definition of done, and continuous improvement ultimately make for very high-performing teams regardless of the end product being produced.