Q:

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

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.

In swarming, how should we arrange the work in such a way that team members do not step on each other's toes?
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?
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?

A:

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.

A:

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:

"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.
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:

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!
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.
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.
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.

