Successfully introduce Mob Programming
When introducing this practice, there usually is a lot of resistance for some very specific reason; let's explore some tips that will avoid your team to fall into the most common pitfalls.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Let's dive into today's micro-topic!
From Individual to Team Contribution
Mob Programming is a collaborative approach to software development in which the Software Development team works together in real time on one task. Almost all work is completed through "working meetings" or workshops, and everyone participating in the software development process, including our partners, is considered a team member.
I will not go further in introducing this practice here, and I will assume you know enough for the rest of the issue - if this is not the case, you can consider to deep dive reading this article or this book.
When introducing this practice in a real-world team, there usually is a lot of resistance from developers and managers, for some very specific reason; usually, there is fear related to this big habit change - fear about losing efficiency and making all the team work on the same task instead of parallelizing, slower progress with the work in general with the risk of pressure from deadlines, resistance to code with other people instead of in isolation, etc.
I’ve explored how to introduce the Ensemble Programming practice successfully in a Software Development team in this article on my blog.
In this issue, I want to explore some tips that will prevent your team from falling into the most common pitfalls the Software Development teams meet when approaching this practice.
💡 This issue is inspired by the great Emily Bache, one of my biggest sources of inspiration for Technical Coaching.
Kudos to her for all her job, make sure to follow her if you are interested in how to coach and introduce Technical Excellence in a company.
Best Practices to Introduce Mob Programming
1. Do not call it “Mob”
Today, people refer to Mob Programming with the new name of Ensemble Programming: as you can read here, the name felt good enough when created, but over time, with the practice gaining popularity, the word Mob was causing misinterpretations and negative biases, so they came up with the new name of Ensemble Programming.
For the same reasons, you should also stop using the name “Mob”: refer to the practice as Ensemble Programming, or Software Teaming, which are nicer names that also transmit the sense of collaboration that the practice brings, helping avoid bias from team members.
2. Start small and safe
Ensemble Programming implies leaving some old habits behind and embracing a new approach to Software Development, moving from an individual contribution to a team contribution approach. Since we as human beings have a natural resistance to change, it’s fundamental to handle the transition smoothly and effectively: trying a first session on a real feature on production code will likely be a failure and build a bad first impression on the team.
This is the process I suggest, which can be adapted to any new practice you want to introduce:
Start with learning: invest time in team training sessions to learn the basics of Ensemble Programming. Read a book, watch some videos together, do some simple katas, collect opportunities, questions, and fears that the team identifies, and look for feedback from someone expert with the practice if you can.
Practice together: raise the complexity of your practices with more complex katas and structured coding challenges; build a real system such as a TODO list or Directory app to build some experience on the dynamics of Ensemble Programming on a larger codebase.
Bugs & small tasks: if you start to work in the ensemble the entire day immediately, it would be too much; start introducing short sessions to work on bug fixes and short tasks (let’s say a couple of hours) to start seeing the benefit of the practice in the real world in a smooth way
Real features: iteratively increase the size of tasks, and the time spent in Ensemble during the day will grow accordingly, moving from a couple of hours to working in Ensemble for most of the day, involving the entire process from idea to release and getting feedback. In a few months, you will realize that mobbing has become a habit and the team can no longer imagine working without it.
Make it default: approach work in Ensemble by default: solo work should require team agreement for a specific good reason. At this point, the team is also used to involving anyone needed in the sessions and can lead the company to make it a habit to be involved by default for non-devs needed in the process.
💡 The process will take weeks or even months: it’s totally expected. The funtamental objective is to make the team build the habit to work as Ensemble, and keep iterating to improve both the outcomes and the wellbeing of the team.
This shouldn’t discourage you: little progress is still progress, and a lot of daily little steps makes a big progress on the mid-long term.
3. Do not treat it as Pair Programming
While the relation between Pair and Ensemble Programming is visible, this relation is often misunderstood: Ensemble is not “Pair for the whole team”, it’s more “the Extreme version of Pair” - with “extreme” intended the XP way (we take what it works and we bring it to the extreme). In the same way that TDD is the extreme version of testing but it’s not merely “test-first”, Ensemble Programming is the extreme version of Pair but it’s not merely adding more navigators to the table.
The dynamic recall strong-style Pairing: the driver should just execute the instructions he receives from navigators; navigators, instead, should have a continuous conversation about how to progress, and one of them should facilitate the conversation and repeat the final decision out loud to make sure the decision is clear for everyone.
4. Measure the outcomes (and give the practice time to impact them)
The two most important things to build in the process are:
psychological safety for the team
trust from managers
An important element to build both is monitoring numbers that measure the outcomes we think are important for the team to make it visible how we are impactive them (in a positive way, ideally). I usually focus mostly on two types of metrics:
Company Metrics: numbers that are meaningful to the company’s expectation for the software I’m working on; it can be as straightforward as profit, number of subscribers, number of active users, etc - or it can be something more specific to the context.
Software Development Metrics: in my opinion, the best way to measure the technical outcomes of a team we know today are DORA metrics; DORA metrics are the KPI used for the research that the book Accelerate is based on, and the following updates via the yearly State of DevOps Report (here you can see the 2023 report); while it’s possible that in the future we will discover better ways to measure the outcomes of a Software team, these are the next tool we know today.
🧠 Test Yourself in 1 minute:
💡 Did you know? An interactive activity, like quizzes or flashcards, can boost your learning!Take a 1-minute quiz and test your understanding of the topic! 🤔 Don't miss the opportunity to boost your learning—try now! 👇
What are some better names for the Mob Programming practice?
Insights Recap
Introducing Ensemble Programming usually causes some fear and resistance related to multiple things:
habit changes
losing efficiency
losing speed
coding in team
To overcome that fear, we need to introduce the practice in a smart and smooth way:
Refer to the practice as Ensemble Programming, or Software Teaming, to avoid misconceptions and biases related to the word “Mob”
Make the team learn the practice first: give them time to read books, watch videos, discuss together, and do Katas and coding challenges
Start with short sessions on production code, making the team work as an Ensemble on bug-fixed and small tasks
Progressively increase the size of tasks and duration of the session, until Ensemble Programming covers most of the daily work
Make Ensemble Programming the default to be skipped only for very good reasons, and start involving non-devs more frequently
Until next time, happy coding! 🤓👩💻👨💻
Go Deeper 🔎
Legenda
📚 Books
📩 Newsletter issues
📄 Blog posts
🎙️ Podcast episodes
🖥️ Videos
👤 Relevant people to follow
🌐 Any other content📩 Team Lessons Found only in Ensemble (Mob) Programming (Crafting Tech Teams)
📩 Ensemble programming is more efficient (Eric Normand’s Newsletter)