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