If You Need Kanban in Scrum, You’re Probably Doing it All Wrong!!!

by ShriKant Vashishtha

Rugby Scrum

The original idea of Scrum came from a 1986 HBR article “The New New Product Development Game“, written by Hirotaka Takeuchi and Ikujiro Nonaka. The teams at Toyota and elsewhere reminded Takeuchi and Nonaka of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

So what’s so significant about Scrum? Why do we call it Scrum and not Cricket, Swimming or some other game?

It’s just because in rugby Scrum, the ball gets passed within the team as it moves as a unit up the field. Scrum is all about everyone doing everything all the time. It’s an important point to remember as otherwise Scrum becomes yet another framework with 4 ceremonies, 3 roles and 3 artefacts.

The foundation of Scrum encourage one-piece continuous flow. So in a daily Scrum, instead of answering 3 daily Scrum questions, team looks at the Scrum board and plans on how to swarm to finish the top story on the board.

It may happen, depending upon the tasks identified for a story, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next story. Daily Scrum is a sprint planning in small. You replan the sprint every day.

If team is working like this, there should be maximum 2-3 stories (depending upon size) in progress at any point of time, depending upon the size of the story.

So you see, if team decides to swarm, one doesn’t require WIP limits anymore. The team focuses on finishing existing ones before picking anything new.

As we discussed the key idea of swarming here, it’s important to understand that the idea of every team member picking one individual story to work on doesn’t really work. It blocks the delivery pipeline as any story a tester may work on comes after a week or so.

At that point of time, a tester may get multiple stories to test and may become bottleneck as there may be too many things to work on. That kind of scenario is not the ideal state of flow but is more like a Scrumfall in which work arrives in a batch after a period of time.

References

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  

{ 6 comments… read them below or add one }

ShriKant Vashishtha November 30, 2017 at 1:24 pm
Bob Lieberman November 30, 2017 at 9:18 pm

Great point, and I think you may have made it too strongly. Scrum teams who have problems meeting forecasts, often have process problems that lean analysis makes painfully obvious. Two examples, often related:

1. Too many stories in progress
2. Queues, bottlenecks, or dependencies on external parties

For the skeptical, it can be helpful to set a very small WIP limit for the team (as an experiment) and see the effect.

The ideal of the entire team swarming to finish the top story on the board is very rarely reached. And its usually because of the domain, the code, the skills, and other factors. So while the team is striving to reach that elusive goal, they still need help and visualization tools. Kanban/Lean/WIP is very helpful, you just have to use it well.

Reply

ShriKant Vashishtha November 30, 2017 at 9:47 pm

@Bob if team swarms and pair-up, there will be max 2-3 stories (if small) or 1-2 stories (if big) in progress which will get completed quickly.

You can identify dependencies on external parties as part of Definition of Ready during backlog refinement. I am not sure which queues or bottlenecks you are talking about.

If team pair-up, team becomes cross-skilled or T-shaped and you fix everything mentioned (domain, the code, skills etc).

Reply

Steven Gordon December 1, 2017 at 1:50 am

Why is it important whether swarming reduces WIP or reducing WIP induces swarming?

Which is the most effective way to get a team swarming on just a few stories at a time depends on lots of contextual and cultural factors best left to the people working at that place and time to work through.

Reply

ShriKant Vashishtha December 1, 2017 at 9:08 am

First thing first, to me swarming (read collaboration, i.e. pairing, swarming) is the way to do Scrum, the rugby Scrum from where this whole concept came.

Second, mechanical WIP limits requires lots of discipline and leave work they have been doing. In practice, not many people following the same. Swarming is natural way to keep WIP in limit and requires no change the way people work by default.

For just a few stories, the way we swarm is to take each story in context during daily Scrum and let team decide how many pairs are required to work on the story based on the complexity and size of it.

Not sure if I understand the contextual and cultural factors you mentioned.

Reply

Steven Gordon December 2, 2017 at 6:28 pm

Leave a Comment

Previous post:

Next post: