What if We do Ensemble Programming all the time? πŸ§‘πŸ»β€πŸ’»πŸ‘©πŸ½β€πŸ’»πŸ‘¨πŸ»β€πŸ’»πŸ‘¨πŸΌβ€πŸ’»

Daniele Scillia (Dan The Dev)
Learn Agile Practices
3 min readMar 19, 2024

--

Imagine a world where software development is a collective endeavor: every team member actively contributes to every line of code. Does it make sense? Is it even possible? Meet Ensemble Programming!

A Mob Programming session imagined by Ideogram.AI

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.

[ … continue … ]

Until next time, happy coding! πŸ€“πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

πŸ™ Thank you for reading this shortened version of this article. You can enjoy the full version on my blog here.

--

--

Daniele Scillia (Dan The Dev)
Learn Agile Practices

Software Engineer @TourRadar - Passionate Dev, XP Advocate, passionate and practitioner of Agile Practices to reach Technical Excellence