How to keep WIP down with swarming in Agile/Scrum teams?

Question

We are practicing swarming in our Agile/Scrum teams. However, keeping WIP (Work in Progress) down continues to be a challenge. I am familiar with the theory, but I have some questions about the practice and application of swarming.

1. In swarming, how should we arrange the work in such a way that team members do not step on each other's toes?
2. We are able to get designers and developers to pitch in with testing. What can we do to cross-train testers so they can help with the design and development, too?
3. When a story is blocked, the Scrum Master works on clearing it. In the meantime, should we not get the team started on the next story though WIP goes up?

Answer 1

tl;dr Stop worrying that much about the amount of WIP and start worrying about getting the sprint done

At my job we've tried a lot of different things to keep the WIP at it's minimum. We're an extreme cross-functional team with members (8 in total) in six different areas (iOS, Android, .Net, Web, Testing and Design) and we're currently quite satisfied by following the following practices:

• Most importantly: We stopped worrying so much about the WIP as long as the sprint goal isn't in danger. Meaning that we don't really mind our people swarming over all the user stories as long as the goal of getting the sprint is clearly within reach. Of course when possible we all work together on one user story at the same time.
• We took care of the problem with stepping on each others toe by reminding and focusing on the team value more than the value of the individual. The team's goal is the most important thing. That means that working together should become easier by time. It does involve a lot of merging different commits (code based) but the developers get used to it. It does help you to actually hunt the stepping on each others toes, because developers tend to become more cooperative and start doing things like pair programming without anyone even hinting about that.
• Each user story we have a set of disciplines to attach to, so it's clear to, if someone who totally lacks experience in a certain discipline skip the user story. This should be done in a very conscious matter though, and every standup should focus on getting the top ones done so if anyone can help with that the focus switches quickly back.
• We've found testers to be quite hard to pitch in. We did involve them earlier by giving them versions almost after one hour already so they can start testing and sit next to you while you solve some of the issues they've found. Normally we don't produce as much software for one tester so we share a tester with multiple teams, which so far didn't really bring up any problems except of the logistic one (where to place them).

These are just some practices we've found very useful. I know they're not all strict Scrum, but then again, Scrum only works if you apply it within your own domain. For us it works great this way, with your team it might be a bit different.

Answer 2

Swarming Defined

This is one of those buzzwords that cause more trouble than it solves. It sounds awesome, but people needs to agree on a concrete definition before discussing it. Swarming typically means one of two things:

1. "All hands on deck" to address a single user story. This is an extension of the collective ownership idea, and throws maximum resources at a given problem.

2. Grassroots organization around a set of problems, often seen in a Scrum-of-Scrums context. Just like ants swarm around a food source without central direction, swarming is meant to lead to bottom-up solutions instead of top-down directives.

However, swarming should never be a synonym for "death-march." Not every technical or process problem is made better by throwing more people at it, and there's no such thing as a free lunch.

How Swarming Applies to Your Three Questions

In swarming, how should we arrange the work in such a way that team members do not step on each other's toes?

You don't. "Arranging the work" is the polar opposite of what swarming is about. However, you can certainly keep the situation from turning into a game of bumper-cars by keeping your WIP at a sensible level.

Scrum implicitly supports WIP limits through Sprint Planning. Teams should limit user stories accepted into a sprint based on their sustainable velocity. This inherently limits the WIP for the sprint. Some teams further limit WIP by ensuring that only X story points can be on the Kanban board (or in a given column of the board) at any given time.

We are able to get designers and developers to pitch in with testing. What can we do to cross-train testers so they can help with the design and development, too?

This is a collective-ownership issue more than a swarming issue. First, check your capacity; are you sure your testers have enough process slack to spend time doing anything other than testing?

If you're sure that your testers aren't so busy testing that they ought to be pitching in elsewhere, you need to create time in the schedule for pairing, training, and information-sharing. You also need to allocate money towards training time and training materials. In other words, cross-training needs to be baked into your organizational process and your budget unless you want it to remain a slogan about something your company would like to do...someday.

When a story is blocked, the Scrum Master works on clearing it. In the meantime, should we not get the team started on the next story though WIP goes up?

Well, no. The Scrum Master facilitates the communication necessary to clear it. That may mean reporting the problems to senior management, working with other project teams to coordinate resources, or coaching a team member on how to approach a political or process issue within the larger organization.

