Swarming on a problem is typical for teams, especially when there is a high degree of complexity or a high degree of uncertainty on how to proceed. Or perhaps there is just a significant amount of excess work in progress, creating a logjam on our board, and our team rallies to help each other.

Mobbing is the same, except the swarm continues until the user story is done and delivered into our customer's hands.

Just as Kent Beck turned up the dial to 10 for code review and created pair programming, mobbing is the dial turned up to 10 for collaborative cross-functional teamwork. With a mob, we can include other specialists such as testers, user experience, the Product Owner, or other subject matter experts (SMEs). When in a mob arrangement, communication feedback loops close incredibly quickly.

But how can our team be productive when they are all working on one work item at a time, at one computer? Woody Zuill says this is the question that he gets asked the most about the Hunter Industries mobs. However, he realized that this probably wasn't the right question to ask. Instead, he reframed it and asked, "What are the things that destroy productivity?"

Here are some of the things that he listed with my interpretations:

• Communication problems: There are no handovers in a mob, we have all of the people present to carry out the job. If we need information/feedback from outside the mob, we can delegate responsibility to one of the team members to get this, while the others continue to work.
• Decision-making problems: A mob will reduce the chain of command as our Product Owner often works with us directly. Any decisions can be made then and there.
• Doing more than barely sufficient: When we work in isolation from feedback, or our feedback cycles are too long, we tend to make assumptions and end up doing more than is necessary; we over produce. To avoid breaking the Agile principle: Simplicity—the art of maximizing the amount of work not done—is essential, takes discipline; the mob will provide that.
• Technical debt: When working individually, we often create technical debt, sometimes without realizing, sometimes deliberately in the spirit of getting things done. As with simplicity, discipline is hard when we're moving fast—as Blaise Pascall, the 17^th Century mathematician remarked: I have made this longer than usual because I have not had time to make it shorter.
  A mob of programmers is more likely to maintain a no broken windows policy to keep the code cleaner and more succinct. The mob makes it easier to get it right the first time as we're more likely to take the opportunity to refactor. 
• Thrashing: In a computer system thrashing occurs when the CPU is under load, trying to service many requests. System memory starts to become limited as the CPU swaps between tasks in an effort to get as many things done as possible. In this state the CPU begins to slow down as it starts to intensively manage its limited resources. This is a similar situation for a team when it has too much work to-do. A team starts to thrash when its members start to multi-task in an effort to get the work done. The mob helps avoid team thrashing by minimizing the tasks being carried out, focusing the team’s effort on one task at a time. If an individual does get distracted by something deemed urgent from outside of the mob, the mob is able to continue until the team member returns. 
• Politics: This impacts us when different business groups aren't aligned, often pushing and pulling us in different directions via the use of shoulder tapping to coerce individual team members to do their bidding. The group nature of a mob makes it harder for individuals with an agenda to interrupt and distract us, making us more resilient to political overtones.
• Meetings: All meetings become doings or workshops, meaning that our team is never distracted from its work.

Talking about Woody's first point, communication problems, as we mentioned in the previous section, handovers between different team members can cause a significant delay in our process. There are two main reasons for this:

• Availability: It's likely that handovers won't transition smoothly as team members are likely working on other pieces of work. We'll need to wait until they become available.
• Information transfer takes time: As we've already discussed, handovers can lose anywhere up to 50% of the information gathered by the person in the preceding step. Many information transfers result in much signal loss and therefore much relearning.

Lean thinking advocates a single-piece flow, which leads us to minimize the waste of waiting and handovers. Instead of optimizing a single part of the system to maximize local efficiency, we streamline the flow of individual work items across our board.

Mobbing is one approach to software development, which optimizes for flow. So, we don't have to deal with the logjams we sometimes get on our board, as we have on the board example shown here:

We optimize the flow across the board from end-to-end as we discussed when we considered the system as a whole in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle.

This thinking may seem counter-intuitive regarding speeding things up, but in fact, we achieve the opposite, especially when we start to measure the overall end-to-end delivery into our customers' hands, and not just the time it takes to write the code.

With the mob programmers I've worked with, we've observed that a mob is more likely to build more maintainable code with fewer to no bugs coming back to bite us and interrupt essential new feature work.

Overall, the finished product will likely be more robust, so if and when it does fail, it fails within tolerances that are more easily recoverable and with less likelihood of seriously inconveniencing our users. Building resilience in means that in the short term we may take longer to write code, but in the long term, the system is more likely to do what it says it would do on the tin.

One other aspect of mob programming that is important to consider is that this is the team. In Chapter 11, Improving Our Team Dynamics to Increase Our Agility, we discussed how communication and collaboration between specialists were similar to that of a sports team. However, some of the thinking behind good sports team management doesn't always translate well into product development.

For example, one competitive aspect of a sports team is in the selection process where team members vie for their place in the team. This allows the team manager to field the best players and creates a healthy competition (hopefully) within the team as each player seeks their place in the A-team.

In product development, we don't have the luxury of having a selection process, as in the A-team/B-team approach where players vie for a spot in the A-team. In fact, we rarely have the opportunity to pick and field alternative players from the bench as it's unlikely that we have substitutes in the first place, such are the pressures of product development in the modern age.

Even when we do have a pool of talent to choose from, as we all know just adding additional people to a team in the middle of solving a complex problem won't speed up things overnight. In fact, it will likely slow things down until that person becomes embedded in the team; not just forming relationships, but also developing an understanding of how the team works and the problem that it is solving. This has been well documented since Fred Brookes highlighted it in his book The Mythical Man-Month. 

Mobbing allows our team to operate at a sustainable pace, and when people are injured, or not up to their game, the team can continue without affecting the work.