Technical Agile Coaching with the Samman Method
Emily Bache, @emilybache, ProAgile, https://sammancoaching.org
This article is an excerpt from the book "Technical Agile Coaching with the Samman Method" published on Leanpub. This content is copyrighted by Emily Bache and reproduced here with permission.
Samman Technical Coaching is a method for Agile people who want to make a difference and improve the way software is built. The focus is specifically on technical practices, how people write code and relationships inside the team.
Imagine working like this
There are 5000 lines of code in the file of code that appears on the screen in front of you. One of the team members, Lars, explains he has had several bug reports connected to a few of the private functions defined here. Lars would like there to be some unit tests for this code. Time to roll up your sleeves and get stuck in! You spend a few minutes discussing possible approaches with the team and propose a technique they haven't tried before. The ensemble gets rolling with you initially in the navigation role. A couple of sessions later everyone is taking their turn and the code is starting to be covered by tests. Lars comments he likes the feeling of freedom to change the code and get quick feedback in the form of passing or failing tests. It should be easier to find and fix bugs in this code now.
At the same time you are also working with a second team. Their task is to write a completely new piece of functionality. Patrik, (a team member), has done some experiments, sketched out an overall approach, but he hasn't written much code or any unit tests yet. People in this team don't normally use tests to help drive their design and they are curious to try it. You facilitate a whiteboard discussion to create a rough test list and articulate an initial goal. You set up the ensemble timer and ask Patrik to become the navigator and begin writing the first test. With some prompting from you, he makes a good start. When the timer pings he hands over to another team member. A couple of rotations later everyone can see the test both compile and fail. Success! The first step of TDD is complete. Making the test pass turns out to be straightforward, so the next navigator soon moves on to write the next test. Over the course of a few sessions Patrik and everyone in his team will experience doing Test-Driven Development in their production code. Patrik comments it was actually fun to write the tests this way instead of afterwards.
One hour each day is set aside to do some practice and learn new techniques. In one of these "Learning Hour" sessions both teams are gathered and you have prepared some materials about the "Golden Rule of TDD". You ask the group to call out five important things to remember when doing Test-Driven Development. This is a quick warmup to remind everyone what they already know about TDD, and you write up what they say on the whiteboard. Nobody quite expresses the golden rule although one person was close. You explain the rule: Don't create any production code without a failing test that requires it! Next is the most fun part - writing code. Working in pairs on a simple exercise, everyone tries to apply the golden rule. When there are a few minutes left of the session, we stop coding to discuss what happened. Several people found themselves writing the code first by mistake. One person was doing well then wanted to create new code in a refactoring step. Was that OK? A short discussion ensues. At the end of the session everyone goes away with a sticky note or a screenshot of the rule and homework to try the exercise again by themselves.
Does this way of working sound interesting to you? What I've described is called the "Samman" method and it's a way of doing Technical Agile Coaching.
Samman Technical Coaching
Samman Technical Coaching is a method for people who want to make a difference and improve the way software is built. The focus is specifically on technical practices and how people write code. The foundation of it is cultivating good relationships with the people you work with. The rest is about effective ways to learn from one another and to change behaviours for the long term.
A Samman coach divides their time between several software development teams and there are two main parts to the method:
In the learning hour the coach uses exercises and active learning techniques to teach the theory and practice of skills like Test-Driven Development and Refactoring. In the Ensemble sessions the whole team collaborates together with the coach in applying agile development techniques in their usual production codebase.
I chose the word "Samman" to describe this coaching method since so much of it involves working in an ensemble. "Ensemble" is a French word meaning "together". "Samman" is a Swedish word that also means "together". I wanted to distinguish this method from other ways to do coaching and make it easier to search for on the internet.
The great privilege of a Samman coach is getting to write code for most of the day, together with others. You work in an environment where everybody is contributing and learning new skills. You're using effective technical practices and writing excellent quality code and tests together.
The purpose of Samman Coaching
A Samman coach aims for improved development practices in the teams they work with. These ones in particular:
The choice of these particular development techniques shouldn't be controversial, they have been used for years by Agile practitioners and in DevOps communities. There are many books and training videos out there explaining how to do them. Samman coaching is a more effective method for introducing them.
Levelling up a whole team together
When I first learnt to do Test-Driven Development and Continuous Integration I was working in a small team on a greenfield development project. Our culture and ways of working were aligned and we were very effective together. Unfortunately that product was not successful in the marketplace and I subsequently moved to another team in the same organization.
The new team culture was very different. I continued to write unit tests but my teammates did not. I continued to work in small increments with frequent integration but my teammates did not. I quickly realized this was not sustainable. The tests I wrote were ignored or even deleted by my colleagues. I was reprimanded for making refactorings that caused merge conflicts for others later on. I was unhappy. They were unhappy. It didn't last - I found myself a new job.
Software development these days is a team sport and it doesn't work to only train individuals. Samman coaching aims to create a whole-team culture shift. In the ensemble working we discuss the minutiae of how to use new techniques in the particular situation the team finds themselves in. We build consensus about how this team wants to work. In the learning hours we discover what development could be like if we used new ways of working. The team becomes aware that a different future is possible. The coach helps them gain the skills needed to go there.
Ensemble Working
As a Samman technical coach the majority of your day is spent sitting with teams working as an ensemble. That is:
"All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer - We call it 'Mob Programming'"
– Woody Zuill
That quote is from "Mob Programming - a Whole Team Approach" by Woody Zuill and Kevin Meadows. I originally learnt the technique from Woody and others close to him. Over the years since then I've come to prefer other words to describe it. I usually say "ensemble" instead of "mob". The essence of the technique is the same though.
Working as an ensemble seems to me to be useful in many circumstances, but for a coach it's a superpower! You can spread knowledge and ways of working to a team, you can increase communication, and promote teamwork. It's a major part of your day as a coach, and one of the most important tools in your toolbox.
In a team ensemble you all work together on a normal task from the team's backlog, coding in their real production codebase. At first, the coach will be teaching the roles and rules of ensemble working. At the same time you begin to apply iterative and incremental development practices. You will write unit tests and integrate the work often. The main goal is that everyone in the team understands the code that you're writing together, and eventually feels confident to continue building more code in the same style.
Learning Hours
The second major part of Samman technical coaching is the learning hour. These are short training sessions where you practice coding skills and learn new techniques. People are not used to training happening like this, every day. There even seems to be a school of thought that says you should do all your learning in your spare time, that your employer shouldn't be paying for it. I strongly believe that for an organization to succeed in the modern world, it needs to be a learning organization.
In the ensemble sessions in the production code the coach will encourage the team to use agile development techniques they may be unfamiliar with. The learning hour is the chance for the team to really understand those techniques. You can discuss the theory behind them, go through examples, and discuss when a technique is not appropriate.
When planning content for learning hours I've taken a great deal of inspiration from Sharon Bowman's '4C' learning model from her book 'Training from the Back of the Room'. A learning hour includes activities for each of Bowman's 4C's:
It's hard to take over someone else's training plans and exercises. Every Samman coach needs a personal portfolio of materials. I'm very happy to share mine - but fundamentally teaching materials that you make yourself will be much better. Find materials and exercises that appeal to you from other people, but always adapt and tweak them so they become your own.
Expected outcomes from Samman Coaching
Firstly, we aim for awareness of what good unit tests look like, what continuous integration actually is, that it's possible to safely refactor code you don't initially understand. Next we aim for the insight that successfully meeting deadlines and delivering high quality code means learning iterative and incremental development techniques. Teams gain new aspirations to be good at these things.
In my experience after perhaps 10-20 coaching days most teams will have reached those insights. These are the first steps on the road to improving the way that team works and the quality of the code they deliver. After that, it's about building skills and anchoring ways of working in habits and culture.
I first learnt about the methods explained in the book through pair-coaching with Llewellyn Falco. I was impressed with the results he was seeing. The outcomes I observed were firstly a clear attitude change. People wanted to learn these techniques, they saw them as valuable. Secondly there was one team in particular where they had become really skilled. Over the course of many days and weeks with the coach they had changed the way they designed and built their software. I remember sitting at the back of the room observing this team working as an ensemble. They were working together smoothly and productively, creating code and tests in small increments with high quality.
Those are the outcomes you should see from Samman coaching. Changes in attitude, increases in skill, improved code quality. Over time, more productive development teams.
Related Agile Coaching articles
Improving Scrum Teams with the Agile Coaching Canvas
Measuring And Increasing Team Alignment
More Agile and Lean Knowledge
Click here to view the complete list of Methods & Tools articles
This article was published in January 2021