As for increasing WIP when items are blocked, this is usually a bad idea. Task switching is inherently bad for any process; Scrum is no different. If a story is blocked, the team should focus on clearing the block rather than task-switching away from the problem.

What to Do When "Swarming" Doesn't Work

Of course, some problems can't be cleared in a reasonable time frame or with a reasonable amount of effort. When that happens, the team might consider:

1. Working with the Product Owner to refine the story or swap it out for an equivalent story--but only do the latter if you have sufficient capacity left in the sprint!

2. Working with the Product Owner to remove the story (and any associated points) from the sprint altogether, as long as the Spring Goal isn't compromised.

3. Working with the Product Owner to remove other non-critical stories from the sprint, in order to reserve more team capacity for this (apparently significant) roadblock.

4. If the story was essential to the Sprint Goal, the Product Owner has the option to terminate the sprint early. The team can hold a retrospective to figure out what went wrong, and then return to Sprint Planning.

If team members have lots of stories that you think they can swap around within the sprint, then it's likely you have a process problem with:

• sprint length,
• capacity planning,
• estimation,
• organizational support for the project,
• political support for the Scrum framework, or
• some combination of all of these things.

Since the team should never be pulling more work into the sprint than they believe they can complete within a single iteration, there shouldn't be any "extra" stories lying around waiting to be done.

Answer 3

In swarming how to arrange the work in such a way that team members do not step on each other's toes?

If everybody participates in the swarming and agrees on the next steps, it shouldn't happen. Make the goals/commitments/targets clear and transparent.

We are able to get designers and developers to pitch in with testing. What can we do to cross-train people the other way about?

What do you mean by that?

When a story is blocked, the ScrumMaster works on clearing it. In the meantime, should we not get the team started on the next story though WIP goes up?

If you do that then the whole WIP idea is pointless. If something is blocked and the queue/column/line is full then everybody should work on the stopped/blocked items. If the team cannot do anything with any of the blocked items, you found a huge organisational bottleneck, which won't be solved by increasing the WIP.

Finding the right WIP limit is a challenge, which requires disciple. I remember that we had long discussions and fights before changing the WIP, and at the end we always managed to get rid of the bottlenecks and kept the agreed WIP. Based on my experience, those who aren't familiar with the concept of WIP, won't really understand (or approve) this kind of approach until they fully understand it.

Answer 4

I'll take a stab at your questions from the experience that I've had. Note that my answers are from a more general agile and lean process, not from a strict Scrum view. So while they should be helpful, you will likely need to adapat them.

1.In swarming, how should we arrange the work in such a way that team members do not step on each other's toes?

We often tackle this as part of the prioritization process. We'll try to ensure that the work being started covers different areas of functionality to reduce the need for multiple people to work in the same areas of code. Obviously, this requires some knowledge of the code base during the prioritization process, and requires that there is enough that needs to be done that you can pick and choose.

When you can't avoid stepping on each others toes, one of the biggest things to help is to ensure that people are aware of the overlaps and are discussing their changes. This usually helps reduce conflicting changes.

Depending on the change management process you are using as well as the specific change in question, it may be as simple as having one of the people start by implementing their necessary change to the code in conflict, ensuring that this portion of their change does not negatively impact anything else, and checking in just that portion of their overall change. Then, both sides can continue on.

2.We are able to get designers and developers to pitch in with testing. What can we do to cross-train testers so they can help with the design and development, too?

On most of the projects I deal with, we actively include testers in design, but not in development. One of the biggest helps our testers provide in design is letting the designers know how testable their design is going to be, how long it is likely to take, and what changes to the design can help improve test-ability or reduce time to test. (Obviously there are always tradeoffs, but it at least provides the option up-front during the design phase rather than after the code has been written). The testers also provide input on commonly-overlooked failure cases that they have seen, suggestions for test cases that developers should ensure work before considering development "done", and data sets that will need to be tested against. This is all basically a case of applying what they've learned from their testing, so the only training that should be needed is likely to lie in the realm of communications training.

We tend not to include testers in development as often, though that is generally due to their time being better spent in test or assisting design.

3.When a story is blocked, the Scrum Master works on clearing it. In the meantime, should we not get the team started on the next story though WIP goes up?

Assuming that the blocked story is not the only active one, the team should see what they can do to finish other items already in progress first.

Consider tackling a small bug or other form of technical debt.

Look to see if any investigatory work needs to be done for upcoming functionality.

Starting a new story is the last thing that should be done.