How to Spread Technical Practices Like TDD in an Organization

One of the success factors for Agile and DevOps is developers changing the way they work and adopting practices like Test-Driven Development (TDD). It’s not something that just happens by itself, and many of the “usual” ways of introducing change fail for TDD. In this article I will outline some of the things I’ve tried that actually do work. I’ll explain “Samman,” which is the coaching method I use with developers.

Why TDD matters

If an organization is building a software product, then the way people write code matters. Good technical practices mean the organization can build new features with a shorter lead time and of higher quality. That should mean meeting deadlines and delivering reliable software. Skilled developers will want to work for an organization with high quality code, effective development practices and a healthy culture. On the flipside, organizations that struggle with poor code quality and fail to address it will ultimately become unable to deliver new features in a timely or cost-effective manner. That’s a bad outcome for any organization.

There is well-respected research that shows exactly these effects. The book Accelerate by Forsgren et al. explains the remarkable findings from a multi-year study of software development organizations. They studied many factors, and identified those that contribute most strongly to business success. In particular, they highlight the practice of Continuous Delivery. That umbrella term includes several technical and organizational practices, including Test-Driven Development, TDD.

It’s a stretch to say that doing TDD will lead to a successful software business, but it is undoubtedly an important part of the picture. Teams that produce high quality code generally achieve that by writing high quality automated tests, integrating frequently, and making constant small design improvements. Not every team or software developer has the skills to do that well. 

In my work as a technical coach, I meet a lot of software developers who are used to long delivery cycles, integrating their changes perhaps weekly. They rarely improve any design beyond the immediate changes needed for the particular feature they are working on. These teams are working at a fraction of the effectiveness I see in other teams where skill at TDD is widespread. TDD and the high quality codebase that it enables has a big effect on teamwork, ability to collaborate and overall developer wellbeing.

What organizations are already doing

The Accelerate research tells us there is a huge gulf between the best organizations and the low performers. In the new world of digitalization, DevOps and business agility, many organizations need to upskill their software development organizations. I’ve certainly met a lot of managers and architects and tech leads who would like their development teams to use more effective practices.

I recently did a poll of around 300 participants at the ACCU 2021 conference about what learning activities they are doing already. (Obviously these are conference participants, so that is one activity I didn’t list!)  The most popular choices in descending order were:

• Code reviews
• Online on-demand training videos
• Instructor-led training courses for 2-5 days at a time
• Frequent pair programming
• Hackathons
• Community of Practice

I then followed up on this question by asking which of those activities they had successfully used to learn TDD, with an additional option of “I haven’t learned TDD”. That was the most popular option, unfortunately, followed by Frequent pair programming and Online on-demand training videos.

This confirmed my own observations that TDD is not an easy skill to learn; the best way to learn it is from someone who knows it, and it takes effort and repetition before you become fluent with it. Activities like hackathons and code reviews don’t work; learning a skill like TDD just isn’t part of what happens there. Even instructor-led training courses have little chance of success - it’s too short a time and too little repetition for the new ways of working to really stick.

Pair programming with someone who knows TDD is one of the few things I’ve seen that really does work. Not many teams have someone like that to pair with, however. Self-paced online training coupled with plenty of practice exercises also works if people are motivated and stick with it. It might not help your team as a whole if only a few individuals make it that far, though. 

My own experience

In 2005 I discovered the Coding Dojo as a forum for teaching and learning TDD, and began to see some progress in helping my colleagues to get the hang of it. I wrote my first book “The Coding Dojo Handbook” in 2011. Coding Dojos are a great way of getting people to learn the basics of TDD and to begin to change the development culture. However, it became clear to me after some years that it’s not all that successful at making lasting change, particularly in organizations where the code quality is poor and TDD is difficult. There is too big a gap between the kind of kata exercises people do successfully in the Coding Dojo and the reality that hits them when they get back to their desks.

What I tried next - the Samman method

In 2018 I received a fantastic invitation from Llewellyn Falco to pair-coach with him. I spent two weeks in the US as his client and saw that what he was doing actually seemed to be working. He was using the same kind of group code Kata sessions that I was familiar with from coding dojos together with hands-on whole-team sessions in the production code. The combination seemed to be the key to making it stick.

