Alternate title: Most Scrum teams need a Kanban board
I am a big fan of Scrum, however, the notion that there are no interruptions during a sprint is simply not realistic in many environments – especially teams adopting Scrum.
Let’s dream of perfection
A key concept from Lean is to dream of perfection. In this case, perfection is “no interruptions”. This is good as a goal but not as a starting point.
Deliver Value
Let’s face it, there is a lot of business value in keeping a production environment up and running. Almost universally, this is more important than getting that new feature out. Unfortunately, this value is usually a form of waste since there may have been things that we could have done to avoid production issues in the first place. It even has a name: failure demand. When we dream of perfection, we dream of zero production issues.
Oops. We live in a world where there are external events. Yep. It’s true. Even Scrum teams. Maybe it’s more useful to drop a story or shallow out some functionality when some important external interrupt happens rather than abort the entire Sprint.
Ken Schwaber told the story of getting kicked out of a client close to home for attempting to veto the company picnic in favour of focus on the Sprint commitment. I keep telling the teams that they are part of a bigger picture and they need to be in tune with that.
I follow the rule of letting Product Owners swap out unstarted stories for new ones if the team agrees. This comes from XP. Darn, broke another Scrum rule in order to maximize business value.
A separate support team is an anti-pattern
I keep getting asked – hey, can’t we have a separate support team? Then there won’t be any interruptions. NO! Funny thing is that most technical folks don’t want to be on the support team. But the main reason is that it is very useful to have people developing software fix their own bugs and appreciate what it takes to get something working in production. Otherwise defect rates will climb steadily and that’s the wrong direction to go. We want zero defects, not more.
Most Scrum teams need a Kanban board
For as long as I can remember most teams I have worked with have had a support board where we track the actual hours spent on support. Why actual hours? This gives us history and the ability to predict support workload – very handy information during a Sprint Planning Meeting.
More recently I have used a Kanban board for managing support issues. See sample photo below.
So now, my thinking is that most new Scrum teams probably need a Support Kanban. How about at your company?
