7 min read
At Kosli we do as much of our work as possible in a group setting, especially (but not limited to) programming. In our experience most tech teams don’t do this and we think they’re missing out on all kinds of advantages that come from working as an ensemble. In this post we’ll share why we do ensemble work, what our experience has been, and why we think you should give it a go.
1. Culture is built one conversation at a time
We think a lot about our team culture at Kosli. We’re a startup, so we’re building a company as well as a product and that requires a strong culture. For us that means being deliberate about how we collaborate, communicate, and make decisions.
As a company formed in the middle of the covid pandemic we have been remote-first from day one. Fostering a common culture that doesn’t involve water coolers, team off-sites, and shared lunches can be a challenge. First and foremost it requires trust.
Trust requires frequent positive interactions that are much harder to do remotely than most people want to admit
— Camille Fournier (@skamille) November 29, 2021
We’ve found that frequent, positive interactions as an ensemble has made it easier to build trust and discover shared values.
2. None of us is as good as all of us
There is a common saying in the ensemble programming community that “none of us is as good as all of us”. On any given task individuals can have good or bad days. We can also have strong skills or weak skills. We can have deep or shallow expertise. By working together we can realize the full potential of everyone’s abilities. The best of the whole team makes it into every decision.
Figuring out how to meet our customers needs, understanding the tradeoffs on solutions, and prioritizing and engineering work are all hard problems.
We want to make sure we optimize for great decisions and ensemble approaches ensure we bring our collective intelligence to every task. As the saying goes, “many eyes make all bugs shallow”.
There’s also a performative aspect to a group setting - we all want to be the best version of ourselves. This helps us avoid shortcuts and quick fixes.
Programming in a shared setting is also a form of continuous code review. This makes it easier to set collective expectations, so everyone knows what’s expected - even if you’ve only just walked in the door.
And, if you know what the rest of the team expects, you know what you have to do to start contributing. That takes a lot longer when everyone is coding on their own.
3. Knowledge production is our biggest bottleneck
As a startup, we are starting from a blank slate. We are exploring new and better ways to solve compliance and change management and there is no existing solution to copy. In this area of software development we are facing a complete absence of good solutions.
To overcome this we have to create new ideas, strengthen them, realize them, and then test them in the market. These innovation loops are completed much faster when we work together to explore a wide array of possibilities.
4. Specialization is for insects
For us, most features are full stack problems. To deliver on customer needs we often need to code across our client, our backend, our data, and our user interface.
If our team was composed of specialists for different parts of the stack it would mean a lot of wait states, handovers, and miscommunication. It would also make testing a big challenge.
By committing to single piece flow, we share competence and knowledge across the team and that makes everyone confident in all areas of the codebase and with all our tools.
This in turn establishes collective ownership of the codebase.
5. Chasing the Continuous Improvement dragon
We all know that it is better to work smarter than to work harder, but things don’t improve by themselves. It requires a culture of support and pressure to improve capability.
One of the fantastic things about mob programming is that everyone sees and experiences the same things. So, if tests are slow to run, if the logging is noisy, if the design is clunky, we all feel it together. And this collective pain drives us to fix things.
The counterpoint is also true. As we fix problems and remove pain, we share the joy from these benefits. This leads to a virtuous cycle of agency because we gain motivation and empowerment from the results.
6. Bulldozers and racecars
The biggest criticisms we’ve seen of ensemble programming revolve around efficiency concerns. Wouldn’t it be more effective to parallelize the work?
We believe software development is not a MapReduce problem, i.e. it isn’t compatible with top down decomposition, farming out tasks to worker bees, then integrating the results. Parallelism works great for piece work, but teamwork works best for knowledge work.
Contrary to popular belief, typing is not the bottleneck when it comes to software development. By far the biggest cause of delays is wait states and lack of inspiration. We want to optimize for quality of decisions over quantity of decisions.
By working together we significantly reduce the likelihood of getting stuck and we don’t have to wait for help.
One benefit of Mob (Ensemble) Programming may be: no blocked persons anymore
— Peter Koch 🇨🇭 (@petikoch) November 19, 2021
"In practice it usually feels like a bulldozer
rather than a racecar - unstoppable and thorough."
- by @techgreatness
Just tried to visualize that ✍️ pic.twitter.com/j5Y32mGaAO
One of the challenges of growing a technical team is how to onboard new members without impacting our momentum. As Ewelina discussed in a previous blog, mob programming - even remotely - enables new employees to become productive members of the team within a few days. This is what Jeff Langr means when he’s talking about busting Brooks’s Law. This also makes it easier to bring in specialist consultants in a productive manner.
7. Less chance of burn out
Knowledge work is emotional labor. We need to manage our emotions and support ourselves and our team as we do our work. And this labor comes at a cost.
The practices in ensemble work make this easier to handle. For instance, if we are feeling overwhelmed it is easy to swap roles or even check out altogether if that’s what’s needed. It also reduces task switching because the work continues even if we don’t.
We also reduce the individual pressure to deliver since we share the responsibility for success. This is the basis for the psychological safety we believe we need to win as a team.
8. It’s more fun!
Last but not least: it is a lot more fun to work together to solve problems. We have a weird image in software that it is an individual, isolated endeavor. And in many places it is. But we knew this wasn’t the case as far back as 1971:
We must deal with one other problem, which is important because of a seldom questioned view of programming - a view which this book will spend a great deal of time questioning. That view is that programming is an individual activity.
Jerry Weinberg
We’re on team Jerry!
Summary
We’ve found ensemble approaches work for all types of tasks: customer success, coding, design, testing. Anything that requires thought, really. And isn’t that the type of work we all want to be doing?
We’ve had a great experience doing ensemble work this year as we grew from 2 employees to 12. How will it scale? How will we adapt our practices as our team matures? I’m sure we’ll figure it out together!
