The Agile Architect
Mob Programming as a More Agile Replacement for a Team Charter
A team charter is a common tool of an agile team to create consensus on how the team will do its work. Unfortunately, the act of creating a team charter can be lengthy and dull. Our Agile Architect describes an alternative approach to team chartering that embraces the agile concept of delivering real value rather than talking about it.
Creating a team charter is a common practice when kicking off a new project. The team comes together and creates a series of agreements on how they will work. This ranges from technical agreements (configuration management, deployment process, coding practices) to product ownership (process to create stories, definition of "done") to risk tolerance and management, and more.
However the process of creating a team charter is not easy. Even with a charter template, bringing the whole team together in a room to agree on these many items creates complex discussions often about mind-numbingly tedious issues, real or imagined. Without a focus for the discussion, the chartering process can seem interminable. This often leads to abbreviated sessions where important decisions are never broached or weak decisions are made by an apathetic team eager to get back to work.
A Better Approach
Recently, I've been working with a team that is experimenting with the use of mob programming as a replacement for a team charter. The team has never gone through a chartering process but does have some basic understandings in place as to how they will work. They are going through a period of rapid change in the tools and technologies used in the project which has led to a string of changes in their processes. They are encountering problems with team consistency in the application of these decisions or even agreement on what their past decisions meant. This has led to a series of failed releases, the primary culprit being inadvertent code mixing between stories, and subsequent roll-backs that the team believes will continue unless they can gain consistency and simplicity around their processes.
Rather than go through a lengthy chartering process, the team decided to experiment with mob programming as a way to come to consensus on as many aspects of their processes as are necessary to complete a story.
What Is Mob Programming?
Mob programming is the act of a large group of individuals coming together to develop a story. It could be the entire team or a subset. Think of it as an extension to pair programming. If two developers are better than one, than a whole gaggle of programmers would be better still.
Mob programming can be used for multiple purposes.
Starting to develop a new feature: When a team starts to develop a new feature, there can be many different ideas about how to implement it. Discussions up front yield some value but if there is disagreement on direction, it can quickly degenerate into discussions of who has the most experience or technical knowledge in the area. In other words, who's opinion does the team trust more? Without the benefit of being informed by code, it is tough to validate either opinion. I've discussed in previous articles how parallel spikes can be used to resolve these disagreements. Mob programming is another tool that can be applied. By having all the developers work together to create the solution, disagreements may melt away in the face of working code.
Implementing a technically diverse story: When the team hits a story that touches many different technologies and parts of the code base, there may be multiple team members who's expertise is needed. You could use pair switching as a mechanism to bring in the expertise as needed. By mob programming, you avoid the context loss that occurs when pair switching. Everyone knows what is going on with the story at every phase of development.
Rapid development with high quality for a team: Some agile teams have adopted mob programming as their everyday style of working. They find that they can maintain or increase their productivity while increasing code quality.
The big question, of course, is whether mob programming will help your team. My agile coach's answer to this is, try it, measure it, and see what happens.
The Experiment: Can We Use Mob Programming as a Replacement for Chartering?
Despite all of the reasons for mob programming given above, we wanted to try mob programming for a different reason. By mob programming for a day, could we generate a team charter, or the equivalent, without a formal chartering meeting? Here's what we did.
The first step was to choose a story that was small enough that we believed we could finish it in a day, even with the extra burden of the discussions we knew we would have. We chose a story that had good acceptance criteria, was well understood by the team, and had little to no technical challenge.
We then discussed how the mob programming would work. We adopted the driver/navigator paradigm from pair programming, with a single driver at the keyboard and the entire team acting as navigator. The driver would not be allowed to type their own thoughts but only input what the team wanted. This prevents the driver from taking control while disenfranchising and disengaging the rest of the team. In addition, we added a position of scribe. The scribe would be responsible for documenting the decisions made by the team, in effect, creating the charter. We also decided that everyone on the team, developers, QA, product owner, would all take their turns at each keyboard. Based on what we had read about mob programming online, we decided that we would rotate through the positions every 15 minutes.
Next, we reconfigured our war room. Instead of the many pairing workstations, we set up one workstation with a 50" TV/monitor so everyone could read the text on the screen. We brought in a second large monitor to display the acceptance criteria for the story so we all knew what we were building. We then adapted the adjacent workstation for use by the scribe who would take notes in our wiki on the decisions the team made. We used a timer to keep to our 15 minute rotations. We established a parking lot for discussions that were too big to be decided in this experiment or were outside the scope of the experiment. Finally, we chose our first driver and scribe, with the rest of the team positioned in a semi-circle around them and began.
Our Results
As you might expect, we spent a good portion of the first couple of hours discussing how we would do what we were doing, all while working and documenting. Our discussion was informed by the experience we were gaining through doing. The team appeared to enjoy the experience and find it useful, at least in part. We asked after lunch who wanted to continue. About half wanted to, half didn't care. No one said stop so we continued.
Towards the end of the day, we had finished implementing the first acceptance criterion for the story. The rest of the acceptance criteria had not been started. Rather than continue with development, we decided to treat the implemented acceptance criterion as its own story so we could run it through the rest of our process.
When we were done, we had a fully documented, multi-page development process in our wiki, a much better team understanding and agreement on how we would work, and a single story (the first acceptance criterion) ready for deployment to production.
One failure had occurred in the afternoon as we started to get concerned that we wouldn't finish the development phase of the story and thus not be able to work through the rest of our process. In order to be more efficient and move faster, we decided to only allow developers at the keyboard since they knew the tools and could go through the mechanical process of typing faster. We also put a developer pair at the keyboard to follow the test-code-refactor cadence of Test Driven Development. Almost immediately, the mob programming paradigm broke down. The pair began working together, talking together, collaborating as good pairs do. But they shut out the rest of the team. We should have stuck with the single-driver paradigm.
The good news is that since this experiment, we have had no failed releases and our adherence to our processes is significantly improved with no major conflicts or questions arising.
Next Steps
I would like to continue the mob programming experiment. I am hoping the team will want this as well. I think our next step should be to set up a regular cadence for mob programming, perhaps one day every couple of weeks both to ensure team knowledge of our shared processes and to drive discussions of how these processes can be improved. In addition, I hope to be able to observe and hopefully measure other possible benefits of mob programming like enhanced code quality and increased development speed.
Final Thoughts
Is mob programming a replacement for a team charter? In this case, I think it was a good first step. The team was able to actively work through the development process, discussing and modifying based on real immediate experience.
However, we haven't addressed other charter topics like story writing and risk management. For the former, it would be interesting to try a mob story writing exercise. For the latter, there are several agile risk-based exercises that the team can work through without the need for a chartering meeting but that's a topic for another time.