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 Honda 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 rugby scrum?
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 5 events, 3 roles, and 3 artifacts.
The foundation of Scrum encourages one-piece continuous flow.
So in a Collaborative Daily Scrum, instead of answering 3 daily Scrum questions, a team looks at the Scrum board and plans on how to swarm or mob to finish the top PBI (Product Backlog Item) on the board.
It may happen, depending upon the tasks identified for a PBI, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next PBI.
Daily Scrum is a sprint planning in small. You replan the sprint every day.
If a team is working like this, there should be couple of stories (depending upon size) in progress at any point in time.
So you see, if a team decides to swarm or mob, one doesn’t require to set explicit WIP limits anymore. The disciplinary act of stopping at numerical WIP limits is not required as that becomes part of the system.
The team focuses on finishing existing PBIs before picking anything new.
As we discuss the key idea of collaboration (swarming or mobbing) here, it’s important to understand that the idea of “swim-lane Scrum” (each team member individually taking ownership of a PBI through the stages of the process) doesn’t really work. It blocks the delivery pipeline as any PBI a tester may work on comes after a few days, a week or so.
At that point in time, a tester may get multiple stories to test at once and may become the bottleneck. 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.
Kanban Mythbusters Series
There are other posts on Kanban Mythbusters series which you may find interesting
- Kanban Mythbusters: Limiting WIP is NOT the Goal
- Kanban Mythbusters: When to Use Scrum and When to Use Kanban?
References
- An Alternative to Kanban: One-Piece Continuous Flow
- Takeuchi and Nonaka: The Roots of Scrum
- The New New Product Development Game
- One Piece Continuous Flow
Lots of discussions happened in LinkedIn on this post. Here are the links:
* https://www.linkedin.com/feed/update/urn:li:activity:6341179432820146176/
* https://www.linkedin.com/pulse/you-need-kanban-scrum-youre-probably-doing-all-wrong-vashishtha/
I think the premise here is what needs a review. As I coach teams and organziations I empress upon them to question everything in a process for continued improvement. Regardless of the words of the Scrum inventors even scrum can be improved! I know blaspheme!
Even for teams that swarm they can use the focus of kanban to swarm one item at a time, which isn’t always the case. kanban concepts typical much way with teams that are looking for ways to improve their scrum process, if we can’t improve the scrum process it is going to go the way of all known changeable processes and be replaced with processes that not only allow change but embrace it! no process is perfect
sincerely
paul
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.
@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).
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.
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.
https://www.google.com/search?q=culture+eats+strategy+for+breakfast