Testing in the Mob

It sometimes feels as if Mob Programming has been around forever, but it actually hasn’t been all that long since Woody Zuill started the practice. As he put it, “Mob Programming emerged from the efforts of a team that was focused on learning to work well together and finding their own ‘better way to work.’ We were studying together, paying attention to what was going well, and discovering ways to turn up the good.”

Since then, the idea has been adapted in many ways. There are numerous different patterns for switching drivers, some with designated navigators and some with whole-group navigation, some that use strict time-boxes and some that don’t. Mobbing has been used as a tool to facilitate cross-team collaboration on an as-needed basis, as a way to share knowledge effectively with multiple teams, to gain leverage when there are few technical coaches available to guide a large number of teams (we use it for that purpose at LeadingAgile), and sometimes as a team’s default style of work on an everyday basis.

Mob testing

In larger organizations where functional silos continue to exist, mobbing has been used to very good effect for software testing. Particularly in the latter stages of testing when multiple systems are involved, it saves a lot of time and reduces duplicate effort to have all testers in the same room at the same time working on the same task together.

The canonical “Agile” guideline is to form cross-functional teams with the skills, resources, and authorization to support one or more products end-to-end. That’s a good model when it’s feasible. A single cross-functional team that can support all aspects of a large solution autonomously may not be realistic in all circumstances, especially in large organizations that have a highly heterogeneous technical infrastructure.

Even if it’s technically feasible, there may be additional forces in play. Established organizations typically have numerous “management fiefdoms” that middle managers are loathe to give up. Often these are organized around functional silos, such that there’s a manager in charge of front-end programming, another in charge of mid-tier programming, another in charge of database management, another in charge of infrastructure, another in charge of functional testing, another in charge of integration testing, another in charge of user acceptance testing, another in charge of performance testing, and so on. These managers fear for their own fate should the organization restructure into cross-functional teams.

Another limiting factor is the ability of individual team members to learn a range of new skills quickly in order to become well-rounded developers, sometimes called generalizing specialists or T-shaped professional, as opposed to “just” a programmer, analyst, or tester. It takes time. Cross-functional teams that comprise a group of specialists and that (usually) continue to have dependencies on specialists in other teams can’t instantaneously take end-to-end ownership of a product.

More than testing

There have been times when I’ve seen more value from mobbing than expected. One situation in particular stands out. In a large bank, I brought together five testing teams to do mob testing. There were 24 participants.

As is the case in many large banks, the systems had evolved over decades, gradually adding more connections and interfaces and data feeds, until the whole conglomeration was too complicated for anyone to understand fully.

The greatest source of headaches in those interconnected systems was that a change in any one system would have downstream effects that no one had anticipated. Most testing was manual, which is also normal in most of those organizations. So it was all but inevitable to have production issues following every release.

The five testing teams were responsible for five key systems. Data flowed through those systems as well as many others. No one person in the organization could explain the data flow from end to end.

At the beginning of the first day, the team members introduced theselves and briefly described the work their team did. Right away it was apparent that no one knew what anyone else in the organization was doing. Each of these teams lived in its own bubble.

I decided that as their coach the best way I could help them was to play dumb. It didn’t require much acting skill on my part, as I was unfamiliar with the systems and the data flow. I asked them to walk me through the entire flow from start to finish.

No one could do that. Each team was familiar only with their small piece of the puzzle. So we started with the team responsible for the first system in the flow. By lunch time we had a diagram stretching across two full walls of whiteboard surface, and a tenuous but improving grasp of the big picture.

As we walked through the process step by step, there were many comments like these:

“So that’s what your team does! I never knew.”

“I had no idea this was causing you so much trouble. We can provide the data in this form instead of that form, if it would help.”

“You mean, your system takes the same data feed as ours? And you need that field? We were planning to delete that field next week!”

“So, this extract flows downstream to that system, and also turns around and gets consumed by this other system at the front of the pipeline? Never knew that!”

“It looks like three of our teams are doing the same thing in three different ways, because we didn’t know about each other’s work. Let’s consolidate that and just do it once!”

Functional silos lead to islands of knowledge, and islands of knowledge often lead to redundant effort, misunderstandings, and incorrect or inconsistent data being passed between systems. Even from the first day of mob testing, these teams were ironing out problems that had plagued them for years.

And they hadn’t even started testing yet.

Conclusion

That anecdote is only the most striking of many. If you think about it, it isn’t surprising that mob testing would be beneficial in large organizations. Such organizations usually have most of the following characteristics:

• Testers are a separate role who work in isolation from analysts, designers, programmers, and others, and are often engaged only toward the end of the development process
• Different systems are supported by different teams and even by different management hierarchies, such that testers who work with System A have little or no knowledge of how System A affects Systems B, C, and D.
• Most errors occur at the interfaces between systems and not within individual software components; yet, people’s understanding of those interfaces is weak compared to their understanding of the internals of the one system they support.

If you can’t get rid of functional silos, and if you support numerous complicated systems that are interconnected in multiple ways, then it’s likely you can derive value from mob testing.