I came home from that trip inspired to change direction in my consulting. Over the next three years, I found four or five organizations willing to let me try doing this new style of technical coaching. I also recruited a couple more people to work with me in the same way, and we developed the approach. Soon I wanted to share these effective techniques.

I decided this coaching style needed a name to distinguish it from other approaches, and to help people discover it. “Samman” is a Swedish word that means “together”. It seemed appropriate for a method that involves a lot of working in an “ensemble” - a French word that also means “together”. My new book “Technical Agile Coaching with the Samman method” was published in January 2021. 

What is the Samman method?

Samman 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. A Samman coach divides their time between several software development teams, and there are two main parts to the method:

• Learning hour
• Ensemble working

In the learning hour, the coach uses exercises and active learning techniques to teach the theory and practice of skills like TDD. In the Ensemble sessions, the whole team collaborates together with the coach in applying agile development techniques in their usual production codebase. (Some people may know Ensemble Working by another name: Mob Programming.)

Learning hour - like a short, frequent Coding Dojo

I’m sure you’ve had the experience of learning a new skill. Perhaps you’ve learnt a musical instrument, a foreign language, a new style of dancing, cooking or a new sport. If you’ve been successful, I expect you had some form of teaching or coaching as well as quite a few hours of dedicated practice. The best learning experiences usually involve being in a friendly group with an inspiring teacher and fun hands-on exercises pitched at just the right level. That’s the essence of a learning hour.

I’m very inspired by the teaching methods used by Sharon Bowman. Her best-selling book “Training from the Back of the Room” describes the “4C” teaching model. Each learning hour is structured with these four parts:

• Connect
• Concept
• Concrete practice
• Conclusions

A paragraph or so ago I asked you to recall learning a new skill. That’s a kind of “connect” activity. In order to learn something new, you need to integrate it with what you already know. It helps to give learners an opportunity to recall their previous knowledge and put it top of mind before you move to the next part, “concept”. 

Standing in front of a deck of slides and talking is one way to get a new concept across to people. It might not always be the most effective way though. You want to fuel their curiosity, get them to be active participants in their own learning. The brain thrives on variety, movement, social interactions and finding out for yourself. I generally try to minimize the amount of slides.

If the concept I want to get across is an aspect of TDD, I’ll most often do a short demo of the technique. If it’s a design pattern or testability problem I might give participants some code to review. For a new coding technique like parameterized testing, I might have them search the web for code snippets or design advice.

“Concrete practice” usually means writing some code and doing a practice code kata. This is often the longest section of the learning hour - about 30-45 minutes working either all together in an ensemble or in small groups of two or three. You can’t write a lot of code in that time, so you need to prepare a starting point and clear instructions so people can start to apply what they learnt about the “concept” straight away.

I’ve been using code katas for years in coding dojos, and I now re-use many of them in learning hours with little modification. The new exercises I’m coming up with now tend to be smaller and more focused on a particular technique though. I also often use the same kata to teach several things, and have several branches in the repository set up with different starting points. Supermarket Receipt is a good example of that. I use it for teaching refactoring as well as various aspects of approval testing.

Before the end of a learning hour, we always take a few minutes to work out our “conclusions” from the session. It helps people to remember something if they write it down in their own words, or explain to another person what they learnt. Finally, I encourage people to have another go at the exercise later on by themselves. Fluency comes from practice, and at some level you just need to put the time in.

Ensemble working on a typical task

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 Zuill and others close to him. Over the years since then, I’ve come to prefer other words to describe it. I usually say “ensemble”. I like the way this term implies friendly people collaborating, like a group of musicians. The essence of the technique is the same though. 

Just as musicians need to practice together before they create a really good sound, programmers need to learn how to collaborate smoothly in an ensemble. There are different roles you can play in the group, which require different skills. One of the first challenges of taking the “navigator” role is expressing yourself verbally about code and design. You need to say “declare a new variable” or “inline that return statement” when previously you’ve only ever typed that and not thought about what it’s called. Once you’ve got some new vocabulary though, it frees you to think at a higher level of abstraction, and open up for design discussions. Ultimately the whole team can get involved in doing the development work, pooling their knowledge, and producing code everyone is proud of.

