Achieving Swarming In Agile Teams – Part Three


On May 23rd I gave a talk about Achieving Swarming In Agile Teams at Project Society Conference (PMI). Slides are available on SlideShare. And here is the full transcript, organized in three posts…

If you haven’t read previous parts, here are links to Part One and Part Two.

Part Three

Kanban is a process optimization framework. As such, it is applied to an existing process. Even though it features a visualization board – Kanban board – it is quite different that Scrum board. It does not come with prescribed states, as Scrum board does. The number of states depends on actual phases and stages of the process being optimized.

In this example, Kanban is used to optimize a simple process. It has a backlog of items, which are then selected for development, then they go to development (actual implementation and finished implementation queue) after which is item deployed to live system.

Those little numbers in column headers are Work In Progress limits (WIP limits) which mean that no more than that number of items for particular column is allowed at any time in that column. WIP limits are used as optimization mechanism.

So, here is the example flow: Product Manager selects two most important items (because of WIP limit) and put them in “Selected” column. Development team takes those two items and put start working on them. Since there are TWO items and FOUR developers, this represents a swarming opportunity for the team. In order no to have idle developers, they have to come up with a way of working together. This team decided to work in pairs.

Upon finishing their work, the first development pair puts their item (item “A”) to “Develop/Done” column, where it is immediately picked up by deployment team. First development pair goes on and picks up next most important item (item “C”).

However, deployment team seems to be stuck. They have encountered an unresolved dependency, introduced by development pair, so they try to resolve it on their on. They have to work on that item both due to their WIP limit and since it is the most important item.

At about the same time, the second development pair is done with implementing their item (item “B”), but they cannot take any more items before “Develop/Done” column is cleared, since WIP limit for the whole “Develop” column is set to two, and there are already two items in there.

So, the second swarming opportunity for the Kanban team arises – second development pair joins deployment team in resolving the dependency issue.

Even when the first pair is done, they cannot move on with new items due to WIP limit, so they will also join the swarm and contribute to unblocking the flow and help delivering the most important item (item “A”).

In the end, there are multiple benefits of swarming. If you decide to go with it, you will at least:

  • get shared knowledge and shared understanding of the product by the team;
  • increase ownership over the product by the team;
  • innovate more often, at least process-wise, but most likely on product side as well.

If you decide to remove silos, you will get:

  • higher quality because of building the quality in the product from the very beginning;
  • eliminate handover cost.

There are lots of other benefits which I am sure that you can recognize and find in your contexts.

Here is yet another bonus video of one day in team engaging in mob programming.