SAFe Mix-ins: Mob Programming
I’d like to talk a little bit about SAFe mix-ins. SAFe mix-ins are innovative practices in the agile community that we can incorporate into popular frameworks like SAFe, LeSS, or DaD (to name just a few). To me these mix-ins represent an opportunity for us to improve the performance of our teams within existing large scale frameworks, and that ultimately serve to enhance and provide benefit to us and our customers.
Overview
So, with that in mind, the first mix-in that I would like to address is mob programming. Now, if you haven’t heard of mob programming, it’s relatively new. It’s been around in the agile community, at least as far as I can remember for about the last four or five years or so. Its original proponent is a guy by the name of Woody Zuill. Woody probably describes it best, so here are a few references to mob programming and how it works.
Wikipedia article on Mob Programming
In two sentences or less, mob programming is basically getting the entire team working together in a structured fashion to work on a single problem at a time. This is usually done in a team workspace in front of a big screen. It has a variety of intriguing benefits:
Helping to train everyone at the same time.
Getting all the minds and the wisdom of the crowd looking at the problem simultaneously.
Generally bringing the team together to work together closely and collaboratively. Working in, dare I say it, an agile fashion.
There are also some rules to mob programming, but not many:
There is one and only one driver. The driver is responsible for doing all the typing. They own the keyboard.
Everyone else is a navigator. The navigators are giving the driver directions and keeping an eye on where you are headed next.
Roles are swapped frequently. Being the driver is exhausting, so we swap out the driver role every 10 minutes or so. Everyone gets a chance to drive.
With these sorts of benefits, mob programming is the kind of activity that I would describe as a technical practice akin to pair programming. As such, it really represents no disruption to incorporate it into any of the existing frameworks. It’s relatively easy for us to incorporate it into SAFe. For example, if one team on your release train decides to adopt mob programming, great! It’s no problem, it doesn’t impact anyone else on any of the other teams. Furthermore, if you were to adopt it across all of your teams on a release train, you might find that they all might accrue the benefits of mob programming – without affecting any other release trains. All of this works out to our benefit.
SAFe Implementation
So, with all of these things in mind, adding something like mob programming to a framework like SAFe seems like a fairly pragmatic and useful idea. Certainly, at its worst it’s harmless – it doesn’t hurt us in any way, shape, or form. And at its best, it helps us to improve the performance of the teams. Furthermore, it has no side effects or impacts to any of the existing practices, artifacts, roles or structures in the process that is SAFe. So, from that perspective it’s really quite useful.
Now, there’s probably one other thought that some may have which is, “Hey, if it’s so useful Tom, why don’t we put it into SAFe and formalize it?” I’m not sure that’s really necessary or frankly a good idea. After all, SAFe is espoused as a framework and as such should probably be kept as minimalist as possible (I know there are some who would laugh out loud at that last statement). I don’t believe that we should take every single technical practice that we happen to stumble across and stuff it into our definition of a framework.
The other thing that I like about the practice of mob programming is that it is so low impact that it doesn’t represent the kind of change that might seem to be challenging for some of your more conservative organizations. This is the kind of mix-in you can add relatively easily to an organization that might otherwise find more substantial types of change very challenging to adopt. In this particular case, mob programming is easy to slip in and try out. It’s low risk and has no noticeable effect outside of the team (unless, of course, it’s advertised). These sorts of mix-ins are probably the best-case scenario for starting to introduce subtle change and subtle evolution into frameworks like SAFe, LeSS, DaD, Nexus and others.
I guess there is one other question that we should ask ourselves anytime that we try to change our process: What problem are we solving? Let’s think about that question in terms of mob programming. How long does it take to add new people to the team and get them up to speed and contributing at the same level as everyone else? Do you have silos of specialization, where there are only one or two people who understand a component or subdomain? Are people able to easily switch roles on your team when someone is missing? If these are the types of problems you face, then perhaps mob programming would be useful. You could certainly easily measure improvement relatively easily.
I’ll also offer this thought: When you take a step back and take a look at the PI Planning process, it’s not a whole lot unlike elements of mob programming. It’s inclusive, everyone in the release train is asked to join and participate. Each team has its time in the sun where they share their plans with the other teams. And it’s an intense period of learning for everyone involved. You could think of it as mob planning. So, this mobbing concept might be useful in other domains outside of programming too.
Forces (What Would Lead You to Do This)
The organization is resistance to change at the program level and above
Work encounters bottlenecks within the team
Team is struggling to bring team members up to speed quickly
Team composition may be changing frequently due to growth or turnover
Framework impacts (How Would it Change SAFe)
Within individual teams only, no changes to roles or artifacts
No other impacts outside of the team
Benefits (What’s in it for You?)
Train everyone at the same time (learning transfer, cross functional training)
Getting all the minds and the wisdom of the crowd looking at the problem simultaneously – higher quality
Brings the team together to work together closely and collaboratively (team cohesion)
If you are one of those radicals who happen believe that SAFe needs to change. If you believe that large scale agile needs to evolve in order for the promise of agility to pay off. If you believe that we can incorporate the latest innovations in the agile world into organizations adopting these frameworks, then please come join me as we explore just how we can do that together.
Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. https://bit.ly/2HXCcKD
