Introduction
Hello, developers! 🚀
Today, the issue will focus on collaborative coding - we're exploring the practice of Ensemble Programming.
In this issue, we will look at the fascinating subject of Ensemble Programming, including its ideas, advantages, and possible impact on software development processes. Ensemble Programming has the potential to transform the way we develop software by encouraging collaboration and improving code quality.
So make sure to be ready to read this with an open mind while I tell you the potential benefits of adopting Ensemble Programming as a mainstream practice in the software business.
Let's dive in! 💻✨
From Mob to Ensemble
Some of you probably heard about Ensemble Programming under a different name: this is a synonym of Mob Programming.
Ensemble/Mob Programming is a collaborative approach to software development in which the Software Development team works together in real time on one task. In addition to software coding, the team collaborates to complete almost all tasks that a typical software development team would perform, such as defining stories, designing, testing, deploying software, and working with the customer. 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.
Ensemble Programming is clearly connected to Pair Programming, an XP practice that you probably heard enough times from me: I love to say that this is an evolutionary step beyond the eXtreme Programming practice of Pair Programming, even more, “eXtreme”. When practicing Ensemble Programming we prioritize face-to-face and side-by-side communication, team alignment, cooperation, entire team engagement, continuous code review, and self-organizing teams.
So, some of you might wonder… why the name change?
As you can read here, the name Mob Programming was retrieved by Woody Zuill team when they set up this practice for the first time, and it felt like a good enough name for them. Then, Zuill started to advocate the practice, which became famous but… as mentioned here by Zuill himself:
Many people had been appalled by the term "mob" and hence didn't want to give it a try. Thinking of bullying or lynch mobs, the term is triggering trauma.
Therefore, in 2020, they decided to come up with a new name - and Ensemble Programming was the choice - a very good choice IMHO, that well expresses the intent of a “whole-team approach”.
Is this even possible?
I know what you all guys are thinking: “How can be sustainable to have the whole team work on a single task together? We need to parallelize, go faster, to produce more code! And the business will never buy into such an approach, btw!”.
I mean, if we said that Ensemble Programming is the “extreme” version of Pair Programming, it’s easy to expect that skepticism goes to his extreme also.
The problem, by the way, is always the same as when we discuss most Agile Practices: what do you think is “waste” in Software Development?
Waste in Software is a hard topic - but luckily in the latest years, the software world has collected some data, and, together with Lean and DevOps principles, we can have a better understanding of this compared to 10/20 years ago.
Waste in software is made of a lot of things, some of them unexpected:
-
unplanned work - a category containing work such as bugs, defects, and any other unexpected problem that might show up
-
features - the most unexpected type of waste; a research from Pendo shows that features usage mirrors the Pareto Principle: only 20% of features are always used; among the other 80%, 24% of features are never used; this is a HUGE waste
Some other type of waste exists, but those 2 are enough to show why Ensemble Programming is a great idea and improves the outcomes of the team.
First of all, how do we reduce unplanned work? The research in the book Accelerate shows that the percentage of unplanned work goes down from 27% for low-performing teams to 20% for high-performing teams. To achieve that, practices such as Continuous Integration and Trunk-Based Development have proved to be effective, according to the same research. In addition to this, working together works a lot better to improve quality code and share knowledge compared to Code Reviews, especially async once.
Therefore, the same benefits of pairing apply to mobbing and “goes extreme”: everyone works on everything, knows a lot, and continuously shares knowledge. No one can be a blocker for the team because “only he worked on such stuff”, or any similar example you can think of. We are still fundamental as individuals, by contributing to the work as a part of the team and not with individual contribution that we understand how to integrate when it’s done.
Ensemble Programming simplifies a lot of things: it’s a lot easier to apply Trunk-Based Development because we are all there and we can easily commit to master directly when we all agree on the solution; no review needed, no waiting time, the code goes straight to master and to a test environment.
But, what about features? Well… as we saw, building features shouldn’t be our priority - at all. Features are waste, we should work on them with an MVP and iterative approach as much as possible: build a small version of that feature, monitor its usage, and iteratively evolve it if the usage justifies it.
What we should optimize instead is lead time: the time that goes from idea/ticket creation to release in production. Optimizing that time will give us superpowers. As Lean and DevOps teach us, optimizing lead time means optimizing the flow of work - and limiting Work In Process (WIP) is a good way to achieve this. Again, we bring this to the extreme by applying Single-Piece Flow (WIP=1), working on one task at a time, as a whole team - therefore maximizing the flow of work.
Being able to go from idea to production requires also good design choices, of course - and working together we will maximize the quality of our design choices by having all our talent working on it and sharing a decision.
If you think about it, we typically see this happening naturally when a bug in production shows up: it happens quite often that the entire team groups around the problem while investigating the issue, looking together at logs, tests, etc to find the solution as soon as possible - and then, most of the times the fix happens also together, PR can be skipped because everyone already knows about it and code can go straight to production. So, when an emergency shows up, we naturally decide that working together is the fastest way to release a solution, even if it’s a stressful moment - why shouldn’t be a good idea to do this more often, or even all the time?
To finish my considerations, I also want to emphasize that Ensemble is very great not only from a technical/productivity but also from a cultural point of view: working together builds trust and psychological safety; it makes burnout less likely to happen, and, in general, makes it easier to introduce a junior in the team, and results in easier business success.
Especially in a remote world, where it’s harder to build a sense of teamwork and trust each other, we should favor sync work and Ensemble Programming: frequent, positive interactions as an ensemble make it easier to build trust and discover shared values**.**
Practical tips
Ok so - we have established that not only Ensemble Programming exists and makes a lot of sense for a lot of people - with proven data of its outcomes.
But I know how this works, and again I know what you guys are thinking - because I’ve been in your shows. This looks nice in theory, but impossible in practice.
So here I want to share some practical tips to start introducing Ensemble Programming in a team and see how it can work for you in your context - with some additional tips to set up it correctly and effectively from my experience.
Introduce Ensemble Programming to your team
Start with Learning
The first approach I can suggest is to start approaching learning as an ensemble; turn the learning time of the team into a team activity instead of an individual one: set book clubs and workshops, but also katas, coding challenges, and hackathons as whole team activities; the benefits of learning together will be visible, and the team will start to understand how working together gives better outcomes for most activities
Introduce Ensemble with bugs and small tasks
Typically, bugs and very small tasks are already handled in a special way than usual work; it’s very often that a hotfix can be merged in a special way than the usual PR process, for example - and the same usually applies to very small task such as one line changes that anyone in the team can do. Therefore, those are the best opportunities we have to introduce Ensemble: instead of investing time in aligning before letting one of the team do the work, just jump into doing it all together immediately.
Make a first try
Once you practiced the whole-team approach in small tasks a bunch of times, be ready to identify the best chance to apply it on a real task or bigger feature; ideally, it should be a piece of code where we already have a good agreement on the possible solution so that the conversation will be easier and the team can focus a bit more on the dynamics of working as an Ensemble. Don’t wait for the “ideal” task anyway - it will never come; just pick a task that at least a couple of the team have confidence in, and try it out!
Make Ensemble the default
Review the test session in a retrospective, collect what worked and what didn’t - and try to improve the setup to start making Ensemble Programming the default way of working for the team. It’s a one-way road, there is no going back once you see how amazing the result is - and you will never regret doing this.
Tips to improve Ensemble Programming sessions from my experience
Create an environment to make Ensemble work comfortable
People must be comfortable when working, and this is even more true when working in Ensemble; if you work in person, make sure there is a room dedicated to the Ensemble; there should be either a projector or a very big screen, more chairs than the people in the team - and ideally that kind of chairs that allow to easily look up, if you use a projector; ensure that is easy for everyone to quickly connect its own device (laptop, keyboard, mouse, etc) to ensure that everyone is feeling comfortable when driving the keyboard; if you do this remotely, make sure you use a tool for online meeting that allows for smart screen sharing, with the cameras always visible and the ability to draw on the screen for who is watching (it really helps conversations!!) - you can even use a collaboration tool to be able to work together on the code without committing, either on a local IDE or on a cloud environment, but be careful: committing often is a good practice, and being forced to commit something before changing the driven can be a helpful limitation.
Make up a rotation rule and stick to it very strictly
You have to set up some rules, and at least at the beginning when the team has little experience, it’s a good idea to strictly respect them. The most important rule is probably the one about rotation: there are multiple strategies to handle rotation when Pairing/Mobbing - if you are confident with TDD you can try ping-pong, where a member of the team writes a test, then immediately switch to another member that passes that test and write a new one, etc; or you can stick to a more standard chess-clock approach: just set up a timer, and switch the driver when the time is up. Make sure to let the team pick up their preferred strategy, the one that suits them the most: some teams prefer to stick to the timer very strictly, for example - when the time is up, you have to switch even unfinished work - while some others prefer to either rollback unfinished work or invest a couple more minutes to finish and commit.
Have a team break strategy, but allow for free solo breaks
The other most important rule when working in Ensemble, in my opinion, is the rule about breaks: it’s always important to have proper breaks during work, but it becomes fundamental when working in Ensemble because it requires some more energy. The best strategy here is to pick up a team break rule that matches with the rotation rule: for example, if you use ping-pong, you can still set up a timer and make a break when time is up. If you use a chess clock, instead, you can decide after how many timers there will be a break. Make the team set this up together, and make it explicit.
It’s always a good example to stick to some time and focus management strategy: the most famous is always the Pomodoro Technique: 25 minutes of work, 5 minutes of break (15 minutes every 4 Pomodoros). You can easily match this technique with a chess-clock strategy, which I think it’s the easiest setup to start: 25 minutes of work, 5 minutes of break, then another 25 minutes with a different driver - and so on - and if 25 minutes looks very little, you can consider some alternatives.
In addition to these team break rules, anyway, you should let people be free to take their own time: someone might have a bad day or need some time for any reason. Make an explicit rule about allowing people to take a break at any time, especially when they are not the driver, without even asking - and make sure that people are aware of this rule and feel safe to use it.
Share a netiquette and make it transparent
While I decided that 2 rules deserved their spot, is a good idea in general to write down the rule set of the Ensemble sessions in a shared netiquette: this is typically a great first task to work on as an Ensemble.
In the netiquette, make sure that everything is explicit - keep it simple, but clear, so that no understanding shows up. Of course, be always ready to improve it if any negative feedback shows up from experience - and if you do this as a team, it will be easier for people to “disagree and commit” while fixing and improving.
The purpose of the rules is not just to avoid discussion - is to make sure that the team commits to a shared understanding (which is why they should be decided by the team and not imposed) and they are responsible for themselves. They can set it up as they want, as soon as it works and produces a good outcome, and can keep improving it over time in autonomy.
Involve non-dev people
Whenever the team needs non-developer members of the team to progress with the work, involve them in the Ensemble. Typically, it works well to involve UX designers while finalizing the frontend development, for example - or involving a domain expert while building a new feature, spike, or experiment.
Involve the most people possible the more time possible - it can be hard work to let people outside developers the value of this and make sure to help them on this, but it’s game-changing.
For example, it typically is a great idea to write Acceptance tests together with domain experts and stakeholders - but putting them in front of code is very hard for them, so using a higher level language, even English, with explicit examples can work well and allow you to convert that in code.
An easier example is related to UX designers, that can typically be involved in the Ensemble while developing a Design System because 100% of the code has an impact on what they design.
Find a good balance between doing this in front of code (when it’s really necessary) or in a physical/digital workshop or anything else, but make sure that you spend some effort in involving also non-developers, even customers, in the Ensemble continuously.
Monitor the right metrics
This is true in any Software Development Team, but I want to discuss this to answer the question: “Can I monitor if it’s working?” - IMHO, the answer is: “Yes, if you monitor the good stuff”.
DORA metrics are still the best choice we have today, and you should expect to see them improve when starting work as an Ensemble. In addition to that, is always a good idea to set an Employee NPS every week or two to let people anonymously express how they feel and therefore check if there is improved feedback from the team. And also talk about it in the retrospectives and 1to1 meetings - conversations always help!
Until next time, happy coding! 🤓👩💻👨💻
Where is the proof that splitting the work between multiple people is effective at all? The goal is not to be productive but effective: being productive and not effective is usually a good way to produce waste quickly.
Go Deeper 🔎
📚 Books
-
Software Teaming: A Mob Programming, Whole-Team Approach - the reference book on the practice, by Woody Zuill itself.
-
Code With the Wisdom of the Crowd: Get Better Together With Mob Programming - See how to avoid the most common pitfalls that teams make when first starting out.
-
Remote Mob Programming: At home, but not alone. - Remote Mob Programming combines two ways of working: Mob Programming and working as a distributed team.
📩 Newsletter issues
📄 Blog posts
🎙️ Podcasts
🖥️ Videos
-
A day of Mob Programming (Woody Zuill)
-
AVOID These Mob Programming / Ensemble Mistakes (Emily Bache)