The Samman Method

Here is a quick introduction to the Samman method. I’d like to briefly explain what the method does, where it works well, and some of the concepts used to make it work.

Introduction

The Samman Method, developed by a software engineer, author and technical agile coach named Emily Bache, is an approach to software development through ensemble programming (otherwise known as mob programming) which emphasises learning (most importantly), continuous improvement and a large dollop of collaboration. The idea is to bring the team together to work on the same task simultaneously, getting them to flesh out differences of opinion and direction and breaking down information silos, all while writing code that contributes to the codebase.

Bringing the team together like this is the foundation of mob/ensemble programming; it encourages quick feedback, a shared understanding, and continuous improvement by regularly rotating roles among team members, such as the “driver” (or typist, as Emily prefers to call it), who writes the code, and the “navigator”, who provides the direction for the task at hand.

The Samman Method enhances technical skills and fosters team cohesion and alignment by engaging all members in problem-solving and decision-making. It is an effective tool for teams to boost productivity and refine their software development practices.

A forward from Kent Beck

This quote from Kent Beck in the forward of the book says it all:

Small cost, low risk, high potential payoff

Since Kent Beck sees the value and provides a glowing endorsement, we should all consider this a skill to be added to our toolboxes so that we can be better technical leaders and coaches for our dev teams.

Emily Bache’s presentation at DDD Europe 2022

I saw a video of Emily Bache’s presentation at DDD Europe 2022, which was helpful for me to understand it in more detail – take a few minutes, it gives a great introduction:

What are the key concepts that make the Samman method work?

Ensemble (Mob) Programming

The Samman Method employs ensemble programming, where the entire team works on the same task simultaneously, using a single screen and keyboard. This approach involves a “driver” who writes the code and “navigators” who guide the coding process. Such a setup ensures continuous knowledge sharing among all members and prevents one individual from becoming a bottleneck due to specialised knowledge, fostering a collaborative and inclusive work environment.

Role rotation

In the Samman Method, we regularly rotate team members’ roles of driver and navigator. This rotation ensures that every team member stays engaged and gains experience in all aspects of the development process. By democratising knowledge and skills across the team, this approach reduces dependency on specific individuals and promotes a more resilient team structure.

Live and learn Sessions

The Samman Method integrates dedicated learning periods into the development cycle, allowing the team to explore new technologies, work on practice exercises, or delve deeper into less understood parts of the codebase. These sessions are crucial for ongoing professional development and help up-skill the team, ensuring everyone is up-to-date with current technologies and methodologies.

Focused, time-boxed sessions

Work within the Samman Method is structured into short, focused sessions with specific goals, followed by brief retrospectives. This approach maintains team focus and momentum, allowing for rapid feedback and continual adjustments. Such a structured environment is essential in fast-paced development settings, enabling the team to address and refine work processes efficiently.

Immediate feedback

By working in an ensemble format and incorporating continuous testing and integration, the Samman Method provides immediate feedback on the written code. This immediate response helps quickly identify and correct errors, enhancing the software quality and reducing the long-term costs associated with late fixes.

Psychological safety

The collaborative nature of the Samman Method, underscored by the regular rotation of roles, promotes a psychologically safe environment. This atmosphere encourages all members to express their ideas and opinions freely without fear of criticism. Fostering an innovative and inclusive team culture where everyone feels valued and encouraged to contribute is crucial to enhancing overall team performance and creativity.

Let’s look at a case study

You’re about to embark on a new feature development, and you’ve identified some issues in the large legacy codebase that may be contributing to the problems that the team has been encountering:

The team is taking too long to release relatively simple features (nothing against the team – we understand that they’re doing the best they can – but as the technical leader, you realise that, in an ideal world, the team should be releasing faster); and
When they do release to production, they find it difficult to release without bugs. Users find problems in most releases, making everyone unhappy—the users, the testers, the stakeholders, and the team themselves—because you’ve seen how hard they’re trying to get it right.

So you went through the codebase, and you’ve identified a few things that may help:

The code could be more consistent. Having gone through many different modules, you can see that many hands have touched the project without any oversight.
The test coverage is also inconsistent, and you consider this “low-hanging fruit” – if you get the team to improve testing, it could yield results quickly.
When you speak to the team, there isn’t a shared understanding of the business rules governing the module that everyone’s working in.
And you’ve seen a few missed opportunities to use an existing programming pattern instead of building it from scratch.

