If today many people equal Agile with Scrum, the Agile approach is also deeply rooted in software engineering practices, like pair programming or refactoring, promoted by the eXtreme Programming (XP) movement. In this book, Emily Bache presents the Samman Technical Coaching approach. It is a method for helping software development teams to become more agile and raise the quality of their work.
As Emily Bache writes it “Software development these days is a team sport and it doesn’t work to only train individuals”. You need to develop collaborative teams and “Samman” is a Swedish word that means “together”. The approach promoted by this book is based on the Mob Programming approach proposed by Woody Zuill. The book describes the two main “tools” of Samman Technical Coaching: ensemble working and learning hours with examples. A section is also dedicated to pitching the idea of Agile technical coaching to organizations and how to start doing it.
The book is largely based on the Agile coaching experience of Emily Bache and contains many real-life situations and dialogues. It is easy to read and well-structured. I will recommend it not only to Agile coaches, but to every member of an Agile team that is interested in practical approaches for technical improvement and collaborative working.
Reference: Technical Agile Coaching with the Samman Method, Emily Bache, https://leanpub.com/techagilecoach
Quotes
As with any new skills, the way to learn is through a combination of teaching and practice. The Samman method includes a series of short lessons called ‘learning hour’. The coach uses active learning techniques that are proven to be more effective than lectures. We work together on code katas and other exercises so developers both understand the new techniques in theory and experience them in carefully chosen examples. The Samman coaching method is also on-the-job, together with developers in their usual situation. In order to change the way developers work it’s often not enough to only practice on code katas and learn theory. The coach works together with development teams in a structured collaboration called an ‘ensemble’. We learn how to apply relevant techniques in the actual production code the team works with daily.
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.
It can feel good to complain about the code you’ve inherited. A group can bond over making fun of obfuscated design or misuse of language structures. Unfortunately by doing that you’re also ridiculing the author of said code. Woody’s rule reminds us we probably can’t know why they wrote the code that way. We should assume they did the best they could with the knowledge theyhad and the circumstances they were in at the time. Nothing is more corrosive than disrespect in an ensemble. The original author of the code perhaps isn’t present today, but you don’t want anyone feeling nervous that some day it will be their code that everyone is laughing at. We want to create a space that is safe. Safe to experiment, to learn, to show your vulnerabilities and weaknesses. We can work to improve code without making judgemental comments that criticize the original author. Working in an ensemble exposes a lot about everybody involved, and we need to feel safe and supported.
You want future sessions to be at least as good as this one, if not better. Ask people to form a circle so you can see everyone. Go around the circle and each person says one thing that happened in the session that was good. Just a sentence or two. The idea is to encourage one another to behave like this again. Woody Zuill calls this ‘turning up the good’. Concentrate on what works well and do more of that.
Less task-switching and lower amounts of Work-In-Process make a team more effective overall, and it means learning to collaborate and work on coding tasks together. Individual working followed by code reviews is not always the most effective form of collaboration. Ensemble working is a structured collaboration that enables you to code together on one task in an effective way. You don’t have to do it all day every day or on every single task, you should learn when it’s going to be most useful and effective. It’s a skill that takes some time to learn. Ask “Have you tried Pair programming? How did that go?” Go through the roles and the rules of ensemble working. Ask “Are you interested in learning this skill?”
You’ll become a better coach if you spend time reflecting on your work and explaining what you’re doing to other people. Also, listen to other coaches explain what they do and find out what works for them. You will hopefully find insipiration and incorporate new ideas into your work. You could seek conversations with many different people, for example at conferences, online ensemble programming sessions or internet discussions. As well as more general conversations, I’ve found it very valuable to find one or two trusted peers who I talk with regularly. Other technical coaches doing the same work as me but in different organizations. We can talk confidentially and compare notes. This is something I’ve personally found very important and helpful for my career.