I have observed the following many times in an ensemble setting: one person in the team knows how to do something. The ensemble needs to do that thing. Very soon everyone in the ensemble knows how to do that thing. It happens all the time - people learn from one another, knowledge and skills spread quickly. That was the key insight for me as a technical coach. Being part of an ensemble gives me superpowers! If I join an ensemble I can spread what I know in a very natural way as the need for it comes up, with the whole team at the same time.

When I’m coaching an ensemble, I often prompt them to use Test-Driven Development. When we’re discussing what to do I’ll ask them to sketch a test list. When someone starts to implement some code, I’ll ask them to write a test first. If we need to refactor I’ll ask them to do it in small, safe steps. If at any point they don’t know how to do that, I can step into the navigator role and show them. I try to stay in that role as short a time as possible - just long enough to change the direction. When someone else starts to feel confident to take over. I step back again.

A brilliant consequence for the coach in working in an ensemble is that you are also constantly learning new things from the teams you’re working with. Just by working with so many different people you pick up new tools, frameworks and design ideas, as well as being personally rewarding; this will also ultimately benefit the whole organization as you move between coaching different teams and spreading what you learn.

In the ensemble sessions, the team picks a task that is typical of what they usually work on. With the coach's help, the team learns to apply relevant agile development techniques. This is the crucial part that is missing if you only do practice exercises and coding dojos. This is where we start to see what agile techniques look like in this production code that my team works on.

When people are first learning ensemble working, two hours a day is long enough. That’s why the Samman method enables the coach to work with more than one team at once, if they want to. You can coach one team in the morning (two hours in an ensemble, one learning hour) and another in the afternoon. If you’re ambitious, you can coach three teams’ ensemble sessions and hold a joint learning hour each day. I have to say that’s a bit stressful though.

I’ve done this coaching both on-site and remotely. I think both ways work well, with different advantages and disadvantages. When you’re on-site you have the advantage of being able to read body language, and have quiet conversations on the side while the rest of the group continues working uninterrupted. When you’re remote you have the advantage that everyone can clearly see the code on the shared screen, and everyone has a comfortable chair, keyboard, monitor etc. It’s also easy for people to look up documentation or other parts of the code, since everyone has their own machine as well as access to the shared screen. 

I find that after ten half days of coaching, both the team and the coach benefit from a break; a few days or weeks before another similar 10-day coaching block. The team gets some time to continue the new ways of working without the coach, and are forced to find out what they really know and what they need more help with when the coach comes back. The coach gets a chance to plan new learning hours and perhaps pair-coach with others. They might onboard new teams for future coaching blocks. 

Observed outcomes

After one coaching block of 10 half days, I observed most teams get the hang of ensemble working to the point where they could do it without the coach being there. That in itself is a great skill for a team to learn - moving forwards they can decide when it’s helpful to use this collaboration technique. I have heard about teams subsequently choosing to ensemble on big design changes and when onboarding new team members. Some even adopt it as a regular part of their daily work.

The other main outcome I observed after only one or two coaching blocks was a change in attitude. In a post-coaching survey, the majority agreed they were:

• More likely to write unit tests
• More likely to improve design and refactor safely
• More likely to design readable, maintainable test cases
• More likely to work in small increments, committing code more often
• Improved teamwork, better collaboration

So far I haven’t worked with any large organizations that have been successful adopting TDD widely. I’ve seen several teams adopt ensemble working quite regularly, and beginning to write a lot more unit tests. The most notable changes I’ve seen have been in a couple of cases where one team member was already quite senior and had some skill with TDD. The coaching enabled them to get the rest of their team to actually begin to adopt the practice, where previously they’d only talked about it. 

Is Samman coaching for you?

I’m convinced the world needs more technical coaches. There are so many teams out there struggling with difficult code and lacking the technical agile skills needed to make good progress. There are many developers and technical leaders out there who perhaps have those skills but struggle to spread them widely and quickly in their organizations. Samman is a concrete method to bring effective development practices into the teams and organizations that need them.

About the Author

Emily Bache has over 20 years of experience as a software developer and technical coach, having worked in a variety of organizations from small startups to large enterprises. She is a well-known author and speaker on topics related to automated testing and technical coaching. She maintains a website with materials for technical coaches.