So you decide to use the Samman Method because it has the ingredients to address these issues

Ensemble (mob) programming helps build a shared understanding of the business rules and propagate code conventions and practices across the team.

We sort out any disagreements when programming together. Also, when the “typist” is typing what the navigator needs, the senior team members encourage unit tests to be built and demonstrate good practice on the spot, helping everyone develop their skills together.

Most importantly, something implicit in the points we discussed above is improved communication and cohesion, which result from everyone working collaboratively to reach an objective. Everyone understands the pain points and is there to benefit from lessons learned.

And finally, we can break down the knowledge silos as we go along, removing the risk and dependence on certain people.

Step 1 – Set up a learning hour

After breaking the issues down from the codebase, you’ve identified several practices the team can use to improve. So, set up some learning-hour sessions where you and various team members provide instruction and background to each of the great programming practices you’d like the team to follow. These sessions are just the primer and theory behind the practices you’d like the team to adopt.

Set up these sessions regularly—before I knew anything about the Samman method, we did something similar in our chapter meeting. We published an agenda, and people could add to it before the session. We would run through the agenda. I felt that this gave everyone a voice, and they could present their argument in a collaborative way. Everyone would listen to the proposal and give opinions or approval.

Step 2 – Deliberate practice

Once the team adopts the highlighted theory and benefits, they’ll understand why and where they can use these practices – now we need to instil the “how”.

Setting up a coding dojo and creating (or reusing) well-thought-out coding katas can help the team practice the theory. Emily Bache has published another book, “The Coding Dojo Handbook,” in which she explains how to do this comprehensively to help you create an effective dojo for your team. I’ll link to the book at the end of this post.

Step 3 – Form the ensemble team

By forming an ensemble team, you create an environment where all members work together on the same code. This immediate collaboration helps disperse knowledge throughout the team. The idea is to work on the actual codebase together so, before the session, identify a coding convention that hasn’t been implemented consistently across the codebase or a design pattern that needs to be implemented and set up the team as follows:

The typist: Emily prefers the term typist over driver because the driver implies some kind of leadership, which it doesn’t. The typist is the only person with hands on the keyboard, and they follow directions from the navigator.
The navigators think strategically, review the code as it’s written, and provide suggestions and guidance. They also discuss the approach, architecture, and possible solutions.

Regular Rotation: Switching roles every 10-15 minutes keeps everyone engaged and ensures knowledge transfer.

Step 4 – Review and reflect

Schedule regular retrospectives. I’m sure everyone reading this understands what a retrospective is, but for the small chance that you don’t, it’s a meeting that we hold with the team to review whether the latest sessions we’ve held together have been successful and to discuss what can be improved.

A simple way of doing a retro could be the:

What went well? To break the ice and identify practices that we really liked, we all added post-it notes on a whiteboard that represented everything that went well in the sessions.
Areas for improvement – Similarly, we identify and put post-it notes up on a whiteboard of everything we did that needed improvement, e.g.:
- The navigator was too bossy, OR
- I still didn’t understand the pattern at the end of the last learning session because we went through it too quickly.
- etc.…
For each of the identified “Areas of improvement” discussions we hold, we need to have an action point and a person responsible so that the next time we get together, we check on the status so that we don’t forget to action these improvements.

How to learn more about the Samman Method

Here are some resources I found while trying to understand the Samman Method for myself:

Emily Bache’s books:

Technical Agile Coaching with the Samman method – ISBN: 978-91-986769-0-7
The Coding Dojo Handbook – ISBN: 978-91-981180-3-2

The official Samman Coaching website:

You can find the official website here: sammancoaching.org

Conference talks and presentations

“Happier Developers & Better code” – Emily Bache’s presentation introduces the method
Here’s the link to the YouTube video embedded in the article above—if you haven’t watched it yet, I suggest you do. This is an excellent orientation to the topic from the author at the 2022 DDD Europe conference.

Community & Meetups

I found a few more resources should you want to join the community and immerse yourself in the practice. The community holds two events:

The “Samman Open Space event”, and you can register to join on the website.
The “Open learning hour” you can find more about here.