Designer’s Schedule, Manager’s Schedule
Two summers ago, I was working on a contract with a major satellite television provider to redesign their members’ online experience. My team was brought in to introduce the team to new ways of working: we used design sprints, usage analytics and agile development to de-risk the project as much as we could.
As we introduced our clients to the ceremonies of agile development, we saw the pain they felt when trying to commit to a chunk of work, even for the length of a sprint. One of my colleagues had to frequently and somewhat sternly ask the question “This is different than what we agreed to in sprint planning. Are we Blowing Up the Sprint?”
I respected the question, and Jim’s willingness to ask it. It’s human nature to want to please others, and giving someone a few moments of time here and there doesn’t seem much in the grand scheme of things. But Jim revered the commitments the team made, and he wanted to ensure we could deliver. So when other activities interrupted when a Sprint was in session, he wanted to be sure we were all agreeing to the potential impact.
I’ve never met a product team that didn’t struggle with the balance of Urgent vs Important. An issue from an at-risk customer comes up, a competitor releases something we feel a need to respond to. But as Paul Graham described way back in 2009, interruptions can be a killer to the productivity of someone doing creative work. Sure, Paul was talking about meetings specifically, but he could equally be discussing the impact of changing scope or priorities, especially in the middle of a block of dedicated time.
“This is different than what we agreed to in sprint planning. Are we Blowing Up the Sprint?”
What I loved about Jim’s question was that it forced a conversation. We are pretty accustomed to a development team agreeing to a chunk of work within a given period of time. The agile ceremonies of backlog grooming, sprint planning, daily standups, review and retrospective keep things moving smoothly and ensure a shared understanding of what’s happening.
So when a team chooses to “blow up the sprint” — something must be wrong. Less than (insert your sprint length here) ago, the team all agreed on a priority and course of action. If this change in direction can’t wait even a few weeks to be addressed, then by all means, pull the cord… but be sure it’s worth it!
I’m referring here to the Andon cord, which was part of the Toyota production System. The idea was that if anyone on the manufacturing floor noted a problem, they were encouraged to pull the cord, which would stop all production. It was empowering for workers as they were encouraged to monitor and report problems, and the overall quality of the products improved because things were fixed sooner rather than later.
In her book Thinking in Bets: Making Smarter Decisions When You Don’t Have All The Facts, Annie Duke introduces the term “resulting”. This is the problem of assuming too tight a relationship between the quality of a decision and the quality of the outcome. We can make good decisions that result in bad outcomes, and poor decisions that result in good outcomes.
I introduce the concept of resulting and decision-making, because they describe the two justifications we may give in Blowing Up a Sprint.
1. Fear of a Bad Outcome
Our development team has committed to something and is making progress, but we are afraid that what they are going to release is not going to be valuable for our users.
We could blow up the sprint and direct them to take on different work, but are we confident that what they are redirected to will be better?
2. Fear of a Bad Decision
Our development team has committed to something, but we’ve decided that we gave them the wrong assignment. Something would be MORE valuable for our users.
We could blow up the sprint, but the bigger question is why we’ve changed our minds. Did we get new information that caused us to reassess? What could have allowed us to make a ‘good’ decision earlier?
In my time on product teams of various sizes, I’ve seen teams recover from #1 gracefully. Indeed, it’s a core assumption in software development that design and development are iterative and things will not be perfect right away. When the team struggles with decision-making, however, the team sees a decrease in confidence and productivity with many stops and starts along the way.
Reducing waste is another focus in Lean Software Development. We pull the cord to solve problems quicker, at a lower expense.
Think of the waste involved with blowing up a sprint. Something has made it all the way up to the top of a backlog, through prioritization and scoping and refinement, story-pointing and task-assignment. The team gets to work for a focused period of time.
And then we can’t even wait a few weeks to let them finish what they had planned.
What is wrong with our planning that we let things get to that point? That we decide it’s more important to stop the work and throw it away than let it be completed.
I suspect the problem isn’t planning: it’s managing tasks.
Let’s take a look at the Eisenhower matrix: balancing what’s urgent vs important.
The team should be focused on the most important activity: the backlog prioritization should drive this. Then once the sprint starts, the team should be left to complete this activity. The train has left the station, but it can be redirected in a few short weeks if something else surfaces as more important at the next planning session.
“The word priority came into the English language in the 1400s. It was singular. It meant the very first or prior thing. It stayed singular for the next five hundred years. Only in the 1900s did we pluralize the term and start talking about priorities. Illogically, we reasoned that by changing the word we could bend reality.” -Greg McKeown
Introducing.. the UX Sprint
As a UX designer, I straddle the worlds of product and engineering. I loathe to commit to X hours for a task, but at the same time, I need focused time to do my best work.
UX Design is fundamentally about context: what is the user trying to get done, under what circumstances, how does he measure success, and how can we craft an experience for him while taking into account all the other users of the system?
So it’s VERY hard to task-switch from customer discovery for one feature one day, to rapid prototyping the next, to recruiting for usability testing for something else, to creating responsive mockups for developers.
I see the benefits in the agile ceremonies, and I’ve seen teams try to tie their UX designer into the development teams sprint planning. But as a designer, I can’t give you a realistic estimate of how long til the design is ‘right’. We need to test it and it may take several iterations of design before we’re ready to hand it off to development.
So while the process is valuable, the workflows are distinct. We can’t assume that design can be in Sprint 34 and development can start in Sprint 35.
UX and Product Development should serve the same prioritized backlog, but how do we manage the cadence? I mused about this on Twitter, and John Cutler pointed me to an excellent piece he’d written:
This gave me further things to think about, so I’m going to pause now. To be continued.. but in the meantime, what are your thoughts about how we prioritize and carve out space for UX work?
