Techagilecoach

Technical Agile Coaching with
the Samman method

Emily Bache
This book is for sale at http://leanpub.com/techagilecoach
This version was published on 2021-04-07
This is a Leanpub book. Leanpub empowers authors and publishers

with the Lean Publishing process. Lean Publishing is the act of
publishing an in-progress ebook using lightweight tools and many
iterations to get reader feedback, pivot until you have the right book
and build traction once you do.
© 2019 - 2021 Emily Bache

Tweet This Book!
Please help Emily Bache by spreading the word about this book on
Twitter!
The suggested hashtag for this book is #coachingsamman.
Find out what other people are saying about the book by clicking on
this link to search for this hashtag on Twitter:
#coachingsamman
Also By Emily Bache
The Coding Dojo Handbook
Mocks, Fakes and Stubs
Contents
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Samman Technical Coaching . . . . . . . . . . . . . . . . . . . iii
Why would an organization engage in Samman Technical
Coaching? . . . . . . . . . . . . . . . . . . . . . . . . . iv
Why would you choose to coach using the Samman method? v
Elevator pitch for Samman Technical Coaching . . . . . . . vi
What is in this book . . . . . . . . . . . . . . . . . . . . . . . . vii
How this book relates to my other books . . . . . . . . . . . viii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . ix
The purpose of Samman Coaching . . . . . . . . . . . . . . . . . x

Development techniques . . . . . . . . . . . . . . . . . . . . . x
Levelling up a whole team together . . . . . . . . . . . . . . . xii
Expected outcomes . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Part 1: Ensemble Working . . . . . . . . . 1

Ensemble Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Typist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Team-members . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Group Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 5
Facilitator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Rotating roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Other ensemble roles . . . . . . . . . . . . . . . . . . . . . . . 6
The Coach role . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
CONTENTS
Let the Ensemble give you Superpowers . . . . . . . . . . . . . 7

Everyone understands the code . . . . . . . . . . . . . . . . . 7
Skills are multiplied . . . . . . . . . . . . . . . . . . . . . . . . 8
Visitors are quickly contributors . . . . . . . . . . . . . . . . . 9
Joining a smoothly functioning ensemble . . . . . . . . . . . 9
A Coach is a Visitor with an Agenda . . . . . . . . . . . . . . 10
Coaching Behaviours in an Ensemble . . . . . . . . . . . . . . . 11

Teach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Mentor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Facilitate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Coach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Observe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Take Short Breaks . . . . . . . . . . . . . . . . . . . . . . . . . 14
Retrospect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Breathing space between and during sessions . . . . . . . . . 15
Kindness, Consideration and Respect . . . . . . . . . . . . . . . 17

Woody’s Legacy Code rule . . . . . . . . . . . . . . . . . . . . 17
Yes, and . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Take time out . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Too much thinking at the keyboard . . . . . . . . . . . . . . . 19
I think <name> has a good idea we should listen to . . . . . 20
Consideration means paying attention . . . . . . . . . . . . . 20
Call out bad behaviour that can’t wait until the retrospective 21
Coaching Situations Illustrated with Stories . . . . . . . . . . . 22

What should we do now? . . . . . . . . . . . . . . . . . . . . . 22
Team, help your navigator . . . . . . . . . . . . . . . . . . . . 23
Can we do an experiment? . . . . . . . . . . . . . . . . . . . . 24
Discover scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intention, Location, Details . . . . . . . . . . . . . . . . . . . . 27
Reminder to test first . . . . . . . . . . . . . . . . . . . . . . . 27
Typist, use your shortcuts . . . . . . . . . . . . . . . . . . . . . 28
Consume-First Design . . . . . . . . . . . . . . . . . . . . . . . 29
How long is it since we saw feedback? . . . . . . . . . . . . . 31
How long is it since we made a commit? . . . . . . . . . . . 33
Only one person knows what’s going on . . . . . . . . . . . . 33
Nobody knows what is going on . . . . . . . . . . . . . . . . 34
CONTENTS
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . 35
Retrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Ask for Observations . . . . . . . . . . . . . . . . . . . . . . . 36
“Liked, Learned, Lacked” Observations . . . . . . . . . . . . . 37
Turn up the good . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Your private retrospective . . . . . . . . . . . . . . . . . . . . . 38
Retrospective skills are essential . . . . . . . . . . . . . . . . . 38
Remote Ensembles . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Seeing people’s faces . . . . . . . . . . . . . . . . . . . . . . . . 40
Be considerate and time your comments . . . . . . . . . . . . 41
Take breaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Make it quick to change typist . . . . . . . . . . . . . . . . . . 41
Typist lag is deadly . . . . . . . . . . . . . . . . . . . . . . . . . 42
Design discussions . . . . . . . . . . . . . . . . . . . . . . . . . 42
Retrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Part 2: Learning Hours . . . . . . . . . . . . . 44

Explaining Why you should hold a Learning Hour . . . . . . 46
Learning TDD is like learning to ski . . . . . . . . . . . . . . 46
Why should you spend a whole hour every day on learning? 50
Who should come to the Learning Hour? . . . . . . . . . . . 51
The Theory and Practice of Teaching and Learning . . . . . . 53

Learning Outcomes and Objectives . . . . . . . . . . . . . . . 53
The ‘4C’ learning model . . . . . . . . . . . . . . . . . . . . . . 55
Design learning experiences that fit with how the brain
works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Deliberate Practice . . . . . . . . . . . . . . . . . . . . . . . . . 62
Sample Learning Hours . . . . . . . . . . . . . . . . . . . . . . . . 64

1. Incremental working, Driven by Tests . . . . . . . . . . . . 65
2. Selecting and ordering test cases . . . . . . . . . . . . . . . 67
3. Golden Rule of TDD . . . . . . . . . . . . . . . . . . . . . . 71
4. Names of Refactorings, especially ‘Extract Function’ . . . 73
5. Misconceptions about Refactoring . . . . . . . . . . . . . . 76
6. Make a test list . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CONTENTS
7. Arrange - Act - Assert . . . . . . . . . . . . . . . . . . . . . 83

8. Start with the Assertion . . . . . . . . . . . . . . . . . . . . 85
9. One function at a time . . . . . . . . . . . . . . . . . . . . . 88
10. Inspirational Demo . . . . . . . . . . . . . . . . . . . . . . 91
Learning Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Small steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Refactoring safely . . . . . . . . . . . . . . . . . . . . . . . . . 94
Legacy Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Testable Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Designing Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Behaviour-Driven Development . . . . . . . . . . . . . . . . . 96
Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Add your own ideas . . . . . . . . . . . . . . . . . . . . . . . . 97
Remote Learning Hours . . . . . . . . . . . . . . . . . . . . . . . . 98

Cyber-dojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Everyone uses their local machine and screenshares . . . . 99
Retrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Part 3: Samman Coaching Engage-

ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Finding an Organization and Teams to Engage with . . . . . 102
Sales and Marketing principles . . . . . . . . . . . . . . . . . . 105
The Coaching Proposal . . . . . . . . . . . . . . . . . . . . . . 106
Proposal for a large organzation with hundreds of teams . . 109
Closing the Deal . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Identify your sponsor . . . . . . . . . . . . . . . . . . . . . . . 111
Beginning Coaching with a New Organization . . . . . . . . . 113

Present yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Kick-off Workshop with each team . . . . . . . . . . . . . . . 114
Chartering Workshop . . . . . . . . . . . . . . . . . . . . . . . 119
Offer Samman Coaching . . . . . . . . . . . . . . . . . . . . . 122
Persuading Reluctant Teams to be Coached . . . . . . . . . . 123
Practicalities Before Coaching Begins . . . . . . . . . . . . . . . 128

CONTENTS
When should we hold the coaching? . . . . . . . . . . . . . . 128

What task should we work on in the ensemble? . . . . . . . 128
What physical space should we use for ensemble working? 129
Should we use a branch for the code we write in an
ensemble? . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Turn Up the Good . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Decide on the next coaching . . . . . . . . . . . . . . . . . . . 132
Enquire about bringing in a visiting coach or two . . . . . . 133
Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Days Spent Away from the Teams . . . . . . . . . . . . . . . 135
A Career as a Samman Technical Coach . . . . . . . . . . . . . 137

Pair Coaching in a larger organization . . . . . . . . . . . . . 137
A Visiting Coach Programme . . . . . . . . . . . . . . . . . . 138
Preparing for a Technical Coaching Career . . . . . . . . . . 138
How I became a Technical Coach . . . . . . . . . . . . . . . . 141
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

What is the most important thing to remember? . . . . . . . 143
Where can I find out more? . . . . . . . . . . . . . . . . . . . 143
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Working incrementally in small steps . . . . . . . . . . . . . 145
Refactoring safely . . . . . . . . . . . . . . . . . . . . . . . . . 145
Legacy Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Testable Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Designing Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Behaviour-Driven Development . . . . . . . . . . . . . . . . . 146
Teaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Image attributions . . . . . . . . . . . . . . . . . . . . . . . . . 147
Foreword
Software development is best seen as a learning process where
running programs are the proof of learning, rather than a factory or
production process. That’s the first idea I found in Samman.
Learning works best together. Learning necessarily reaches beyond
the familiar. Fear of the unfamiliar slows & delays learning. Walking
a new path together along with an experienced guide reduces time
spent not learning because of fear. That’s the second idea I found in
Samman.
Learning is best experienced episodically. If you’re always stirring up
the pond, you never see the gold at the bottom. Learn a while. Digest
a while. Learn a while. That’s the third idea I found in Samman.
I first remember Ms. Bache from the XP 2002 conference in Alghero,
Sardinia. She asserted that unit tests wouldn’t help for the software
she was writing, then patiently waited while we fussed and argued.
Turns out she was right—there are programs where unit tests don’t
provide a double check of the behavior of the system.
In the 2 decades since, Ms. Bache has been working and communicat-
ing, continuing the program she started back then. Part of the project
is helping geeky teams learn and apply their learnings. Part of the
project is learning herself.
If you are haunted by the feeling that you and your team could be
doing so much more (wait, that’s my typical negative framing, let’s
try that again) if you are energized by dreams of working better
(that’s better), Samman is worth a try. Small cost, low risk, high
potential payoff. If, like me, you find you greatest satisfaction in
helping others reach their potential (“coach” is such a shallow word
for this experience), Samman is a set of mutually-supporting ideas to
make you more effective. I can’t wait to try it.
Kent Beck, December 2020
Introduction
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 decide to
try a technique they haven’t used 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
design 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
Introduction iii
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? It’s called the
Samman method and it’s a way of doing Technical Agile Coaching.
The rest of the book explains all about it.
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 devel-
opment 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 Test-Driven
Development and Refactoring. In the Ensemble sessions the whole
Introduction iv
team collaborates together with the coach in applying agile develop-

ment 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.
Why would an organization engage in

Samman Technical Coaching?
What’s in it for them? For the organization investing in coaching?
Well ultimately, increased business agility and success. If a company
is building a software product, then the way people write code
actually matters quite a lot. Specifically:
• Good technical practices mean the organization can build new

features with a shorter lead time and higher quality. That should
mean meeting deadlines and delivering reliable software. This
brings happier customers and a successful business.
• Skilled developers will want to work for an organization with
high quality code, effective development practices and a healthy
culture.
• The company needs to avoid drowning in technical debt. If it
piles up too much developers will ultimately be unable to deliver
any new features in a timely or cost effective manner. That is a
serious risk for any business.
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 techni-
cal and organizational practices, including Test-Driven Development.
Introduction v
In follow-up research¹ the same authors also found that technical debt
directly reduces developer productivity.
Why would you choose to coach using

the Samman method?
What’s in it for you as coach? Well, it’s the best method I know for
improving the code that gets written. Life as a developer is more fun
when the quality of the design and the tests is high. It’s easier and
faster to add functionality, please the users, meet your commitments,
keep your boss happy, all of that. Plus when the code is well-written
and the design is flexible you’re more likely to get to introduce fun
new tools and technology.
Those are all benefits of the end result - higher quality code. Benefits
for you personally doing the job as coach:
• It’s challenging and interesting. You never know what code the
team is going to put up on your screen, and you never know how
people will react when you ask them to work as an ensemble, do
TDD, refactoring etc. There is a lot of variety in the interactions
and the kinds of problems you face.
• You can have a bigger effect than you would in other roles. You
get to influence several teams over a few weeks of coaching.
Over months and years you influence several organizations.
• Teaching is inherently rewarding - witnessing someone start to
understand a new concept and recognize how they can apply it
in their work. That feeling when you see that happen. Gold.
I can’t cite statistically sound research to prove these points, unfor-

tunately. I just encourage you to try it for yourself and see if it
works. You should see improved code and happier teams following
your coaching. The other important question is whether you enjoy
working this way. I know I do.
¹https://cloud.google.com/devops/state-of-devops/
Introduction vi
Elevator pitch for Samman Technical

Coaching
In order to be successful in modern development organizations,
software developers need new skills. These skills are not easily learnt
on a short training course or at a university. Practices like Continu-
ous Integration and Test-Driven Development require developers to
change their minute-by-minute habits and ways of working.
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.
Day in the life of a Samman Technical Coach

Right here at the start of the book I want to give you an idea of how
a typical coaching day could be structured. This is a sample agenda
for coaching 2 teams, in Sweden, where office hours are usually 8-17
and lunchtime is generally 11:30 or 12:00.
08:00 Arrive, check messages, prepare for today’s sessions
09:30 Ensemble working with first team
11:30 Lunch
13:00 Learning Hour with both teams
14:00 Short break
14:15 Ensemble working with second team
Introduction vii
16:15 Debrief, reflect, write a summary report

17:00 Go home on time!
As you can see, the bulk of your time is spent interacting with
people and writing code: Ensemble Working. The next main item
on the agenda is a one hour teaching slot, the Learning Hour. The
rest of your day is spent preparing for those sessions as well as
communicating with others in the organization so the whole coaching
engagement runs smoothly.
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.
What is in this book

This is designed to be a useful handbook for someone working as a
Technical Coach using the Samman method. This introduction gives
you an overview. The next chapter goes into more detail about the
purpose of the coaching - what development practices a Samman
coach promotes. The rest of the book is structured in three parts:
• Part 1: Coaching in an Ensemble - why and how.

• Part 2: Learning Hours - how to plan and execute them.
• Part 3: The overall coaching engagement and your career as a
coach.
I have deliberately gone straight into some detail about ensemble

working in the first section of the book. I wanted to start with the most
exciting, challenging, interesting parts of being a Samman technical
coach. I’d like you to get an impression of what it is like to do this
job. Perhaps a more logical place to start would have been ‘what
kind of person becomes a coach’, ‘what skills do you need’ and ‘how
to get started’. That material is in Part 3. It’s important and useful
information, but first let me tell you stories about what it’s like when
you’ve got there.
Introduction viii
Of course I won’t be offended if you choose to read the parts in

another order than I’ve set them out here. If you’re not thinking of
becoming a coach yourself but perhaps want to hire one, Part 3 might
be more interesting for you than Part 1. Choose the starting point that
works for you.
How this book relates to my other

books
I’ve been a professional software developer for over 20 years, and
during that time I’ve learnt from a lot of great people. I have also spent
a fair amount of time teaching others, particularly in a forum called
‘The Coding Dojo’. In 2011 I published “The Coding Dojo Handbook”²
which is full of advice and experiences to help other programmers to
create such a forum. That book has been moderately successful, and
many programmers have used it to set up coding dojos and improve
their skills. Now, a few years on, I’m feeling the need to write another
book.
You can see this work as an expansion of some of the ideas and
methods I wrote about in ‘The Coding Dojo Handbook’. I’ve learnt a
lot in the roughly 10 years since I wrote it. You don’t need to read that
book to understand this one, I aim for them to be complementary to
one another.
In 2011, I was full of ambition to write a book called “Mocks, Fakes
and Stubs”. Unfortunately I never found the enthusiasm needed for
finishing it, and I don’t know if it will ever be finished. What I have
found enthusiasm for though, is continuing to write code, practice
on Code Katas, and teach others. I’ve been pleased to work with
groups of developers in many contexts, from evening user-group
meetings to company trainings, even an accredited course for an
adult education college. I believe all programmers need to continue to
develop professionally, and I have been finding more effective ways
to help with that. This book is an attempt to write some of them down.
²https://leanpub.com/codingdojohandbook
Introduction ix
Acknowledgments
The main ideas in this coaching method were originally developed
by Llewellyn Falco, and I continue to learn a huge amount from
him. This all started in 2018 when I did some pair-coaching with
Llewellyn and I was impressed with the results he was seeing with
his teams. (You can read about that story towards the end of the book
in the section “How I became a Technical Coach”). I have adapted
Llewellyn’s ideas for my situation and further developed several
aspects of the coaching method. I came up with the name “Samman
Coaching”.
I’d like to thank Llewellyn Falco for so freely sharing his knowledge
and methods with me. I’d like to thank all my colleagues at ProAgile
for all their support and inspiration. I’d also like to thank all the
early readers of this book who gave me feedback, including Samuel
Ytterbrink, Olof Bjarnason, Alexandre Cuva, Per Hammer, Grzegorz
Gałęzowski, Dave Nicolette, J.B. Rainsberger, Ester Daniel Ytterbrink,
Bill Wake, Jo Van Eyck, Joe Wright, Ted M. Young, Dianing Yudono,
Lars Eckart, Clare Macrae, Heidi Helfand, Philippe Bourgau, Sam
Cranford, Thomas Sundberg. I really value you taking the time to
help me write a better book.
The purpose of Samman
Coaching
A Samman coach aims for improved development practices in the
teams they work with. This chapter explains what those practices are
and what outcomes to expect from the coaching.
Development techniques
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. The next sections go
through the main practices we aim to introduce and promote.
Better unit tests

Developers should deliver a suite of automated unit tests together
with the code they write. The tests demonstrate each part of the code
works as the authors intended, and documents their assumptions. The
tests provide a safety-net for refactoring and make maintenance less
costly.
In many organizations there are explicit processes in place to ensure
that tests are written. However, many developers still struggle to
write good unit tests. Not many have received any training or
feedback about what tests should look like. In the worst case the tests
can actually increase maintenance costs without providing a useful
safety net.
The purpose of Samman Coaching xi
Continuous Integration
With the rise of Agile methods, Continuous Delivery and DevOps,
development schedules are being compressed and teams are expected
to deliver working increments of software more frequently. In my
experience, the way to confidently deliver a new version of the
software every 1-2 week iteration is to integrate and test the software
at least every day, so you always have something ready. If you
want deliveries even more frequently then you need a corresponding
decrease in the length of time between integrations. In general it
means the developers should work only for a few hours between
synchronizing and integrating their code together.
In many organizations the developers are used to working alone in a
branch for days or weeks before integrating their work. They don’t
know the incremental design and refactoring techniques you need to
be able to integrate more often than that. In the worst case everything
looks fine until shortly before the intended release date, when big-
bang integration happens with a string of bug-causing, schedule-
delaying merge conflicts.
Safe refactoring in legacy code

Developers often find themselves working with code that they don’t
understand very well but that they need to change. In this situation
it’s difficult to maintain the overall health of the design and develop-
ers are tempted to make small kludgy fixes. In the long run this just
makes the problem worse. The code becomes more and more difficult
to work with and developer productivity sinks. In the worst case the
organization has to throw this code away and start again.
There are techniques which can prevent this decline. There are safe
refactorings and migrations that developers can use to get difficult
code under control. There are ways to add regression tests without
taking big risks. If developers know the techniques and can use them
skillfully then you can avoid the need for a costly re-write.
The purpose of Samman Coaching xii
Incremental and Iterative Development

These days you don’t plan the whole software up front. You deliver an
increment, get feedback and adjust your plans. In the code, developers
need to use iterative and incremental techniques to develop the
design. You can’t plan the whole architecture up front.
Many developers struggle to iterate the design of the code. They don’t
know the refactoring tools, the design patterns or the signs to look
for that a different design is needed. These are teachable skills. It
is possible to maintain a long-term cadence of regular incremental
releases each with high quality. You need great automated tests and
a culture of constant design improvement.
Levelling up a whole team together

When I first learnt to do Test-Driven Development and Continuous In-
tegration 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
The purpose of Samman Coaching xiii
that a different future is possible. The coach helps them gain the skills
needed to go there.
Expected outcomes
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 this 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.
Measuring outcomes
Most people like to see hard evidence that something works before
they spend a lot of money on it. Or at least, they might let you start
The purpose of Samman Coaching xiv
coaching based on your reputation but soon afterwards they will

want evidence. Numbers help with that.
The first thing to measure is attitudes. A simple survey should suffice
to show that after the coaching developers are more enthusiastic
about using these techniques. After that you expect to see improved
code quality, increasing number of test cases, more frequent integra-
tion. Hopefully you can track those kinds of things by examining your
existing development infrastructure.
After a while of coaching you hope to see teams meeting deadlines
more reliably, reductions in production bugs, and fewer calls from
despairing developers who want to re-write the whole system from
scratch.
Ultimately you’d like to observe increased productivity. Unfortu-
nately it’s really difficult to measure the productivity of software
developers. A great deal of research has been done. I recently read
“Rethinking Productivity in Software Engineering”, a compendium of
essays from a number of researchers summarizing the state of the art
in 2019. My conclusion from reading it was that it might be possible
to measure productivity of software developers, but that it is really
difficult and probably outside the reach of most organizations I work
with.
You also need to be aware of Goodhart’s law. Anything you measure
and start to use as a target can become gamed, (ie people work to
get better numbers instead of improving anything important). Some
measurements are more susceptible to that than others. Any numbers
you gather need to be backed up by qualitative measures - talk to
people and find out if they think things really are improving or if it
just appears that way.
Part 1: 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.
I like the way the word “ensemble” implies friendly people collaborat-
ing, like a group of musicians. It seems to me to much better describe
what this activity is actually like in practice than the word “mob”. In
Sweden, (where I live), “mobba” actually means “to bully”. It’s not
a good association to make. Another change is I also prefer to say
“typist” instead of “driver”. I like to make it clear the person with the
keyboard is not in charge of the direction the group takes.
A note on pronunciation. “Ensemble” is originally a French word that
has been loaned into many other languages. In English I pronounce
it “on-som-bull”. Your own language may have another way to say it.
³https://leanpub.com/mobprogramming
2
This section of the book goes into some detail about what a Samman
technical coach actually does in the ensemble sessions, and why it’s
such an important part of your work.
Ensemble Primer
For those of you who have not experienced working in an ensemble,
a short introduction could be helpful here. Many programmers have
tried pair programming, and conceptually, working in an ensemble
is the same but with more people. You still have only one computer
being used to write code. Everyone present is responsible for the code
being produced, even though only one person at a time is typing.
However, for an ensemble to work smoothly you need more structure
and roles than you generally have in a pair. There are three main roles,
and you rotate roles frequently.
Typist
The typist is the person who has the keyboard and mouse. You use
the development tools and operate the computer. The important rule
here is that you are not allowed to decide what code to write or what
tests to perform. The typist listens carefully to everyone present, and
most particularly to the navigator. You enter the code the ensemble
has decided on, to the best of your ability. The navigator is usually the
spokesperson for the ensemble, but the typist may also follow advice
from other people. You can always ask questions to clarify what is
wanted and ask for more detail.
The typist should be in full control of the editor, the testing tools, the
debugger, the commandline, the refactoring shortcuts - everything
to do with operating the computer. Things like entering new code,
browsing through existing code, running tests and making commits.
Navigator
The navigator speaks for the ensemble and explains to the typist
what code they should enter into the computer. They speak in words,
Ensemble Primer 4
out loud, explaining the development activities they have in mind in

enough detail that the typist knows what to do. In this way, everyone
in the group both hears the navigator explain the work, and sees the
typist do the work.
At first this feels very strange - we are not used to talking about
code in this way. Many people don’t actually know the higher-level
vocabulary for talking about code. An inexperienced lead might say
things like “public int foo parenthesis int bar close parenthesis” when
they’d probably be better off saying “define a function called foo. It
takes one argument, an integer called bar”. You are talking to the
typist, not to a computer! They generally respond well to high-level
descriptions.
Team-members
Everyone who isn’t the typist is a co-navigator in the ensemble.
We all develop the software together. The aim is that the whole
ensemble should instruct the typist with one coherent voice. Usually
that means appointing someone to “be the navigator”. They lead the
work, they are talking and making the detailed decisions. Everyone
else is in a supporting role, quietly waiting for an opportunity to
contribute. With a more experienced ensemble, this leadership role
may not be explicitly appointed, it could simply pass fluidly between
members without any formal handovers. People chip in when they
have something valuable to contribute, and stay quiet otherwise.
Teammembers support both the typist and the navigator. If you know
a good keyboard shortcut the typist doesn’t seem to be using, you
can suggest it. If you can see a way to reduce duplication or improve
design, you can suggest it. The important thing is to choose carefully
when and how to make the suggestion. You don’t want to distract or
cause context-switching or confusion. If the typist and navigator are
getting along well doing something else, wait with your comment.
Choosing your moment to speak and knowing when it’s better to stay
silent is a really important skill. Having said that, it is important that
every member of the ensemble should follow what’s going on. You
should always feel free to ask questions so you understand the code
that’s being written. Just pick your moment wisely.
Ensemble Primer 5
Group Discussions
There will be periods when no code is being entered, and instead we
are discussing what to do. This is a normal part of coding work: we
need to agree on a goal, an approach, a design, a next test case… Many
discussions become more productive when you all stand around a
whiteboard or shared online document and can collaboratively sketch
your ideas. During these discussions you pause the ensemble roles
and let everyone take part equally. It’s wise to have a bias to action -
don’t discuss too long before returning to the ensemble and writing
some code together.
Facilitator
It’s worth remembering that working as an ensemble is a skill that
takes some time for a group to learn. It helps to have a facilitator
whose job it is to keep things working smoothly. This is usually
someone different from the typist or navigator since it’s hard to facil-
itate at the same time as doing one of those other roles. This person
will spend their time reminding people of the working agreements,
making sure roles rotate regularly, and helping the ensemble to reflect
and improve their work together.
As the ensemble gains experience the facilitator may need to inter-
vene less often. It may become a part-time position or disappear alto-
gether. To be honest, I haven’t worked with many really experienced
long-term ensembles and I’m speculating here.
Rotating roles
Most ensembles have some kind of timer that alerts the group when
it’s time to rotate roles. Many build their own - it’s a fun little piece of
software to implement. You can customize it with your own alerting
mechanism and decide exactly how intrusive it should be and what it
should suggest. Many such tools have a list of names and prompt the
next people that it’s their turn to be the navigator and typist. Other
groups have a more informal switching mechanism.
Ensemble Primer 6
Experience from many ensembles suggests it’s a good idea to ask

the person who is currently navigating to become the typist when
you rotate. As typist they have to stop leading the ensemble, and
someone else naturally then finds it easier to step into that role. Other
ensembles prefer to do it the other way around - the typist becomes
the navigator. Typing gives them a good introduction to what’s going
on and they can seamlessly take over when it’s their turn to navigate.
Other ensemble roles

As well as typist and navigator, there are other roles that people
can take as the need arises. A common one is “Researcher”. If the
ensemble gets stuck because no-one remembers the exact syntax or
library function to use, someone can offer to research it. While the
ensemble continues with some other task, the researcher gets onto
another computer and searches the internet. When they have found
something useful they could paste a link into a shared group chat,
or otherwise share it with everyone. The researcher can then take
up their normal role as an ensemble member and explain what they
found out when the group asks for it.
Another useful role to have is “Archivist”. It can be helpful to have
someone writing stuff down - decisions the group makes, alternatives
we looked at, designs we’re following. In particular the archivist
might keep track of the current goal the ensemble is working towards.
It could be written on a whiteboard in the working area, a shared
online document or noted in a ToDo list in the ensemble’s timer.
The Coach role

Now you have a basic understanding of what working in an ensemble
entails, the rest of this section of the book explains how you as a coach
can use this forum to promote better ways of working in the code.
Let the Ensemble give you
Superpowers
Working as an ensemble seems to me to be useful in many circum-
stances, 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.
Coaching an ensemble is generally really challenging, as well as
rewarding. You need to be on your toes technically as well as
interpersonally. On several occasions I’ve had some of the most fun
I’ve had while programming. You learn as much from the team as
they learn from you, and you can keep your technical skills sharp and
and up-to-date as you continue to write code every day. You should
go into it with a healthy respect for the skills and experience of the
people you’re working with, and offer them your full attention.
This chapter explains why ensemble working is so beneficial. I’ve
watched teams who work like this regularly, and are really good
at it. A smoothly-functioning ensemble is an amazing collaboration
to witness. First let’s talk about the benefits of programming in an
ensemble.
Everyone understands the code

When you work together in an ensemble, everyone is involved and
has a stake in the code you write. That’s the reason for the original
name, “mob”. When an angry mob runs riot and smashes up things,
you can’t pin the blame on any individual, the responsibility is
collective. As already noted, I prefer to say ‘ensemble’ instead of
‘mob’. If you think of an ensemble of musicians it’s pretty much
the same only less angry! Everyone in a mob or ensemble owns the
outcome. It’s produced together.
Let the Ensemble give you Superpowers 8
Think about this for a minute. If everyone on the team understands

and feels a collective responsibility for the code, that is bound to
improve the way you work together. Junior team members are
brought up to speed rather quickly. Team norms for simple things
like how to format code and place curly brackets will quickly get
established. Over time you build up team norms for more interesting
behaviours like how to write tests and which design patterns are
appropriate in which situations.
Skills are multiplied

I have observed the following many times in an ensemble setting. One
person in the team knows how to do a thing. The ensemble needs to
do that thing. Very soon everyone in the ensemble knows how to do
that thing. It shouldn’t really be surprising but somehow people only
notice this when they compare with how slowly knowledge dissem-
inates when people work individually. In a team where everyone is
responsible for their own tasks, it easily happens that the one person
who knows how to do a particular kind of task always does it.
If there is an intermittent need for, say, kubernetes configuration
updates, the same person tends to take those tasks every time. They
eventually become a kubernetes expert and no-one else knows how
to do anything without asking them. Over time they become a
bottleneck and a silo of knowledge.
In an ensemble, when a task comes up that involves kubernetes
configuration, the one person who knows how to do it steps up to
navigate. They explain in words what should be done. The typist
writes the correct syntax into the computer, asking for more detail
as necessary. Everyone in the ensemble both hears the description
and sees the code. They have a chance to ask questions and request
background information. The navigator gets to show off a little and
explain what they know. Everyone’s happy!
More importantly, the next time a similar task comes up hopefully a
different person will know enough to take the navigator role. If they
get stuck, the original expert is there in the ensemble, able to give
advice. Knowledge is increased when you share it.
Visitors are quickly contributors

When you join a development team as a new member, how quickly
are you a net plus? How soon will the time they spend telling you
stuff will be outweighed by the value of you contributing stuff? A
few days? Weeks? I’ve observed in an ensemble setting the time to
net positive contribution is reduced drastically. I’d put it at minutes or
perhaps hours before you are a net positive for the team. Particularly
as an experienced developer, if you sit down in a team ensemble you
will pick up loads of team norms and code details within minutes,
almost without effort.
You will not have seen the particular codebase before, but the people
around you are talking about it animatedly and explaining what they
are trying to achieve. They can explain design details and things
you’re curious about if you are hazy on details. You may not have seen
the particular programming language before, but it’s probably similar
to one you know already. You’ll recognize the general shape of the
design and many of the words being used by the navigator are generic
for any programming language. Loops, conditionals, polymorphism,
closures, functions, references. The people around you can explain
specific pieces of unfamiliar syntax if needed.
Joining a smoothly functioning

ensemble
Imagine turning up for work and seeing an ensemble of programmers
working smoothly together building a feature. (Imagine you’re not
their coach, just a colleague from a different department visiting for a
morning). You take a seat near the back and observe for a few minutes.
You spot an opportunity for a refactoring to increase readability. No-
one in the group seems to notice it. Next time the tests are green, you
politely suggest the change. The team is interested and asks you to
explain further. They ask you to navigate the change, which you do.
For a few minutes they discuss whether they like the refactored code,
and eventually conclude they do. You go back to your seat and they
carry on programming from where they left off.
After a while longer you feel you understand the direction the
ensemble is taking, and what the current feature is all about. You
ask to join the ensemble rotation and are added to the list in the
timer. Typing is tricky at first but people soon tell you the keyboard
shortcuts for their coding environment. While in the ensemble you
are able to answer a couple of questions and help the navigator. When
it’s your turn you pick up the navigation and carry on without it
affecting the flow of work or overall direction of the ensemble. After
a few hours you are working smoothly in the ensemble, you have
influenced the code in many small ways. You have contributed some
of what you know and learnt more about the struggles and challenges
of this particular team.
A Coach is a Visitor with an Agenda

If you had a smoothly functioning ensemble like the one above,
what would you be able to contribute? How would the code be
written differently because of your presence? Of course it depends
on the situation, but I’d hope that we’d have written a few more or
better unit tests. Probably reduced coupling and increased cohesion
via a few well-placed refactorings. Perhaps discovered a few more
capabilities of the IDE that the team can start using. In the long term
we’d be using more design patterns, increasing testability, building
features in smaller batches and writing excellent quality code.
When you coach a team you are there to help them to write better
code. If they are working smoothly in an ensemble you will find
ample opportunity to do that, for all the reasons listed above. You
quickly understand the code, share your expertise and promote team
agility.
In most coaching engagements, the first step will be to teach the team
to do work as an ensemble. It’s a skill in itself that takes time and effort
to master. An awkward, inexperienced ensemble that isn’t really
holding a direction consistently or collaborating well is challenging
for a coach to work in. I think it is worth persevering with them and
reaching a fuller maturity. A smoothly collaborating ensemble is a
fantastic forum for a coach, it gives you superpowers.
Coaching Behaviours in
an Ensemble
When you are working with a team ensemble you can help them
to apply iterative and incremental development practices in their
real production codebase. You can help them to write unit tests and
integrate their work often. Of course you need to adapt your approach
depending on the situation. The following sections go through some
of the various behaviours you use in the ensemble to help the team.
The first four of these approaches are outlined in the Coaching
Competency Framework⁴. All coaches exhibit these behaviours at dif-
ferent times, here I give some examples of what a Samman technical
coach might say and do.
Teach
As well as prepared learning hours, you will sometimes teach in the
ensemble sessions. An ideal teachable moment might arise when you
notice they need a particular technique that they haven’t used before.
You can outline some theory, go through some concepts, then mentor
them through using the technique straight afterwards. If you teach
something just as they need it, then you increase the chances they
will remember that technique and when to use it.
Perhaps you’re in an ensemble and you come across a long method in
the code. You want to suggest a refactoring ‘extract method object’,
but the team has only done ‘extract method’ before. They struggle
to understand what that new refactoring does. You pull out some
teaching materials and do some or all of:
• Explain how this refactoring is similar to one they already know

⁴https://www.agilecoachinginstitute.com/wp-content/uploads/2011/08/Agile-Coaching-
Competencies-whitepaper-part-one.pdf
Coaching Behaviours in an Ensemble 12
• Step to the whiteboard and explain the new refactoring with a

sketch.
• Ask them to browse to refactoring.com and read Martin Fowler’s
description
• Put up some slides you have pre-prepared that explain this
refactoring
• Open up a code kata and do a quick demo of this refactoring for
the group
• Take the Navigator role and lead them through this refactoring
in their code, step by step
It’s a real skill to spot these teachable moments, and to be able to bring
out relevant teaching materials quickly. Don’t be afraid to pause the
ensemble rotations and teach for a few minutes.
Mentor
This is where you help the team to apply specific techniques in their
codebase, and build their capabilities. The team should already have
some understanding of the theory of the technique, perhaps already
tried it in simple exercises. Now you lead them step by step, with a
lighter and lighter touch as they become more competent.
For example, you want them to start doing Test-Driven Development.
You notice they begin to write some production code for a new
feature, and there is no unit test for it yet. Ask them to pause the
new feature and write a test for it first. What you do then depends
on the competence of the team at writing unit tests. Perhaps it will be
enough just to remind them they should have one. Perhaps you will
need to step into the navigation role yourself and write the whole
test.
As the team gets more familiar with the skill you are mentoring
them in, spend less time navigating yourself. You want to build their
capabilities not show off your own! Hand back to a navigator from
the team and instead prompt them with ‘coaching questions’ as they
get stuck. Only take over the navigation if they are not making any
progress, or are heading rapidly in the wrong direction.
Facilitate
A facilitator conducts a process without having an opinion about the
content. Usually you do have an opinion about a lot of what goes on
in the ensemble, but not everything. In certain situations, facilitation
can be the best way to help the team to move forwards.
For example, perhaps there are two design suggestions being put
forward, and the group can’t agree which is best. You think either
might work. Facilitate the process of setting up a new branch to try
suggestion 1 in a timebox, then starting over with suggestion 2 in a
different branch for an equivalent timebox. When both the suggested
approaches have been tried, facilitate a discussion about which design
to choose.
Coach
This word is used in many contexts. Here I’m talking about “Profes-
sional Coaching” as the ACI⁵ or ICF⁶ would call it. You partner with
people and support them to achieve their goals. You work from the
assumption that they have the answers within themselves, and your
job is to help them to fulfill their promise. A key tool is the ‘coaching
question’ that evokes action without telling them what you think the
action should be.
As a Samman technical coach you do have opinions about the
direction you want people to take. You want them to learn to work
together as an ensemble, do refactoring, TDD etc. Before you can do
this ‘Professional Coaching’, they need to not only aspire to use those
kinds of development techniques, but also be skilled enough to be
able to do them. In that case, asking ‘coaching questions’ becomes a
great way to help them to change their behaviour.
For example, a new team member takes the navigation role when the
previous navigator had just begun defining a new test case. The new
navigator gets stuck and don’t know what to write. You think they
⁵https://www.agilecoachinginstitute.com/
⁶https://coachfederation.org/
know what the test is for but are temporarily flummoxed. Ask ‘what
is next on our list of scenarios?’. That could help them to remember
you have a list of scenarios for the current user story, and that the
name of the scenario will help them to name the new test case.
When they have named the test case, they still look stuck. Ask ‘What
would you assert if this scenario was working?’. Working backwards
from Assert to Act to Arrange when writing a test is a technique I’ll
have taught them in a learning hour, and that prompt may be enough
to get them to use it in this situation.
If this kind of prompting isn’t enough, I’ll switch to mentoring or
teaching.
Observe
You may not need to intervene. If the ensemble is working well,
your best strategy could be to stay in the background and observe
the interactions and the code that is being produced. By staying
quiet for a while, you can give your whole attention to language
and tone. You can get a feel for whether the rhythm of test-code-
refactor is sustainable. You can see with your own eyes that they
have learnt to use the development techniques you’ve been teaching
them. Probably, you will see some things that could be improved. You
might see things the other ensemble members are unaware of, that
they would change if they did.
For example, you might note that a particular person is saying things
that are useful but people are not listening properly. Perhaps they are
not even aware that they are discounting that person’s views. You
could note down what you see and bring it up in the retrospective.
Take Short Breaks

You do not need to be present all the time! In an ensemble session
everyone should feel free to leave for a few minutes to get a coffee
or fix a small errand. That applies to the coach too. When you take a
break, you also force the team to fend for themselves and continue
working without you. One of your ultimate goals as is to make

yourself entirely dispensable. Before deciding you can leave a team
entirely, see what happens if you take a slightly longer break during
an ensemble session. How are they doing when you get back?
Retrospect
When there is around 15-25 minutes left until the scheduled end of
the session, I will call a halt. Preferably just after we made a commit,
or I will suggest we round off and make a commit. It can happen a
few minutes before that if we reach a good point to stop. Occasionally
I lose track of time and forget to stop at all until the next session is
due to start - this is not a good thing!
The reason for stopping programming before the end, is to get the
team to spend some time reflecting on what happened, so they can
realize consciously what they have learnt. For example, Sam might
not have noticed how frequently they have been making commits,
until Jenny points it out. Once Sam has consciously acknowledged
what happened, he can ask questions about why that was a good thing
to do. He can start to examine how he usually behaves and reason
about it. If all he had done was experience frequent commits, then
gone back to his desk to work alone again, it’s possible that could
have led to a change in behaviour all by itself. By making him think
about it, though, you increase the chance he will consciously try to
change his behaviour.
Breathing space between and during

sessions
In the middle of a 2 hour session, I usually have the whole group
take a 5 minute break. Everyone benefits from a short leg stretch and
opportunity to get a coffee. Similarly at the end of the session I’ll
make sure to finish on time or perhaps a few minutes early.
For a remote ensemble session this isn’t so relevant, but in an office
setting you need a few minutes to tidy up the room at the end. As
everyone leaves, take a picture of all the retrospective sticky notes,

so you can refer to them later. Perhaps tidy away mugs, straighten
chairs, put sticky notes away. Make sure you have a few minutes to
rest before starting something new.
Kindness, Consideration
and Respect
Members of an ensemble should treat one another well and feel safe
to express themselves. Often an ensemble will adopt this rule:
We treat everyone with kindness, consideration and respect
I learnt this from Woody Zuill and most of the ensembles I come
across use it too. Interestingly, research shows that the people we treat
kindly are the people we end up liking, rather than the other way
around. The coach has a particular responsibility to help the ensemble
to set up a sound working agreement including this kind of rule, and
to help them to uphold it. In this section I’ve collected some situations
where the coach should step in and do this.
Woody’s Legacy Code rule

Honor the coder and their code. The constraints they endured are not
mine to know.⁷
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 they had 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.
⁷https://twitter.com/woodyzuill/status/848362834715041793?lang=en
Kindness, Consideration and Respect 18
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 judgmental comments that criticize the original
author. Working in an ensemble exposes a lot about everybody
involved, and we need to feel safe and supported.
Yes, and
In improvisational theater, they have this rule. Say ‘yes, and’ to your
fellow actors while you perform together. It means you should accept
whatever they give you, and build on it. I’ve only seen this kind of
theater a couple of times, but on both occasions bizarre and funny
situations arose, the actors clearly having a brilliant time creating
together.
If the actors instead say “No, but…” and start in another direction
entirely, it breaks the group flow and hinders the creativity. The actors
know it will be a better performance if they support one another.
This is the kind of spirit we want to cultivate in the ensemble. Do not
delete or undo what the previous navigators did before you. Refactor
but do not rewrite. Say ‘Yes, and’ to whatever your colleagues give
you.
Take time out

If ensemble members feel unable to uphold their working agreements
then the coach should encourage the ensemble to take some time out
for everyone to calm down. Spend 15 minutes all going to get a coffee
or taking a walk around the block. Some people may take longer to
return than others, that should be fine. Start with a smaller group who
are all calm enough to work together well. You want to re-establish
trust and respect. Bring in additional ensemble members as and when
they are calm too. You may need outside help if the problems recur.
Bring in the Scrum Master or manager and book 1-1 meetings with
people if necessary.
Happily this hasn’t happened to me much. I can tell you of one
occasion where it did though. I was working with another coach,
and I had actually asked him to coach the ensemble while I took a
navigator role together with about six others who all worked in the
client organization. At one point I was lead navigator and writing a
new test case for a class that didn’t exist yet. I hadn’t quite worked out
what the best design was, whether to pass arguments to a constructor
or to have a static method. I had asked the typist to write the ‘arrange’
step one way and was going on to start writing the ‘act’ and ‘assert’
steps of the test.
My colleague stopped me and asked me to not write any more code
before getting it to compile. He wanted the code to be in a good state,
close to green, ready to hand over to the next navigator. Creating the
class would have been a couple of trivial clicks in the IDE. I wanted to
defer the design decision until I’d seen the whole test. He was insistent
that I not write any more code before having it compile. I held my
ground and asked to finish writing the test before creating the class.
We both got a bit angry, which was absolutely not a good way to
behave!
I don’t remember which of us suggested we take a time out but it was
exactly the right thing to do once we had got into that bad situation.
We all left the room, got coffee and calmed down. I realized that
since he was coaching I really should have deferred to his judgment.
Apologies were exchanged and relationships repaired. Us arguing was
a terrible example to set and I am still embarrassed when I think about
it. Even experienced coaches have a bad day sometimes!
Too much thinking at the keyboard

Consideration is really all about listening. One ensemble role that
does a lot of listening is the typist. The typist is not supposed to
have their own ideas, they should be channeling the ideas from
the navigator and the rest of the ensemble into the codebase. So
many programmers are used to only coding by themselves and being
valued for their individual contributions. It’s easy for people to just
start writing the code they think of without waiting for any verbal
instructions.
Not listening as a typist is inconsiderate behaviour. You lose a large
part of the magic that makes working as an ensemble so valuable.
The design should be spoken by the navigator before it is coded by

the typist. It’s the primary mechanism for spreading knowledge and
enabling collective code ownership. Everyone in the ensemble has
the chance to both hear a description of the code, see the syntactically
correct code appear in the editor, and an opportunity to ask questions.
If the typist starts coding before a navigator has asked them to, step
in and remind them to listen instead.
It also happens semi-frequently the other way around. That the
navigator asks the typist to do something, and they do nothing at all.
Perhaps they are simply not paying attention or perhaps they think
the navigator’s ideas are bad. Whichever, you should politely remind
them to write the code or ask for clarification. You don’t want the
typist to argue with the navigator at this point. If the ideas are bad
it will be much easier to judge that when the code is written. The
typist should hold their criticisms until they are in another role and
can voice them with kindness, consideration and respect.
I think <name> has a good idea we

should listen to
Everyone in the ensemble should be listening to one another, and
sometimes you get good ideas being spoken but no-one pays attention.
Often the idea is softly spoken by a more introverted navigator. Use
your facilitation skills to call attention to those good ideas. Over time
the ensemble will learn the habit of listening to everyone and people
will learn to wait for the best moment to contribute their idea. As we
gain experience of being heard, we change the way we speak.
Consideration means paying

attention
It’s happened to me a few times that people in the ensemble get
distracted by their phone or laptop. They start responding to email
or checking twitter. As a coach you don’t want to encourage this,
but it’s hard to call people out without making them feel unsafe or
reprimanded like a child. A better approach is probably to increase

the rotation speed so they end up leading the navigating more often.
Perhaps ask them to look up something on stack overflow ‘since you
have your laptop out already’. Draw their attention back to the task
in hand.
Call out bad behaviour that can’t wait

until the retrospective
This has happened to me rarely, but occasionally someone says or
does something directly insulting or harmful. You’d like them to stop
and never repeat this behaviour. A useful phrase is “we don’t do that
here”. It makes it clear the behaviour is not accepted in the ensemble,
without being too confrontational. If they defend themselves and
perhaps try to claim it was only a joke, be polite but firm. “I’m sure
that’s true, but still, we don’t do that here.”
Coaching Situations
Illustrated with Stories
You spend so much of your day coaching an ensemble as they
program, this chapter is all about how you could behave. I’ve written
some short fictional exchanges to illustrate what could happen and
how you might handle it. When everything is going well, you will not
be saying very much at all. These are all examples where the coach
steps in to change something.
What should we do now?

All the tests are green and Christie has just stepped up to navigate.
Christie - “…” (looks worriedly at the code on the screen)
Coach - “What should we do now?”
Christie - “…” (looks worriedly at the coach)
Coach - “What stage are we in the TDD cycle?”
Christie - “…” Coach - “What stages are there in a TDD cycle?”
(points at whiteboard where there is a sketch of them)
Christie - “Red, Green, Refactor”
Coach - “Which stage are we in now?”
Christie - “the tests are green”
Coach - “Great. So what should we do now?”
Christie - “… Refactor?”
(looks worriedly at the code on the screen)
Coach - “Do we have any code that needs refactoring? Code smells?”
Christie - “long method?”
Coach - “Great, what should we do now?”
Christie - “we should extract a method”
The coach asks ‘What should we do now?’ to determine whether the
navigator has direction, or whether they are lost. Having understood
Coaching Situations Illustrated with Stories 23
that Christie lacks direction, the coach asks leading questions⁸ to help
her to find a direction. In this example the navigator was silent, but
if they give a plausible but vague answer you should also push for
more information.
Liz - “…” (looks worriedly at the code on the screen)
Liz - “… make it work…” Coach - “what is it that is not working yet?”
Liz - “…” Coach - “we have some scenarios we wrote up earlier. Are
all of those working yet?”
Liz - “we haven’t done error handling for duplicate items yet”
Coach - “Should we write a test for that?”
On the other hand, you might find the navigator knows the direction
they want to take, and were just thinking for a moment
Charlie - “…” (looks worriedly at the code on the screen)
Charlie - “We need a test for the error handling scenario”
Coach - “Great, let’s do that.”
As a coach, you should help the navigator to find a direction.
Team, help your navigator

These are stories about ensemble members supporting their navigator.
Navigator - “I think we need to refactor this, but I’m not sure how. I
can see duplication between test cases”
(pause)
Coach - “Team, can you help your navigator here?”
(pause)
Anders - “Could we extract a factory method to create the Trobastin
instance?”
(pause)
Navigator - “yes. Go to line 23…”
In this example someone in the ensemble contributes the direction.
The coach is taking a less active role and encouraging the group
⁸A ‘leading question’ is one where you have a hidden agenda - you know what answer you
want them to give.
to solve their own problems. This is a good strategy for a coach

when the team has some experience and the coach is trying to make
themselves dispensible. The navigator gets a good suggestion and is
able to continue in that direction.
Sometimes the navigator isn’t immediately able to follow the sug-
gested direction. In this example Christie has just stepped up to
navigate, and appears to be lost.
Christie - “…” Coach - “Team, please help your navigator”
Filip - “we should extract a method to reduce duplication”
Christie - “…” Coach - “Can you help Christie see which lines are
duplicated?”
Filip - “lines 23-27… and 34-38”
Christie - “…” (looks blank)
Coach - “Christie, perhaps Filip could take the navigation for a
moment?”
Christie - (looks relieved) “sure”
Filip - “ok. We should extract a variable first …” (Filip navigates some
of the refactoring, then the ensemble timer pings)
Coach - “Thanks Filip, Christie, can you carry on now?”
Christie - “ok. The new method doesn’t compile, so let’s fix that…”
Here the coach facilitates a transfer of the navigator role to someone
in the ensemble who had direction. This helps the team to make
progress. You have to be careful to not make the original navigator
feel snubbed or stupid or overlooked. It should feel ok to hand over
and safe to take back the navigation later on.
Can we do an experiment?
The ensemble is stuck discussing options and no code is being written.
There is general disagreement about whether it’s a good idea to
import a particular header file.
Coach - “This is an interesting discussion. Some people are saying
they think compile time would be reduced if we pre-declared the class
instead of importing the header file. Can we try it both ways and com-
pare the compile time? Deepak, can you navigate an experiment?”
Deepak - “Yes ok. Can you add the header import and check the
current compile time for a clean build?”

Typist - “35 seconds”
Deepak - “Ok, and now change the import to a pre-declaration of the
class, and time the clean build again”
Typist - “32 seconds”
Deepak - “ok so that header import was a lot heavier than I realized!
Shall we carry on with the pre-declaration?”
Ensemble - (general agreement)
Here the coach reminds the ensemble that they should be pre-
disposed to action. To settle a disagreement, try writing some code. As
a coach it can be tempting to just decide which is the best option and
tell them to do that. It’s often better to instead propose an experiment
to try each option in turn. You want people to know their opinions and
ideas matter, and you might be surprised at what the team actually
prefers when they have seen the code written.
Discover scenarios
The team has just started working on a new task. They would like to
work with TDD but have only done it before with simple code katas.
The coach might help facilitate scenario discovery and making a test
list. The coach steps up to the whiteboard.
Coach - “can someone explain this user story?”
Frank - “We receive a customer record from the mainframe and we
should process it then notify our users about the change”
Coach - “Can you think of a simple example?”
Frank - “A new customer record. We haven’t got it already.”
Coach - “Sounds like a good scenario. How do we know it’s new and
we haven’t got it already?”
Frank - “The externalId is not found when we search for it”
(Coach writes on the board: “new customer: externalId not found”)
Coach - “How will we know when we’ve processed it correctly?”
Frank - “We send out a notification about the new customer”
Coach - “Anything else? Should the new customer appear in searches?”
Frank - “Yes, it should appear in searches through the api.”
(Coach adds these details to the ‘new customer’ scenario)
Coach - “ok, what other scenarios are there?”
Mirrim - “The externalId exists but has updated fields”

Coach - “what should we call that scenario?”
Mirrim - “…”
Frank - “update existing customer?”
(Coach writes on the board: “update existing customer: externalId
found, updated fields”)
Coach - “what kinds of fields might be updated?”
Mirrim - “ address, phone number, that kind of thing”
(Coach notes this next to the ‘update’ scenario)
Frank - “we should also handle the case when we have a different
customer with that updated phone number - the records will need to
be merged”
Coach - “sounds like another scenario. Shall we call it merge cus-
tomers?”
(Coach writes on the board: “merge customers: externalId found,
phone number matches other existing customer”)
…
(discussions continue)
In this example we see the coach facilitating the ensemble. They are
making a list of a handful of scenarios on a whiteboard which will
turn into automated test cases as part of the TDD process. This can
take perhaps 5-15 minutes during an ensemble session. Teams often
need practice at writing good scenarios and you could run a learning
hour on this topic.
Once the scenarios are written up on the whiteboard, you can refer to
them later, to help the ensemble maintain a sense of direction. When
the tests are green and the group is looking for a new test to write,
the scenarios should help them.
Record the scenarios

Get someone from the ensemble to take ownership of recording
the scenarios so they are not lost at the end of the session. They
could:
• take a picture and post it to the team slack channel

• attach a picture to a Jira task
• make notes they send in an email to the team

• write comments in the sourcecode and check them in
Intention, Location, Details

The coach helps the navigator to express themselves so the typist
understands better.
Dima - “Can you show me the main switch statement?”
Typist - “…” Dima - “In Chamwas”
Coach - “Dima, say the location?”
Dima - “It’s open in a tab. At the top. The filename is Chamwas.cpp”
The navigator has given a high-level instruction that the driver didn’t
get. The coach reminds the navigator to follow it up with a location
on the screen. The general rule for the navigator is
1. Intention
2. Location
3. Details
First the high-level intention - what direction are we taking. This is

helpful for both the typist and the rest of the ensemble. It helps the
next navigator to take over smoothly.
If the typist doesn’t get it right away then the next communication
strategy is for the navigator to tell them the location on the screen.
Often that’s enough for them to carry on. If that still doesn’t work,
start dictating details. Down to the level of “type a curly bracket then
a newline…0”. (This is a last resort).
Reminder to test first

All the tests are green and Tobias has just stepped up to navigate.
Tobias - “Can you go to the start of the frizzbleAccount method we

were just working on?”
(pause while the driver finds the method)
Tobias - “Add an if statement - if (frizzbles.contains(frooble))...”
Coach - “Wait a minute, can you just explain at a higher level what
you want to achieve here?”
Tobias - “We need to handle the case when the incoming frooble is
identical to an existing one”
Coach - “That’s a really good point, we do need to handle that case.
Can you write a failing test for it?”
Tobias - “Ah, no. Right.” (addressing the typist) “Can you go to the
Frizzble test case? We should add a test for this first.”
In this case the navigator has direction, and has jumped straight into
the details. Firstly the coach gets them to explain their direction, and
also to raise their language from details to intentions. Then they give
a nudge. “Do you have a test for that?” reminds the navigator that
one of their aims is to do Test-Driven Development. The navigator
continues in the new direction.
Typist, use your shortcuts

Kris - “Let’s declare a new test case for the ‘merge’ scenario”
(Typist starts typing the declaration of a new test method. They are
quite slow at typing and before they get as far as ‘@Test public void’
the coach steps in)
Coach - “Typist, Quin, wait. Please use your shortcuts. You could
generate that code.”
Quin - “… uh … How?”
Coach - “Anyone know?”
(silence)
Coach - “You can search for an action with Shift-Command-A. Try
searching for ‘generate’”
The navigator has given a clear direction but the typist is not using the
full power of their tools. As a coach you can help the ensemble to be
more effective at using their IDE. It’s a quick win for many teams.
I usually find people have little idea how much power they have
available in modern tools and learning just a few common shortcuts

speeds everything up.
Once they have seen a shortcut once, it should be enough to just
remind anyone who is typing to use their shortcuts. I often ask
them to undo their typing and go back and do it again with the
keyboard shortcut. Ideally someone from the ensemble will tell them
the key combination if they’ve forgotten. It slows the group down
momentarily, but enables a bigger speedup later as subsequent drivers
start to use the shortcut without being prompted.
Consume-First Design
Kris - “In the VehicleDiagnostics class we need a new method
determineEngineState.”
Typist - types
1 public void determineEngineState(|)
(ensemble timer goes off, Kris moves to typist and Trish steps up to
navigate)
Trish - “… uh … was this method supposed to return something?”
(silence)
Coach - “I think we should be doing Consume First. Where is this
new method used?”
Kris - “From the detectGeofenceIncident method. We only want to
send an incident alert if the engine is on.”
Coach - “Go to that method and add the call as if the determineEngineState
method already existed”
(typist brings up the method)
1 public void detectGeofenceIncident(Point newPosition)

2 throws GeofenceIncident {
3 for (GeofencedArea fencedArea : this.allFences) {
4 if (fencedArea.contains(newPosition)) {
5 throw new GeofenceIncident("New position lies inside
6 fencedArea, newPosition);
7 }
8 }
9 }
Trish - “Ah ok. So we should add a condition on line 3 here. After the
fencedArea check, we need an ‘&&’ then call the determineEngineS-
tate. Pass this.vehicle as an argument. Check it equals ENGINE_ON,
which is an enum value that should already be in VehicleState…”
(typist writes this code)
1 public void detectGeofenceIncident(Point newPosition) throws GeofenceIn\

2 cident {
3 for (GeofencedArea fencedArea : allFences) {
4 if (fencedArea.contains(newPosition)
5 && ENGINE_ON.equals(determineEngineState(this
6 throw new GeofenceIncident("New position lies inside
7 fencedArea, newPosition);
8 }
9 }
10 }
(ensemble timer goes off, George steps up to navigate)

George - “ … “
Coach - “What do you need to do next?”
George - “Ah… this doesn’t compile.”
Coach - “Let’s fix that then”
George - “Create the method determineEngineState. Use the short-
cut.”
In this example, the original navigator has direction, but they have
not managed to communicate it to the rest of the group. When the
Trish steps up she can’t see how to proceed. The coach reminds the
ensemble to use Consume First design. This is a technique where you

start writing new code in the place where it is used, not in the place
where it is declared. Often that place is a test case, but not always.
By consuming or using a new class or method before you declare it,
you communicate better about what it is supposed to do. It’s easier for
subsequent navigators to pick up on a compiler error showing them
what new code is needed, than a syntactically correct but unused
method, class or variable. You first paint the big picture - we have
a new code element we want to use in this way - then it’s easier for
the ensemble to fill in the details afterwards - declare and implement
a new code element.
How long is it since we saw feedback?

Hanbing is navigating writing a new test case for the method ‘write-
File’ on the ‘Storage’ class.
Hanbing - “We’re testing the writeFile method and we’ll need to pass
an outputfile instance to it.” (typist writes this code)
1 TEST(Storage, writeFileNoCallback)
2 {
3 storage.writeFile(outputfile);
4 }
Hanbing - “then we’ll mock the cloud storage and check it gets a call
to putObject. We’ve already got a cloud mock, do the same as in that
other test. Put in some fake arguments for the moment - like path,
filename, data, length of data - say 4” (typist writes this code)
2 {
3 MockCloudStorage cloud;
4 EXPECT_CALL(cloud,
5 putObject("path", "filename", "data", 4)
6 ).Times(Exactly(1));
8 }
Hanbing - “We should construct the storage object - that’s the class
under test - shall we call it StorageImpl? Pass the cloud object to the
constructor.” (typist writes this code)
2 {
3 MockCloudStorage cloud;
4 StorageImpl storage(cloud);
5 EXPECT_CALL(cloud,
6 putObject("path", "filename", "data", 4)
7 ).Times(Exactly(1));
9 }
Hanbing - “And we’ll need to stub the outputfile”

Coach - “Wait, can you sort out some compiler errors first? Creating
that stub will take a little while and I’d rather get back to compiling
code first. We should create the StorageImpl class.”
Hanbing - “ah ok. Comment out the line that calls writeFile, let’s
create the StorageImpl class and its constructor.”
By feedback we mean the compiler output, or a test result. In this
example the coach encourages the navigator to take a smaller step
and get back to compiling code sooner. You want frequent feedback
since it helps the ensemble to share direction and understanding of
progress. A lot of the feedback is in the form of error messages and
failures. It’s useful to keep the amount of these under control - we
want to regularly see passing builds and tests. It helps the group see
we are making progress, and getting confirmation that we are where
we think we are.
How long is it since we made a

commit?
Mikael is navigating and has just completed a refactoring.
Mikael - “Great, the tests are passing”
Coach - “Good time for a commit, do you think?”
Mikael - “yes, let’s do that.”
Typist - (Initiates a commit) “What should the commit message be?”
Coach - “Perhaps look at the ensemble timer? I think we have a list
of goals there and we’ve just completed one”
Mikael - “yes, write the message the same as the completed goal.”
As a coach, you want to encourage small safe steps. Remind the
ensemble regularly to make a commit. If tasks are too large and
you commit too infrequently, it has negative effects, especially if
you share a codebase with other teams. By checking in frequently,
you reduce the risk of experiencing merge conflicts. Encourage other
teams to sync often too. If you do refactorings it’s particularly
important to merge them as soon as possible. No-one wants to be
landed with a huge merge conflict. Everyone wants to be the bird
and not the statue.
Some ensemble timers have a feature where they can keep a list of
goals. It can be a good way to make the direction visible to the whole
ensemble. It also helps track what we’ve done when it’s time to make
a commit.
Only one person knows what’s going

on
Peter is typing and Martin is navigating.
Martin - “It doesn’t compile. Does anyone know why?”
Peter - “We’ll need to change the makefile and add a new target”
Martin - “I’m not very familiar with makefiles”
Peter - “Put it with the other targets, here.” (He moves the cursor to
a line in the makefile)
Coach - “Wait a minute Peter, you need someone to navigate you.

Can anyone help Martin?”
Peter - “Actually I think I’m the only one in the team who knows
about makefiles.”
Coach - “ah, ok, so then you shouldn’t be typing. Let’s rotate roles”
If the team is totally reliant on one person for a particular task, don’t
let them type. The typist has their head full controlling the editor and
the test tools and stuff, and doesn’t have the capacity to also answer
questions about what is going on. There is a danger they will just code
without saying anything and then it’s harder for the rest of the team
to learn what is going on.
Nobody knows what is going on

The ensemble is discussing the next task to work on.
Lars - “The ticket says we need to make a change in the new cloud
storage service. Does anyone know where in that code we should do
that?”
Everyone - (silence and general shrugs)
Coach - “Has anyone worked on this code before?”
Everyone - (silence and general shrugs)
Coach - “Who would know about it? Can we invite them to join us
for a bit and explain?”
Elisabeth - “Patrik would know, he’s in the cloud architecture COP.
He’s very busy though”
Coach - “Let’s give him a call and let him know the situation.”
If the whole ensemble is stalled like this then it’s clear there is a
gap in the team’s knowledge. Someone outside the team who has
the knowledge could join the ensemble for half an hour and explain
and/or start to navigate the change. If that person knows a whole
team is waiting for them they might be more motivated to drop what
they’re doing and join you straight away.
If this kind of thing happens a lot, then you should definitely take
it up with the team’s manager or product owner. Perhaps the team
needs that person to join them more permanently.
Chapter Summary
An ensemble with direction works effectively towards a goal. In many
of these stories the coach helps the group to find direction. Sometimes
the ensemble has direction but the coach would like them to take
a different one. At all times the coach is modelling the behaviour
they want to see. They stay quiet when navigators are setting a
good direction and the ensemble is making progress towards a goal.
Otherwise they intervene with suggestions and leading questions.
Retrospectives
Each ensemble session should conclude with a short retrospective,
about 15 minutes of a two hour session. This is a chance to reflect
on what’s happened, process events, and encourage people to draw
lessons from what’s happened. Each ensemble session should be an
improvement on the previous one. You want to see increasing collab-
oration, new skills being used, people feeling happier. That doesn’t
happen all by itself, people need to decide to behave differently. Don’t
just plunge straight back into your other work, without reflecting on
how to improve.
When I am coaching I have with me a box containing a load of marker
pens and different coloured sticky notes. It’s useful since although all
companies have these things they can be hard to locate, and you’ll
be having a short retrospective several times a day. If you’re remote
you could have a template prepared in an online document or virtual
whiteboard.
When retrospectives are frequent and short, then the outcomes and
learnings are small. Problems can be acted on promptly and many
small learnings add up to a lot. If you hold longer retrospectives less
frequently, you get observations of bigger problems and the danger is
they get ignored.
There are many ways to do retrospectives, it helps to mix it up and
keep it fresh by using different techniques on different days. Here are
a few ideas.
Ask for Observations

Hand round the sticky notes and pens. Ask everyone to write obser-
vations, one per note. Give the group 5 -10 minutes. Perhaps count to
20 in your head after the last person stops writing before you call a
halt. You gather all the notes and stand by a whiteboard or wall. You
read each note in turn and stick it on the board.
Retrospectives 37
• Use the whole space of the whiteboard

• Group similar notes close to each other
• If you don’t understand a note, ask for clarification
• If a note opens a larger discussion, put it to one side. Either
return to it at the end or promise to take it up at a future session.
If you read a sticky and agree, do say so or compliment the author if

it’s a good observation. Be careful of disagreeing with what people
have written. You don’t want to discourage people from making
observations in future.
At the end you can circle and label any groupings that emerged.
“Liked, Learned, Lacked”

Observations
Making observations about the work, thinking at that ‘meta’ level,
is not a skill people are generally used to using. I have a learning
hour where we practice these skills (see part 3). Sometimes I prompt
people to think about particular aspects by writing these words on
the whiteboard:
• Liked
• Learned
• Lacked
When everyone has had a few minutes to write their notes, I ask them
in turn to go to the whiteboard and read their notes, sticking them on
the board as they talk. I encourage people to say if they have written
essentially the same thing, and we group together similar notes on
the board. We may have a short discussion about it, particularly
if the note is vague or novel. If notes are really vague (“liked the
discussions”) then try to get people to say more precisely (“discussion
about long methods”). If someone has not written any notes, let them
go last, and see if they can think of any observations to share now.
While the team members are writing observation notes, I will also
write a couple of notes that I will stick on the board. I prefer to
bring up positive things that have happened that I liked and want
to encourage.
Retrospectives 38
Turn up the good

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.
Your private retrospective

It can help to make a few notes in your private team diary notebook.
This notebook is to help you:
• Pick up where we left off when you meet this team again
• Remember what we did for the ‘Boss email’
• Record progress over many weeks of coaching
• Keep track of class and method names where we need to do
work
I usually only write a few bullet points, just enough to jog my memory.
Something like ‘xxx class - duplication’ or ‘encourage nnn to speak
up’. I might write about a design decision we made, or a test we should
write next time.
These notes form part of my personal retrospective. They are not for
sharing with the team, they are for my benefit. They help me to do
a better job the following day when I meet the team again. After a
few weeks I can look back and feel encouraged about how far we’ve
come.
Retrospective skills are essential

As you begin with these retrospectives, you might not get many
observations. It takes time to build the habit of noticing what is going
on. It’s a great skill for a team to have, to observe how the work is
Retrospectives 39
proceeding and note how to improve it. If they get really good they
might start to do it during the session. Pulling out a sticky and making
some notes when something interesting happens.
Don’t drop the habit of retrospectives, even when the work seems to
be going really well. There is always something that could be better.
If you stop holding retrospectives then gradually the team will forget
to make observations any more.
Remote Ensembles
It’s perfectly possible to work as an ensemble where coach and team
members are all remote. With the covid-19 outbreak, I had to learn to
do this in rather a hurry. The technology to support remote ensembles
is pretty good these days.
A few things that are especially helpful in a remote setting:
• everyone can see everyone’s faces as well as the code

• be even more considerate with your comments
• take breaks
• make it really quick to change typist, or do it less often
• typist should not experience lag from key-presses and mouse
movements
• you will need additional tools for whiteboard sketches and
retrospectives.
I’m sure there is more than one way to set things up that achieves all
these goals. The rest of this chapter shares some ideas.
Seeing people’s faces

This helps with kindness, consideration and respect. People’s face
expressions convey a lot of meaning. It also makes it easy to see if
someone has gone out temporarily to fetch a coffee. If you have the
bandwidth, it can help to have the audio and video on a separate
device than the coding and screenshare. Put a tablet next to your
laptop with a ‘gallery’ view of all the ensemble participants, and
connect your headset to it. Use your main computer to screenshare
and edit code.
Remote Ensembles 41
Be considerate and time your

comments
When everyone is remote it seems to happen more often that people
talk on top of each other and neither are heard. It’s probably some-
thing to do with missing body language cues and a slight lag on the
audio. Firstly, it helps to be really clear about who is navigating at
any one time. If you are not the navigator, you have to be even more
careful about timing your comments.
If you want to speak, consider “raising a hand” in the videoconference
software, or holding up a brightly coloured sticky note in your video
feed. Be considerate and make space for others to speak.
With an in-person ensemble, it’s not a problem to have small side
discussion where a couple of people discuss something quietly while
the typist and navigator get on with something else. That is not going
to work in a whole-group call. Some teleconference software allows
‘breakout’ rooms for this kind of purpose. It might be a bit heavy-
weight for what you need though, and people might wonder where
you disappeared to. If it’s less of a discussion and more of a comment,
just write it in the meeting chat. Otherwise it’s probably best to just
make the ‘side’ conversation a whole-ensemble conversation instead.
Take breaks
Staring at a screen is tiring. It seems to be more tiring than being all
together in the same room. Be kind to one another and take breaks
before you think you need them. At least every hour, take five minutes
to get a coffee or similar. I tend to instigate a common break half way
through each session, where everyone leaves their desk at once.
Make it quick to change typist

Use a ‘ensemble branch’, that is only used for this purpose. The driver
edits code on this branch of their local clone. When switching, the
Remote Ensembles 42
current typist makes a Work-In-Progress (WIP) commit, and pushes.

The incoming driver does a pull and build. Carry on coding. When
you are ready for a ‘real’ commit and push to the main branch,
optionally squash the previous WIP commits into one commit, and
add a better commit message. There are various tools to support this
style so it’s one command or mouse click to do the necessary git
command at each point in the process.
It can happen that changing typist like this becomes slow. For example
if your git server is overloaded, or your compile is very slow. If it is
not quick to change typist, then do it less often. Don’t decrease the
rate of changing navigator though. If necessary, one typist could even
take the whole 2 hour session, with everyone else cycling through the
navigator role.
The absolute quickest way I’ve found to change typist, is to paste the
updated code into the group chat, so the new typist can just copy it
into their editor. It kind of works if you’ve only made small changes
in one place. I don’t think this is a good long-term strategy though!
Version control is important.
Typist lag is deadly

Things get really confusing if the typist has to wait seconds between
keypress and seeing the cursor move. They get distracted and uncom-
municative. The navigator gets confused and repeats instructions un-
necessarily. Other ensemble members lose track entirely. It’s actually
easier to cope if the typist experiences no lag, but everyone else has
a few seconds delay. It’s still not ideal, of course.
You probably want the typist to be editing code on their own local
machine, or on a machine they have a very good connection to.
Design discussions
When working in an ensemble, you don’t spend all your time en-
tering code into the editor. It’s very important to build a common
understanding of what code you’re trying to write and what the test
Remote Ensembles 43
scenarios are. A whiteboard sketch can be really useful, and you’ll

want to have a ‘remote’ version available.
If the ‘sketch’ isn’t all that visual, an ordinary cloud-based document
might suffice. If you do want a picture, an ordinary drawing program
like ‘paint’ could work. One person is the ‘typist’ of the sketch, sharing
their screen. Other people can navigate and direct them to edit the
image.
You might prefer a collaborative whiteboard tool which everyone can
edit at once. In my experience these take a lot of bandwidth and suffer
from lag. Try it and see.
Retrospectives
The simplest thing I’ve found is for everyone to write their obser-
vations into the group chat. Another simple solution is people write
notes in a local document and taking turns to share their screen. A
shared cloud-based document works in a similar way.
Collaborative retrospective tools with virtual sticky notes or mindmaps
could also work. They might be more intuitively similar to what
you’re used to in the physical world. Beware of them taking a lot
of bandwidth and having lag. Try some and see what works for you.
Part 2: Learning
Hours
The second major part of Samman technical coaching is the learning
hour. These are short training sessions where people practice coding
skills and learn new techniques. When working with a team ensemble
you’re primarily a mentor and facilitator. In the learning hour you’re
more often acting as teacher and coach.
If you’re reading this book, chances are you have already been
doing some teaching. You probably already have some materials and
exercises that you’ve done with groups. You may have led workshops
at conferences, or given talks at meetups. Start there. Start with what
you have.
Now would be a good time to put this book down and make a quick
inventory of your existing teaching materials. Think through all the
situations where you’ve made a slide deck about technical practices,
or gone through a code kata with a pair or a group. If you’ve attended
a workshop or training session as a participant, perhaps you worked
on one of the exercises some more afterwards, and shared it with your
team.
It’s hard to take over someone else’s lesson plans and exercises. You’re
going to need a personal portfolio to use when you’re coaching. I’m
very happy to share the materials I use - and some of them are in
this section - 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.
45
First we should talk about why learning hours are such an important
part of your work.
Explaining Why you
should hold a Learning
Hour
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. If you meet
resistance to the idea of spending as much as an hour on learning
each day, this chapter will help you with some arguments and ideas
to help you persuade people.
Learning TDD is like learning to ski⁹

I’m standing at the top of a gentle slope, smooth snow stretched out
before me. Fully kitted out in tight boots, carving skis and helmet, I
take a deep breath. This time I’m going to try parallel turns, I think
to myself. It’s my first day on alpine skis, and I have just successfully
completed several runs of this slope using snowplow. It’s going well.
I feel ready for the next thing. So I adjust my balance, put my skis
parallel in front of me and remember the advice - lean into the turn,
push with your inside foot… aaaaaaargh! too fast! Crash. Ok, let’s try
that again. Slowly slowly… speeding up… aaaaargh! Crash. Picking
myself up again, I try a turn in the other direction. Parallel skis, get
a little speed, push with the other foot… lean a little… Crash. Ouch!
Banged my elbow this time. So let’s try that again…
⁹I realize this is a cultural reference that may not resonate with you! Please bear with me, I
live in Sweden where skiing is a widespread and popular passtime. I believe there are many other
skilled activities which would fit the same narrative, perhaps you can come up with one from your
own experience?
Explaining Why you should hold a Learning Hour 47
It took me about 20 minutes to get down that slope, and I was in severe
need of a hot chocolate and a hug by the end! That gentle slope which I
could get down fairly effortlessly with a snowplow, suddenly became
a nearly impossible challenge. I was still skiing, I was still using the
same equipment on the same slope. The difference was the technique
I was trying to use to get down it.
I don’t know if you’ve ever tried skiing. If you did, chances are that
like me, you started with the ‘snowplow’ technique. You put your
skis in a V shape in front of you, weight firmly in the center, bend
your knees and gently slide down the slope. If you find yourself
accelerating too much, you widen the V, and it slows you down.
Widen the V more on one side than the other to turn. Well actually
it’s not quite as easy as it sounds. Most beginners get the hang of this
only after several lessons. I had an advantage - previous experience.
I was already fairly proficient at cross-country skiing, a related
technique. You mainly ski on the flat, as the name implies, and the
equipment is different. The skis are much longer, and your heels are
not attached, only your toes. It’s quite similar to hiking, following
trails up and down around the mountains. When you go downhill,
the slope on the trail is always gentle, and the technique you use is
not that different from the snowplow you do on alpine skis.
The trouble with snowplow, is that it works really well on gentle
slopes at slow speeds, but if you really want to have fun skiing fast in
the high mountains, you need a different technique. When you think
about it, the key to going really fast is better brakes! With parallel
turns, you slide with the skis parallel to one another instead of in a V.
You get your full weight onto both ski edges when you point them in
the same direction. It gives a much more powerful and controlled
braking effect, and it’s a completely different way of turning and
balancing.
Successfully learning parallel turns
The trouble is, on the beginner slopes that you use to learn parallel
turns, snowplow works perfectly well. It’s really tempting to just go
back to it, especially when you start getting tired or cold or frustrated.
Unsuccessfully learning parallel turns
TDD is like parallel turns
The beginner skislope is like a simple coding exercise - a code kata

like FizzBuzz or LeapYears. You already know how to code, you
could solve this problem easily using the coding techniques you
already know. The trouble is, I’ve asked you to do it differently, as
if with parallel turns. I invite you to write a test first and build up
your solution incrementally with Test-Driven Development (TDD).
Suddenly that straightforward bit of coding takes ten times longer.
You have to shift mental balance to think about how to test the code
before you can implement it. It’s disconcerting, uncomfortable.
If that first experience of TDD goes badly, you might be tempted to
just give up. Go back to the familiar way you coded before. Write the
tests afterwards. Snowplow. I think it especially likely to happen if
you’re a bit stressed or tired or worried about what other people will
think of you.
Hubris
When I tried parallel turns for the first time, I was overconfident. I
wanted to try downhill skiing properly, feel the wind in my hair and
go whizzing down steep slopes. I had seen people doing parallel turns
and someone had explained the basic mechanics to me. I thought I
would be able to pick up the new technique easily. I didn’t take the
trouble to get an instructor to help me. I didn’t find a supportive group
of friends to learn together with. It didn’t go well!
Maybe I’m a little hard on myself. I did at least pick a smooth,
gentle, short skislope to begin with. Many people trying TDD will
start directly in their production code. That’s a bit like attempting
parallel turns on a steep slope with loose snow and moving obstacles
in the form of other wobbly beginners skiing around you. What could
possibly go wrong?!
Learn together with an instructor
In the learning hour, it should be like have a fun safe skiing lesson
together with friends. I’ll ask you to step outside of your comfort zone.
We might fall over or joke about a bit. Together we’ll learn some
techniques that will be useful when we get back to the production
code. Soon you and your whole team will be whizzing down the
mountain with the wind in your hair!
Why should you spend a whole hour

every day on learning?
If you learn skills and become better at your job, you will become
more productive and happier. Everyone benefits! Small increases in
productivity will quickly add up to more than compensate the time
you spent on the learning sessions.
Through training and coaching, I’ve seen developers change their
attitude towards writing unit tests, from it being a boring chore, to
something they see as helping them to write better code. I’ve seen
developers surprised by how easy it can be to refactor safely, once
they had some guidance and got the right tools. I’ve seen developers
leave a learning hour, keen to try out what they have learnt to
improve their production code.
As a software developer, learning is part of your job. There are always
new tools and frameworks appearing that you should know about.
There are always better designs and ways of working being invented.
To remain competitive in a fast-moving world, where you are being
paid for knowledge-intensive, skilled work, you must keep learning
to stay relevant and useful.
The idea of doing an hour of learning daily is to make it normal. Learn-
ing is a useful and important part of your job, not something you try
to cram into lunchtimes or a conference once a year. Organizations
who give you work time for learning are the ones you want to stay
with, and give you the colleagues you enjoy working with the most.
Another benefit of doing learning hours daily, is it makes it less likely
people will miss all the training by being ill or tired one day. It gives
plenty of time between sessions for you to try out what you have
learnt, and come to the next one with questions.
Everything I’ve said here are all the same principles that led me to
recommend the ‘Coding Dojo’ format for many years. The learning
hour is basically a rather short, frequent dojo. Just as with learning
a sport or a musical instrument, usually frequent shorter sessions are
more effective.
Who should come to the Learning

Hour?
In the first place, invite the teams who you are coaching. You might
have a separate learning hour for each team that you have ensemble
sessions with. That way you can tailor the material to their situation
and choose topics that you know are relevant.
In some organizations I’ve found the teams were working with similar
technologies and struggling with similar issues, so I’ve had a joint
learning hour for two or sometimes three teams together.
It’s always good to throw open the invitation to learning hours more
widely than only the teams you are coaching. People in other job roles
like Product Owner or Scrum Master might be interested to come
along. Particularly if the session won’t involve much coding - perhaps
you’re going to play an agile game or simulation - do invite additional
people.
I also find it useful to invite aspiring Samman coaches or interested
developers from other parts of the client organization or even other
organizations. People start to understand what the coaching is about
when they see it happening. In the learning hour we generally only
work on exercises so there is less problem with NDAs and security
when it comes to bringing in external people.
The Theory and Practice
of Teaching and Learning
I have been a learner all my life, but I have no formal training as
a teacher. Some of the teachers who I’ve learnt most from have
been similarly untrained themselves, so clearly it’s not a prerequisite.
Having said that, it helps to know a little bit about pedagogy (theory
and practice of learning) before you set out to teach people.
Learning Outcomes and Objectives

What really matters about your training is actually what happens
afterwards. When people return to their desk, will they be able to
apply what they’ve learnt in a useful way? Start with the end in mind.
What is the outcome you’re hoping to achieve?
Where you will get to will depend on where you start, so part of
your planning will involve finding out what people already know.
Earlier in the book I talked about the initial meetings you have with
the team before the coaching begins. You’ll have reviewed some of
their existing code and tests. You may have worked with other teams
in the same organization. Perhaps you have worked with similar
organizations and teams before.
When you start planning your learning hours, hopefully you will have
a fair idea of who will come to them. You’ll have some idea what their
production code and tests look like at present. You’ll have discussed
with them what they are interested in learning about and what they
are currently struggling with.
Bloom’s taxonomy
Back in the 1950s, educators led by Benjamin Bloom came up with
a taxonomy to describe learning objectives. Since then this model
The Theory and Practice of Teaching and Learning 54
has been used extensively within education, since it helps teachers

to design both courses and assessments. The model has been revised
a little over the years but it has actually stood the test of time pretty
well. The basic idea is that you can describe thinking skills in terms
of six broad categories:
• Remembering
• Understanding
• Applying
• Analyzing
• Evaluating
• Creating
There is an implied hierarchy and order of categories. For example

‘Remembering’ is easier to achieve and probably comes earlier in a
student’s journey than ‘Analyzing’ or ‘Creating’. As you teach you
hope people will gain thinking skills around the topic you’re working
on. Knowing what order they will likely do that in can help you
prepare appropriate materials.
Example learning hour planned outcomes

To illustrate how you could use this to design learning outcomes, let’s
look at an example. I might want to teach something about Approval
testing to a team that’s totally new to it. I have an idea for an exercise
that they’ve done before with normal TDD, that I could demo with
Approval testing. I expect we’ll talk about what’s different when we
do it with the new technique. Then I’d probably set them loose to try
the exercise for themselves. That sounds like a plan. It might help me
to improve my plan to work out what they might learn from this. I
could state the learning objectives like this:
• Describe some characteristics of Approval Testing.

• Compare Approval Testing with assertion-based testing.
• Use the Approvals framework to write test cases when a Printer
already exists.
The verbs I’ve used to begin those sentences with are very deliberately
chosen. Each Bloom category comes with a list of verbs. In this
example these verbs map to categories like this:
• Describe ⇒ Remembering
• Compare ⇒ Understanding
• Use ⇒ Applying
In other words, after this learning hour I expect participants to have

new thinking skills in the first three Bloom categories. If we did more
learning hours on this topic, I’d plan later ones to include learning
objectives tied to some of the higher level Bloom categories. They’d
soon learn enough to start Analyzing and Evaluating approval testing
techniques.
How to use Bloom categories

The Bloom categories help you to plan exercises and teaching materi-
als at an appropriate level. You want to build up people’s confidence
and knowledge from a good foundation. Start with materials to build
Remembering, Understanding and Applying. When those thinking
skills are in place, you can do more Analyzing, Evaluating and
Creating.
The second important use of Bloom categories, is to help you to plan
and describe learning outcomes. If you do a web search on Bloom
taxonomy you should quickly be able to find long lists of good verbs
to describe thinking skills in each category. These words are useful
as a prompt or start of a sentence. If you write good descriptions of
what you expect a student to be able to do after your learning hour,
it can help you to choose appropriate materials and keep on topic.
The ‘4C’ learning model

I’ve taken a great deal of inspiration from Sharon Bowman’s ‘4C’
learning model. I recommend her book ‘Training from the Back of
the Room’.
The philosophy is very much that each person who comes to your
learning hour has a unique background, and what they are going
to learn needs to be integrated with what they already know for
it to stick. People are not some kind of empty vessel that you pour
knowledge into via talking at them in front of a deck of slides. People
are active participants, with their own goals and motivations to learn
things. As a teacher you can help them to see what’s possible, and to
support them as they decide to learn things.
To be more concrete and specific, when you plan a learning hour, you
include activities for each of the 4C’s:
• Connect: Get people in the right head-space for learning about

the topic together.
• Concept: Introduce the new skills or ideas or information you
want the participants to learn.
• Concrete: Hands-on exercises to practice skills or figure out
how things work.
• Conclusions: An opportunity for people to consolidate and
internalize what they’ve learnt.
You’re encouraging people to spend one hour going on a learning

journey. Each of these parts are stops along the way. You want to
help people to be present mentally, fuel their curiosity, let them work
out what they need to do, and to come to their own understanding of
the topic. You vary the specific activities in each part to hold people’s
attention and keep them moving. You don’t have to keep the 4 ‘C’s in
the same order, or spend the same amount of time on each one.
In the sample learning hours in the next chapter of this book, you
should be able to see a clear 4C structure and examples of activities
for each.
Design learning experiences that fit

with how the brain works
When teaching, it helps to understand how the human brain works.
Cognitive neuroscience is the study of how the brain takes in, stores,
retrieves and uses information. It’s a relatively new and growing

field, and there are some things scientists have found out that are
particularly relevant. For example, did you know:
• What you pay attention to is strongly affected by subconscious

processes. (ie out of your conscious control)
• What you learn is filtered through emotions. Stronger emotions
are more likely to cause long-term memories to form. Content
that evokes no emotion is less likely to be remembered.
• Physical movement improves brain performance - the brain is
part of the body, so increased oxygen in the blood helps it
function better.
A ‘trump’ is a kind of card that beats the others. Sharon Bowman has
come up with six ‘trumps’ to help you remember useful rules about
how the brain works. The aim is to help you to plan more interesting
and effective training. In the following sections I’ll summarize some
of her book “Using Brain Science to Make Training Stick” and relate
it to planning learning hours.
Movement trumps Sitting
At a most basic level, you learn more when you’re feeling awake!
If you move around, it increases oxygen flow to the brain, stops
you falling asleep, and increases brain performance. The trick is
incorporate movement into the content of the training so that it
doesn’t take much time. Ideally, you want people to move out of a
sitting position at least every 10-15 minutes.
When we’re working in an ensemble, you can arrange the chairs so

people physically stand up and move a chair to the right every time
you change typist. When you gather observations in a retrospective,
people can each walk up to the whiteboard and stick their notes onto
it. When reviewing code, you can stick printouts to the walls and have
people move around to look at them.
If you’re working together remotely, this is much more challenging.
At least get people to take breaks and leave their desks from time to
time.
Talking trumps Listening
We are a social species and talking with others builds relationships

and creates a safe atmosphere for learning. When you talk about what
you just heard it reinforces your memory of it. Talking also gives
opportunities for feedback from others about how well you seem to
understand the topic.
Pair programming gives lots of opportunities to talk, Ensemble work-
ing too. You can also ask people to pair up to discuss a topic or share
experiences.
Images trump Words
Images (especially moving images) easily capture your attention.

Telling stories that bring pictures into your mind has a similar effect.
If the picture and associated story evokes an emotion that makes
it even easier to pay attention to it and recall it later. Long-term
memories often comprise of images and associated emotions. Words
spoken devoid of emotion tend not to form such memories.
Demonstrating a coding technique is more effective than just review-
ing the finished code. Telling stories - perhaps about a time you
used a particular refactoring or design pattern - is better than only
explaining the theory.
Writing trumps Reading
When you are writing you can’t think about anything else, it forces
you to concentrate. When you read, it’s easier for your mind to
wander. Writing also makes the information multi-sensory - you
physically move a pen on some paper as well as see the text on the
page. You can draw lines and boxes to situate the information in space
and relate it to other information. All those things make the content
easier to remember, but only if the learner does the writing. Watching
someone else write or draw lines and boxes is not as good.
Provide handouts, notes and quizzes that people can annotate. Ask
people to write conclusions and observations on sticky notes.
Shorter trumps Longer
Student’s minds tend to drift after about 10 minutes of a traditional

lecture. To keep people’s attention, divide your presentations into 10-
20 minute chunks and in between spend at least 1-2 minutes on some
other activity. Perhaps ask people to review or discuss the material
presented so far.
A learning hour is a bit too long to concentrate on only one activity,
be sure to break it up with discussions or different exercises. When
showing a long prepared kata, break off occasionally for Q&A, or to
ask people to note down what they observed so far.
Different trumps Same
Anything new or unexpected will catch people’s attention. Emotions

generally and surprise in particular help learning to stick.
Vary the format of your learning hours so that they are not too
predictable. Games and simulations and exercises can contain built-
in surprises. You can prepare code for an exercise that doesn’t behave
the way people expect. You can also create surprises on the fly. For
example, everyone could be working in pairs doing TDD when you
suddenly announce that everyone should get to green within the next
minute then swap code with another pair, (easy to do with cyber-
dojo). Another idea is to suddenly change the requirements mid-
exercise. Keep it fun.
Deliberate Practice
The Bloom category ‘Applying’ is about being able to use a technique
competently. In order to apply a skill like Test-Driven Development,
there are several other skills you need to be able to apply and switch
between. In the Red-Green-Refactor cycle for example you need to:
• identify the next test case that will incrementally improve your
solution
• design the specifics of that test case and see it fail
• implement a solution design which is testable
• Refactor to improve your design
If you are weak in any one of those component skills, you will
struggle to do TDD. The great advantage of practice exercises is we
can find ones that let us work on those component skills individually.
Actually, you can break them down even further. For example within
‘Refactoring’ we have the skills ‘keyboard shortcuts’ and ‘identifying
duplication’. It’s not uncommon to find programmers who need
to practice these skills alone before attempting to refactor more
generally.
This process of focusing on practicing one small skill at a time
before composing them into a cohesive activity, is part of ‘deliberate
practice’. It’s a technique that helps people to improve their skills
more effectively. It’s different from the kind of practice that happens
when you just repeat something you can basically already do. De-
liberate practice will stretch you just the right amount to make you
uncomfortable and expose the need to improve.
For example, musicians often practice playing scales: sequences of
notes going up and down. They practice them first slowly then faster
and faster, maintaining accurate notes and even rhythm. Scales are
not very interesting to listen to, and most pieces of music you actually
want to play are a lot more varied than that. The thing is, those same
tunes will often contain a few short passages that are just scales. These
can be some of the hardest parts to play well. If you deliberately
practice scales, then it will enable you to play a variety of tunes better.
You isolate the hard part and practice it separately.
In the same way, you can practice a skill like refactoring by itself.
In real coding work, this may only be a small part of what you do,
but it can be a difficult part. By doing refactoring katas, applying
specific refactorings and learning how they change your design, you
can start to improve your coding as a whole. Deliberately practice
this one aspect by itself.
As a teacher, I want to plan a series of learning hours that will
be at just the right level so people don’t get bored, and don’t get
overwhelmed or frustrated. I want to build up skills and work towards
composing them into bigger skills like Test-Driven Development. I
tend to work with several themes that I swap between each learning
hour. Each time we return to a theme we’ve covered before, I’ll
increase the challenge-level of the exercise, or focus in on a particular
component skill, based on how well the group coped the previous
time.
In the next chapter we’ll look at some specific learning hour plans
illustrating all these pedagogical techniques.
Sample Learning Hours
This is a sample plan of what I might do for the themes, plans and
goals for ten learning hours with an organization I was new to. Once
I met the teams I would probably adjust the plan and substitute some
of these for other ones. I include it here as a reasonable starting point.
Each learning hour plan starts on a separate page in case you want to
print them out and use them as notes during the session.
Sample Learning Hours 65
1. Incremental working, Driven by

Tests
Since it’s the first session, I’d also like people to get comfortable
with one another and feel safe to work in pairs. The ‘connect’ step
is particularly important.
When I demonstrate ‘LeapYears’ I usually only do the four test cases
listed in the problem description. That means I don’t ‘fake it’, I go
straight to using the modulo operator when implementing the first
test case. That keeps the demo shorter, and means you don’t need to
explain triangulation as a concept.
Learning goals:
This learning hour is in the “Small steps” theme.
• Describe the Red-Green-Refactor cycle

• Explain why you write the tests first and not all at once
• Design a pure function that takes an integer and returns a
boolean using TDD
Session outline:
• 10 min Connect: divide into pairs, 3 benefits of TDD
• 15 min Concept: Demo leap years
• 20 min Concrete: Do Leap years in pairs
• 10 min Conclusions: Summary of main idea
Connect
Ask people to form pairs and introduce themselves if they don’t know
each other. Ask them to discuss the question ‘What are some of the
main benefits of doing Test-Driven Development?’. After 3 minutes,
ask each pair to report one thing they came up with to the group.
Concept
With your code visible to all, demonstrate completing the Leap Years
Kata¹⁰. I like to use cyber-dojo¹¹ because it makes the red-green
iterations visible.
Starting at a whiteboard, explain the purpose of the kata. Read the
description to the group, and/or display it on a slide. Write up all 4
examples given in the kata description on a whiteboard. Note that
these will turn into tests.
Then complete the exercise as a demo. Make it clear you interleave
designing tests and writing code.
Concrete
Ask people to work in pairs or an ensemble to do the same thing.

If they’re using cyber-dojo for the first time they might need some
help to get started. In any case they should start from the problem
description and an empty editor, and complete the LeapYear function
using TDD. Every 3-4 minutes, remind them to swap the person
who has the keyboard. Coach them to write the tests before the
implementation, working incrementally and iteratively.
Conclusions
• Think about what we did today. If you had to explain the main
idea of TDD to someone else, what would you say?
• Write your explanation in a sentence or two on a post-it
Put up a flipchart with the question “What is the main idea of TDD?”
and make it look attractive with a lightbulb doodle or something. Ask
people to stick their post-it notes on it. If time is short, they can do
that on their way out. Otherwise, read some notes out to the group
before you part. Hang the poster somewhere prominent afterwards,
perhaps in the team area or coffee room.
If working remotely, they can each write their sentence or two in a
shared online document.
¹⁰https://sammancoaching.org/kata_descriptions/leap_years.html
¹¹https://cyber-dojo.org/
2. Selecting and ordering test cases

This time the problem description doesn’t include all the test cases
we need and we have to come up with a test list.
The first time you do FizzBuzz, I suggest focusing on the core business
logic for converting one number at a time, and leave out the part
where you print the full 100 lines to the console. That part is a little
harder to test-drive.
Learning goals
The theme is repeated from the first session: “Small steps”.
• Explain why you make a ‘test case todo-list’

• Use a ‘test case todo list’ during TDD
• Describe ‘triangulation’
Session Outline
• 5 min connect: fast pass ‘Order of TDD steps’
• 10 min explain & elaborate test list for FizzBuzz
• 10 min demo FizzBuzz with triangulation
• 2 min reflect: summarize triangulation in own words
• 30 min FizzBuzz in pairs
• 5 min reflect: pairs discuss what they learnt today
Connect
Print out the list of steps below and hand a copy to each participant.
Ask them to spend one minute writing what order to do them in.
(This is a ‘Fast pass’ ‘Take a Guess’ activity)
• Refactor duplication
• Write a new test case that fails
• Review the requirements and note down a ‘todo list’ of test cases
• Make a failing test pass

• Commit to version control
• Cross off a test case from your list
• Run all the tests to make sure they still pass
When the minute is up, ask them to compare their answers with
their neighbour. After 1 more minute ask if anyone has questions
or inconsistencies between their answers. Answer their questions
yourself or if time allows, ask if anyone else in the group can answer
first before filling in any details they missed.
Elaborate test case todo-list
Starting at a whiteboard, explain the purpose of the FizzBuzz kata¹².

Read the description to the group, or put it on a screen they can see.
Ask the group to suggest test cases we will need for this kata. Write
up whatever they say.
What they come up with might include this - an impure function that
prints a multi-line string:
1 () -> print("1\n2\nFizz\n4\nBuzz\n...")
Explain that they could usefully write a pure function that takes an
integer and returns a string. This function could be called by the other
one, and will be easier to test, while still giving us good coverage of
the business rules.
You might then end up with test cases on the whiteboard looking
something like this:
1 1 -> "1"
2 3 -> "Fizz"
3 5 -> "Buzz"
4 6 -> "Fizz"
5 15 -> "FizzBuzz"
¹²https://sammancoaching.org/kata_descriptions/fizzbuzz.html
When you have half a dozen or so of those kinds of cases, ask them
to prioritize/sort them. Which is the easiest to implement? Which
order should we take them in? Hopefully they will notice you should
take a number that is not divisible by 3 or 5 to begin with. Write
numbers next to the examples (in a different colour pen) which order
to implement them as test cases.
Demonstrate how to TDD the first few test cases. Add extra cases
for triangulation purposes - eg if they only wrote up ‘1 - > “1”’ you
may end up doing ‘2 -> “2”’ as well. Explain the extra examples are
useful to force you to generalize the code. Add the new test cases to
the whiteboard.
When it comes to the test for the impure function that prints to the
console, I suggest you point out this is harder to test with a unit test
and we will leave automating that test for another day. For today it’s
enough to check the pure function.
I often use cyber-dojo for the demo, to make the TDD cycles more
visible.
Reflect
What is triangulation? Describe it in your own words in your note-

book, or make a sketch.
Concrete
Have the group work in pairs or an ensemble to do the Kata again,

starting from no code, just the examples written on the whiteboard.
Every 4 minutes, remind them to swap the driver. They should do it
the same way you demonstrated, test by test in small steps.
If some people are really on the ball and complete the FizzBuzz
exercise before the time runs out, give them some additional rules
(write them on the whiteboard).
• Multiples of 7 are “Whizz”

• Multiples of 11 are “Bang”
If they ask you for more details, explain:

• Multiples of 3 & 7 are “FizzWhizz”

• Multiples of 5 & 11 are “BuzzBang”
• Multiples of 3 & 11 are “FizzBang”
• … etc …
• Multiples of all of 3,5,7,11 are “FizzBuzzWhizzBang”
Ask them to refactor first to make adding the new rules straightfor-
ward.
Conclusions
• In pairs, discuss how TDD felt, what was difficult and what was
easier.
• Tell the other person the most useful thing you learnt so far.
3. Golden Rule of TDD

When people start with TDD I often see them struggle to remember
to write the test code first. They may have that intention, but then
forget all to easily. This session helps them practice this skill.
Learning Goals
This time we’re making a start on the “Testable Agile Design” theme.
• Remember the Golden Rule of TDD

• Use the capabilities of the IDE to create a new class from the
test (if you’re using an IDE)
• Understand TDD helps you avoid designing more than you need
Session Outline
• 5 min connect: What’s important to remember in TDD
• 10 min concept: Golden Rule
• 35 min do: shopping basket
• 5 min reflect
Connect
Ask the group to shout out five things that are important to remember
when doing TDD. Write up each thing they come up with on a
whiteboard or shared document everyone can see.
The kinds of answers you might get:
• take small steps, testing one thing at a time

• run tests often
• refactor test code as well as production code
• only refactor when tests are passing
• make a test list
• write the test first
If they get stuck, perhaps drop hints.

Hopefully someone will mention the idea of driving the design from
the test, or only writing as much production code as you need to pass
the test. If so, build on that when explaining the golden rule in the
next part. Connect it to what they know already.
Concept: Golden Rule
In TDD the tests drive the design of the production code. You can
express that as a golden rule:
Do not write any production code until you have a failing test
that requires it
This means you should declare new classes, methods etc, in test code.
Then use your tools to bring those things into existence.
Write the golden rule on a flipchart and make it look pretty.
Do: Driving development with tests
Have people work in pairs to complete the Shopping Basket Kata¹³.

Remind them to practice writing the tests first before creating the
classes and functions they describe. Help people to make a test todo-
list if they forget. If they get as far as creating that list, writing the
first test and creating the class or function it uses with the IDE, then
they’re doing fine. They might well not complete the whole Kata. (Ask
them to do that as homework!)
Reflect: Is this useful?
What do you think about this rule? Will you try to use it?
• Discuss in pairs or small groups

• Note a reminder of the rule on a post-it to take with you
Homework: Do the kata again, remembering the golden rule.
¹³https://sammancoaching.org/kata_descriptions/shopping_basket.html
4. Names of Refactorings, especially

‘Extract Function’
It’s useful to have a vocabulary for talking about refactoring. It will
help you to communicate when doing strong-style navigation in a
pair or ensemble.
Learning Goals
The theme changed now to “Refactoring”.
• Describe what refactoring is

• List the names of a few popular refactorings
• Use ‘Extract Function’ to improve the readability of a long
method
Session Outline
• 5 min Connect: collect names of refactorings
• 5 min Concept: Martin Fowler’s refactoring definitions
• 10 mins Concrete: Pairs review Tennis and suggest refactorings
• 10 min Concept: Demo extract function on Tennis1
• 25 min Concrete: Pairs refactor Tennis1
• 5 min Conclusions: own definition of refactoring
Names of Refactorings
Have people note down names of refactorings that they know already
and then report to the group. Write up names on a whiteboard or
flipchart. When you come to this part, you might discover no-one
knows any names at all. In that case suggest some refactorings they’ve
used without knowing their name. For example Rename Variable and
Extract Interface. That might prompt them to remember some more.
Otherwise, just move on to the next step.
Refactoring definition
Put up Martin Fowler’s definitions¹⁴ of Refactoring as a noun and verb

on a projector screen or write them on a flipchart. Explain how you
understand these definitions. You could point out the code shouldn’t
break while you refactor, and the reason to refactor is primarily
economic not moral. You could mention that as you refactor you take
a series of small steps and can commit and share your work after any
completed step.
Pairs review code
Have them review the code in “Tennis1” in The Tennis Refactoring

Kata¹⁵, and think about what refactorings they might want to apply
to this code. The idea is just to read the code at this point, not change
it.
When they’ve looked at the code, go through their suggestions. Tell
them the ‘official’ name (from Fowler’s book) if they don’t know what
the refactoring is called.
Demo Extract Function
The implementation for Tennis1 has a Long Function smell. Demon-

strate how to use Extract Function to split it into parts. I suggest
three functions you could perhaps call ‘equal score’, ‘endgame’ and
‘early game’. Use IDE refactoring tools if you have them and if so
get someone to write on a whiteboard the key combinations you are
using.
Stop refactoring when you are confident they have got the idea -
perhaps you’ll only do one of the three extract function refactorings.
Explain the goal is to make the public ‘score’ function look short and
more readable. There will still be other code smells, leave them for
later. For the moment we are focusing on Extract Function.
¹⁴https://martinfowler.com/bliki/DefinitionOfRefactoring.html
¹⁵https://github.com/emilybache/Tennis-Refactoring-Kata
Do refactoring
Have them do what you just showed them and continue doing ‘extract
function’ until they have the public ‘score’ function in a good state.
If they have time, they can carry on and refactor away more code
smells.
Define ‘Refactoring’
How would you define ‘refactoring’? Write a definition on a sticky

note and take it with you to put next to your screen.
5. Misconceptions about Refactoring

In this session we talk about what refactoring is and why we do it.
Learning Goals
We’re still working in the “Refactoring” theme.
• Identify good reasons and situations to refactor

• Use ‘Rename Variable’ refactoring
Session Outline
• 15 min connect: Refactoring misconceptions
• 5 min concept: Refactoring purpose
• 30 min do: Refactor Tennis3
• 5 min reflect
Discuss Misconceptions
Create a handout with a number of statements about refactoring,

which are controversial, wrong, or only partially true. If you have
insight into their organization, you might be able to include some
really pertinent misconceptions. Ask people to discuss the statements
in small groups and decide whether each one is true or false.
Example statements:
1. When someone is refactoring the code may be broken for a few

days while they do it.
2. If you encounter ugly code it is your moral duty to refactor it.
3. A good time to refactor is before you add a new feature.
4. You should refactor in a code branch and have QA test it to
confirm you haven’t broken anything before merging to master.
5. You can only refactor if you have test coverage over 80%.
6. You should get permission from your manager before refactor-
ing.
7. Code reviews generate refactoring tasks in the backlog.
Purpose of Refactoring
Remind people that the purpose of refactoring is to make code easier

to understand and cheaper to modify.
It’s a necessary part of iterative and incremental development. You
don’t plan the entire design up front, you take working code and
change the design to support new functionality.
Another use of refactoring is for code that has technical debt, that is, it
is harder than necessary to understand and modify. You do a series of
safe refactorings on it to improve readability and reduce complexity.
Work on Tennis3
Ask people to note down code smells they see in Tennis3 in The Tennis
Refactoring Kata¹⁶. As the address these smells, ask them to note
the names of refactorings they use. Hopefully they will at least find
“Mysterious Name” and apply “Rename Variable”. If they’re using an
IDE, have them learn the keyboard shortcuts.
Reflect
Have people note down an answer to this question: When should you
refactor?
¹⁶https://github.com/emilybache/Tennis-Refactoring-Kata
6. Make a test list

In agile, Big Design Up Front (BDUF) is something to be avoided, but
that doesn’t mean we don’t do any design at all. Before starting to
code with TDD it really helps to spend a few minutes on Little Design
Up Front. Part of that is making a list of test cases we will work on.
Learning Goals
The theme is back to “small steps”.
• Describe why a test list is useful in TDD

• Create a test list to use in TDD
• Evaluate whether a test list is fit for purpose
Session Outline
• 5 min connect: what to do before you start coding?
• 10 min concept: Test List
• 40 min do and reflect: Create and evaluate test lists
Connect
When I was young, I used to read these books in a series called
“Choose your own adventure”. The idea was the story would change
according to decisions you made as reader. After a few pages describ-
ing what your character is experiencing - “you are looking at a temple
complex with a large stepped pyramid with imposing entrance in
front of you and a beautiful grassy meadow to one side”, it would say
something like “to enter the temple, turn to page 164. To walk into the
meadow, turn to page 23”. So you turn to page 164 but quickly find
out there is a big orc in the temple that attacks your character with an
axe. So you quickly revise your choice and turn back to page 23 and
look at the meadow. Here you discover a beautiful unicorn. That’s
what we’re doing in today’s warmup - choose your own adventure.
Will you find the unicorn, or the orc?
Print out the options below on one side of a piece of paper, and the
consequences on the other side. Ask people to read through these
descriptions and choose the option that best matches how they think
they would behave. Then ask them to turn to the next page to see the
possible consequences.
Option A
Start by opening a new file in a code editor. Begin declaring a test case.
Refer back to the requirements document and pick the first thing it
refers to to turn into a test. Go back to the editor and write that test
case.
Option B
Start by reading the requirements carefully and sketching ideas in a

notebook or on a whiteboard together with a colleague. When you
have understood more about what’s needed, note down some test
cases you’ll need. Explore a few different avenues and aspects of the
problem and expand your test case list. Analyse the list and pick the
simplest, smallest one to begin with. Open your code editor and write
that test.
Option C
Start by reading the requirements carefully. Every time you find

something that will need a test case, highlight it. Spend considerable
time analysing each highlighted case and identifying edge cases,
invariants etc. When you’re ready, go to a code editor and declare
a test case for each thing you highlighted. Define custom assertions
and supporting fixture code as needed. Comment out all but the first
test case.
Option D
Start by reading the requirements carefully. When you’ve understood

them, write code to fulfill the requirements. When you think ev-
erything is working, write a test case that checks the code works.
Continue adding test cases one by one checking each passes as you
finish it.
Option A consequences
If your requirements are well thought through this could actually

work ok. The danger is they are not, and then you might end up
starting with a test that is too difficult to get to pass quickly. You
might need quite a bit of setup and become discouraged and give
up on writing tests. Happily, it’s easy to recover from here. Spend
some time reading the requirements and analysing them. Then start
again with a different test case. Take a look at Option B for more
information.
Option B consequences
This is an excellent way to begin working on a new piece of code.

Your aim is to understand enough about the requirements that you
find a good starting point. Your first test case should be simple enough
that you will make it pass quickly, then you have some ideas about
where you will go from there. You won’t do really comprehensive
analysis until you’ve written some code and know a little more about
the problem.
Option C consequences
This option represents a serious investment in test analysis and design

before any coding of the solution. It’s admirable that you have such
high ambitions for your test code, and I’d hope for some really solid
test cases. The danger is that you invest a lot before you really know
the shape of the solution code. You might write more tests than
are needed to prove the code works, or end up designing them in
a way that will need a lot of refactoring later. I’d recommend a
more lightweight analysis and an iterative process to improve the
tests as the solution takes shape. Take a look at Option B for more
information.
Option D consequences
This is not really a test-driven approach, is it? By writing the so-

lution code first you lose the opportunity for the tests to influence
your design. You may write more code than is needed to fulfill
the requirements since you have no tests to guide you. In the end
your tests may become tightly coupled to your implementation and
difficult to maintain as the design evolves. I’d recommend a more
test-oriented analysis of the requirements. Take a look at Option B
for more information.
Concept: Test List

Before writing your first test, you should do a little analysis and
identify scenarios that you’ll want to make into test cases. Remind
people of the test lists you used for previous katas you did in other
sessions, eg LeapYears, FizzBuzz and ShoppingBasket. Bring them up
on the screen if you saved a picture of the whiteboard or have them in
a shared document. When you have reviewed two or three test lists,
ask people to identify what the characteristics are for a good test list.
You’re looking for things like:
• Each case has example input and expected result

• A rule or a name to describe each case
• Not too many cases, you will add to the list when you start
programming
Write these characteristics up on a whiteboard or shared document.
Concrete and Conclusions: Write test lists

and evaluate them
• Ask them to work in pairs to come up with a test list.
• Give them a requirements document to work from, like MarsRover¹⁷.
• After they have had time to read it, ask if there are any questions
about the requirements. Take the role of business expert and
answer their questions.
• Ask them to write a list of 4-6 test case ideas, give them about
10 minutes
• Ask them to show their list to another pair and discuss if it
has the characteristics identified earlier. (This is the Conclusions
part)
¹⁷https://sammancoaching.org/kata_descriptions/mars_rover.html
• Spend a few more minutes improving the list in pairs
Repeat the above steps for a second kata if there is time, for example
Fractions or MontyHall.
Fractions¹⁸ or MontyHall¹⁹.
¹⁸https://sammancoaching.org/kata_descriptions/fractions.html
¹⁹https://sammancoaching.org/kata_descriptions/monty_hall.html
7. Arrange - Act - Assert

The theme this time moves to test design, and in particular, structur-
ing tests as readable, straightforward code.
Learning Goals
The theme is changed this time, to work on designing tests.
• Use Arrange - Act - Assert structure when writing a test case

• Explain why test case structure should be simpler than produc-
tion code
Session Outline
• 15 min connect: review test code samples
• 5 min concept: Arrange - Act - Assert
• 30 min do: Mars Rover, Shopping Basket or Tennis
• 5 min reflect: code review
Connect: Review sample code
Pin up some code samples around the room. For example Mars Rover
Kata Sample Tests²⁰. Some follow Arrange-Act-Assert structure, some
don’t. Have them review the code and vote with their feet which is
most and least likely to contain bugs.
Concept: Arrange - Act - Assert
Famous quote from Brian Kernighan: “Debugging is twice as hard as

writing the code in the first place. Therefore, if you write the code as
cleverly as possible, you are, by definition, not smart enough to debug
it.”. It’s an exhortation to keep your code as simple as possible so you
have a chance of being able to debug it.
²⁰https://github.com/emilybache/MarsRover-Sample-Tests
Similarly you could say about test code - All code you write may
contain bugs, and unit tests help you to find those bugs. If you write
the test code as clever and complex as the production code, your test
code will need tests too!
No-one wants buggy test code that could hide bugs in the production
code. So what to do? We write our test code to be as simple and
straightforward as possible. Nowhere for bugs to hide. Using a
standard Arrange - Act - Assert structure helps.
Bring up the code sample with the best AAA structure and go through
it.
Do: a Kata
I suggest one of the katas you created a test list for last time,
like MarsRover²¹. In that case, each pair can pick one of the lists
they created before. Alternatively use Tennis²² or Shopping Basket²³,
which should also be familiar. Practice writing new test cases with
an Arrange-Act-Assert structure.
It’s useful to choose a kata they already know at least a little bit, so
they make more progress and practice writing more than a couple
of test cases. Don’t worry too much about using a technique like
Parameterized or Data-Driven Testing, unless they’ve used it before
and know the syntax. For the moment you just want to make sure
the tests are straightforward, easy to read, and test one thing each.
Plan for a follow-up session to learn about using parameterization to
reduce duplication.
Reflect
Divide into pairs and take turns to explain to the other person: Why
should test case code structure be simpler than production code
structure?
²¹https://sammancoaching.org/kata_descriptions/mars_rover.html
²²https://sammancoaching.org/kata_descriptions/tennis.html
²³https://sammancoaching.org/kata_descriptions/shopping_basket.html
8. Start with the Assertion

Tests usually have the structure Arrange - Act - Assert. If you write
the test case in reverse order, starting from the assertion, it can help
you to design it better. For example, you avoid overdesigning the
setup, only create the things you need. Hopefully during this session
the participants will discover some other advantages too.
Learning Goals
The designing tests theme continues.
• Choose to begin with the assert when writing a test case

• Explain why good test design is important in the practice of Test-
Driven Development
Session Outline
• 10 min connect: sticky notes of key concepts the group should
know already
• 5 min demo: start with the assert
• 30 min do: Mars Rover or Tennis
• 10 min reflect: observations
Connect
In advance of the session, write sticky notes with some concepts they
should already be familiar with, and stick them where everyone can
see them on a whiteboard or flipchart. For example you could have
these:
• Red, Green, Refactor

• Baby steps
• Arrange, Act, Assert
• Triangulation
• Strong-Style
• Ctrl-Shift-R (Or whatever keyboard shortcut brings up the

‘Refactor This’ menu in your IDE)
Ask the group to gather around the stickies. Ask for a volunteer to
step forward, pick up a note and explain what it is. Use coaching
questions to help them to explain the important and relevant aspects
of the thing, without you taking over the explanation. When the note
is explained, move it to one side. Repeat until different people have
explained each note.
With a remote group, put the statements in a shared online document
and use strikethrough to indicate the concepts which have already
been explained, rather than moving them around.
Demo: start with the assert

Write a starter test case for the chosen kata, starting with the asser-
tion.
Choose a kata where there is some setup and it’s hard to write the
whole test on one line. For example Tennis and Mars Rover both need
some kind of class which you ‘Arrange’ into an initial state, before you
‘Act’ and call a method on it, then ‘Assert’ the result of the method or
the state of the class.
Do: a Kata
You could start over with the same kata as last time, or go for a new
one. I suggest MarsRover²⁴ or Tennis²⁵. Practice writing new test cases
starting with the assertion and working back to the setup. Be sure to
start over from scratch and not just take up where they left off before.
The repetition will help to make it easier to apply the new “start with
the Assert” practice.
²⁴https://sammancoaching.org/kata_descriptions/mars_rover.html
²⁵https://sammancoaching.org/kata_descriptions/tennis.html
Reflect: Observations on starting with the

assertion
Discuss with your pair your observations about your TDD session
and specifically the effect it has when you begin by writing the
assertion. Note down observations on sticky notes and give the notes
to the facilitator.
To trigger more specific observations, you could write up this list of
areas on a whiteboard or flipchart at the front:
• Baby steps
• Test Readability
• Duplication between test cases
• Pairing/Communication
• IDE/Editor
Read out some or all of the observations and stick them next to the
relevant area. Create more areas as needed.
The aim is to get people to see that writing the assertion first will help
them to succeed with many of the concepts we went through in the
‘Connect’ part of today’s learning hour.
9. One function at a time

This kata is a couple of steps up in difficulty from Leap Years. You are
designing one main function with several helper functions. You test
drive the implementation one helper function at a time. The group
learns about this strategy for breaking down a problem into pieces
suitable for TDD.
Learning Goals
The theme is “Testable Agile Design”.
• Solve a problem by breaking it into independently testable

pieces
• Distinguish between overdesign and testability
Session Outline
• 5 min Connect: “Take a Guess” with topic Overdesign
• 10 min explain yatzy & make list of test cases together
• 10 min ensemble with you navigating
• 30 min ensemble continues
• 5 min Reflect: whole group temperature - too many/too few
tests?
Connect
The topic is overdesign in software. Read the list of statements below.
Circle those that are relevant to the topic, and cross out those that are
unrelated. Compare your answers with your neighbour.
• All problems in computer science can be solved by another level

of indirection …except for the problem of too many layers of
indirection.
• Boundary condition analysis is useful in test design.
• Abstract Factory is a design pattern.
• “You Aint Gonna Need It” is a poor excuse used by failed de-
signers to justify deleting useful extension points in the software
design.
• In code reviews, you should suggest replacing any global vari-
ables with the Singleton pattern.
• Primitive Obsession is a code smell.
• UML is a graphical language for describing software design.
• Premature Generalization is a code smell.
Demonstrate
Starting at a whiteboard, explain the purpose of the Yatzy²⁶ kata. Read
the description to the group, and put the category and scoring rules
on a screen they can see. Ask the group if they can see any examples
in the description that would make good test cases. There are lots! For
example they might find these examples:
• 1,1,3,3,6 placed on “chance” scores 14 (1+1+3+3+6)

• 1,1,1,1,1 placed on “yatzy” scores 50
When they’ve identified these, ask the group what order they would
tackle the examples in. When some consensus arises, note this on
the whiteboard. I expect they would want to order by category, for
example:
• Small straight: 1,2,3,4,5 scores 15

• Large straight: 2,3,4,5,6 scores 20
• Chance: 1,1,3,3,6 scores 14
• Yatzy: 1,1,1,1,1 scores 50
• Yatzy: 1,2,3,4,5 scores 0
• …
Don’t worry too much about what order they want to do the cate-
gories in, although I do suggest you encourage them to tackle ones,
twos etc before tackling pair or full house.
²⁶https://sammancoaching.org/kata_descriptions/yatzy.html
Take the navigator role in the ensemble, rotate the driver. Steer the
group towards a design where you have a function for each yatzy
category, and some kind of switch statement in the main function
that calls them. Each such function is named after the category, takes
a list of five integers, returns an integer. You should get at least as far
as creating the first of those functions.
Do
Hand over the navigator role to someone else, continuing to code
from where you got to. Make sure they continue to work in small
steps, implementing function by function and keeping all the tests
passing.
Reflect
In pairs, discuss: - How did we break down the problem into pieces
for TDD? - Is each piece of the design testable by itself? - Do we suffer
from overdesign?
10. Inspirational Demo

It’s the last session for a little while and I want to give the group
some idea of what we’re working towards. It might encourage them
to practice while I’m away.
Learning Goals
This session is a little different - the goal is not to learn about a
particular theme but rather to gain awareness.
• Identify what TDD looks like when it’s done well
Session Outline
• 45 min Demo: TDD the best way you know how
• 10 min Reflect: group observations
Demo
Show off how productive you can be with TDD. Practice this demo
in advance so it goes smoothly!
Use the same programming language that they use, but don’t feel
restricted to use the same tools. Do show off all the modern IDE
features and refactoring shortcuts that you’d like them to be using.
This is what I would call a “Prepared Kata”. It takes some hours of
practice to do these well. It can be hard to both type and talk at
the same time. If you can, I recommend recording the coding part
in advance. The recording can be a silent screencast showing your
IDE as you code. Do the commentary live, pausing the screencast as
needed to explain the code that is appearing on the screen. Another
variant is to ask a trusted colleague to be the typist while you navigate
them and do all the talking.
By this point you should have got to know the team a little and their
codebase. Pick a TDD exercise that is as close as possible to code they
know and actual problems that they face. Alternatively pick a kata
you’ve done together already, like Yatzy or Mars Rover.
I don’t always manage it, but my ambition is to create and perform
a new code kata based on a snippet of their actual codebase. I like
to publish the starting code on a publicly hosted git server and do
the demo on a non-company sanctioned laptop. For those reasons I’ll
anonymize any code from their codebase and only retain the basic
structure so it shouldn’t reveal any company secrets. I aim to show
them that it is possible to work in a different way even when you
begin in a codebase like theirs.
Reflect
Ask the group to write observations on sticky notes. Ask some people
to read theirs out.
Learning Topics
These are the themes I have at the moment:
• Small steps
• Refactoring Safely
• Working with Legacy Code
• Designing Testable Code
• Designing Tests
• Double-Loop TDD
• Agile
As you can see from the 10 sample learning hours in the last chapter, I
tend to have two or three in a row on the same theme before changing
to another.
Different organizations have different challenges, and I wouldn’t
necessarily use every theme in every coaching engagement or with
every team. Likewise your own strengths and interests will influence
which themes you take up in your learning hours.
For each theme, I’d like to summarize what it is about and some of
the topics I include there. If you are not familiar with one of these
topics, there is a section of references at the end of this book which
might give you some suggestions of where to learn more.
Small steps
These learning hours are all about learning how to work incremen-
tally. Instead of writing all the tests all the implementation first, we
work with both together piece by piece. This way of dividing our time
and working iteratively and incrementally on both code and tests is
key to successful TDD.
Topics:
Learning Topics 94
• States of TDD: Red, Green, Refactor

• Commit often
• Strategy: Revert on unexpected red
• Design a function incrementally
• Design a class interface or API incrementally
Refactoring safely
Martin Fowler has written an excellent book about Refactoring. It’s
well worth getting a copy and encouraging everyone to read it, even
if they only get as far as a couple of chapters. These learning hours
help you to practice the skills you need to use the refactorings in his
book and improve the design of your production code.
Topics:
• detecting code smells

• removing duplication
• improving names
• combining many small refactorings to make a bigger change
Legacy Code
Legacy code is basically code that is difficult to work with but we have
to change. One of the reasons its difficult to work with is probably that
the design is poor and it lacks both modularity and automated tests.
Adding tests to this kind of code is often a chicken-and-egg problem.
You can’t add tests until the code is redesigned to be more modular,
and you aren’t confident to change the code to make it more modular
until you have some tests.
The ‘Legacy Code’ theme is closely related to both ‘Refactoring’ and
‘Test Design’, but I tend to put it in its own category since there are
techniques for handling legacy code that you wouldn’t need in other
situations.
Topics:
Learning Topics 95
• Code Coverage to guide test creation

• Approval Testing including Combination Approvals
• Mutation Testing
Testable Design
These learning hours are all about how the need for both testability
and the ability to refactor easily affects your design choices. One of
the biggest reasons people give up on TDD is if they lack the design
skills to do it.
Topics:
• Functions are easier to test

• Dependency Injection (aka Dependency Inversion Principle)
• Design Heuristics
• Consistent Abstraction levels
Designing Tests
Structure of a Test Case, sharing setup, how to verify correct be-
haviour. Some of this is specific to the programming language and
framework you are using. Some of it is general good design principles.
Topics:
• Arrange-Act-Assert
• Styles of assertion - matchers
• Stubs
• Fakes
• Mocks & Spies
• Test data
• Consistent Abstraction levels
Learning Topics 96
Behaviour-Driven Development
Many code katas have a description that contains a list of examples
or scenarios that are easy to turn into test cases. One of the skills of
TDD is taking a vague User Story and creating such a list of scenarios.
This is something we can practice and get better at.
Behaviour Driven Development builds on Test-Driven Development
and introduces the idea of working outside-in, from the user perspec-
tive first. A more ‘classic’ TDD approach has you working inside-
out, from the nitty-gritty details of an implementation out towards
something a businessperson would be able to use. In BDD as you
work outside-in you are guided by a higher-level test written from the
customer or user perspective. As you discover more detailed pieces
of code that are needed, you also add ordinary unit tests to drive out
small pieces of functionality. You find yourself doing ‘double loop’
TDD. Coming up with those higher-level, user-perspective tests is
also something you can practice.
In a production setting, you would come up with examples and
hence test cases by having conversations with business people who
understand the problem. When we are practicing we will need people
in the group to play the role of the business person, so it’s good to
choose exercises are taken from everyday domains where you could
expect most people to readily understand the business rules. You can
discuss the domain and together come up with examples that you can
then formulate into test cases.
Agile
Games for learning about DevOps and Agile in general
I designed a Pipeline game²⁷ and a custom deck of cards for playing
it. The idea is each card represents a step you could include in
your pipeline, and you lay them out on a table in the order you’ll
implement them. You do it in a group, discussing the pros and cons
²⁷https://www.eficode.com/pipeline
Learning Topics 97
of pipeline design and hopefully come to better insights about what’s

important.
I like the Kanban dot game²⁸ that was designed by Marcus Ham-
marberg and Joakim Sundén and is described in their book ‘Kanban
in Action’. I’ve used it with teams to help them to understand the
importance of limiting work in progress.
There are various other games and simulations for understanding
concepts like velocity, minimum viable product, self-organization etc.
Take a look at Tasty Cupcakes²⁹ for more ideas.
Add your own ideas

Don’t feel restricted to my list of themes in any way, shape or form!
Each coach has their own perspective and background. Use what you
know and put together your own learning hours. Look through your
bookshelf and technical video collection. What topics and skills have
you found most useful in your career so far? Can you make a learning
hour around one of them? I find designing small exercises is fun and
challenging for myself, and putting it together into a learning hour is
worthwhile. I love it when people start to ‘get it’ for themselves.
²⁸https://livebook.manning.com/book/kanban-in-action/chapter-13/
²⁹https://www.tastycupcakes.org/
Remote Learning Hours
The learning hour samples that I detailed earlier in the section are all
conceived as in-person events. In these times it’s not unlikely you’ll
be instead teaching remotely. In my experience, it can still work really
well and your basic planning will still be relevant.
In addition, you need to find good technical solutions to these things:
• videoconferecing and textual chat

• ability to split up videoconferencing into pairs or smaller groups
• shared whiteboard/flipchart
• ability to share a coding environment and switch typist.
• shared retrospective notes
There are several good options here. Anything I recommend for

videoconferencing or shared whiteboard will probably be out of date
before you read this. There is rapid development in these tools. I will
mention a couple of technical solutions for the rest though.
Cyber-dojo
I’ve found cyber-dojo³⁰ very useful for setting up exercises quickly,
and also for viewing what code the participants are writing during the
session. It’s a substitute for going round looking over the shoulders
of the pairs as they work. Pairs can easily switch typist too - they
both use the same URL and when it’s time to switch, run the tests
and refresh the browser.
For commercial coaching work, you will need to buy a license if you
want to use the public server. Sometimes it gets overloaded or goes
down entirely. There are instructions for setting up your own server
on the cyber-dojo github page³¹.
³⁰https://cyber-dojo.org/
³¹https://github.com/cyber-dojo/cyber-dojo
Remote Learning Hours 99
VNC
I’ve had some success using a shared remote server for group pro-
gramming. I set up a Linux machine on Amazon’s EC2 with a
graphical desktop running a popular IDE. Everyone joins the same
videoconference call, then we all use VNC to log into the machine.
This means everyone can use their keyboard and mouse to control
the remote machine, so we just agree verbally who should control
it at any one time. Switching typist takes no time at all. The main
downside I’ve discovered is that keyboard mapping from a local mac
keyboard to the remote linux machine can be a bit quirky. If people
are using Windows locally then there is much less of a problem.
Everyone uses their local machine

and screenshares
If everyone works on their own machine then there will inevitably be
some setup time while each person clones the exercise repo and sets
up their development environment. For a one hour session, this can
be a significant cost and I would generally prefer one of the other
options I mentioned previously. However, if people use their own
machine they can learn keyboard shortcuts and improve their IDE
configuration in a way that lasts better after the session.
If possible, have them download the exercise and setup their en-
vironment in advance of the learning hour, perhaps email them
instructions the day before. If people are going to work in a pair, they
need to be able to switch typist. As well as changing who shares their
screen in the videoconference, you’ll need to get the code changes
from one local machine to the other. There are various solutions for
that. A very simple one is to copy and paste the sourcecode into the
videoconference group chat window. That quickly stops working well
when you have several changed files however! A better way is to push
and pull to and from a shared remote git branch. There are various
scripts and IDE plugins to help with this.
Remote Learning Hours 100
Retrospectives
So far this is the part that I’ve had the most trouble with when
working remotely. People seem somehow reluctant to write virtual
sticky notes. Perhaps they feel more permanent and less private than
actual paper. At least try to get people to say out loud what they’ve
observed and make your own notes on what they say.
Part 3: Samman
Coaching
Engagements
In the first sections of the book we looked at the details of what
a Samman technical coach does in the Ensemble sessions and the
Learning Hour. This is what you spend the majority of your time on.
In this section we take a step back and look at the overall coaching
engagement with an organization. We’ll talk about marketing, sales,
persuading a team to take you on as coach, and setting expectations.
In the last couple of chapters, we’ll talk about your coaching career -
how you get started and improve as a coach.
Most of the coaches I know are consultants who engage with a
number of different organizations over periods of months and years.
That is also the way I work, and what I am explaining in this part of
the book. I believe it should also be possible to be an internal coach
in a large organization. I don’t have experience of that but I hope you
will still find useful material in this section.
Finding an Organization
and Teams to Engage with
Finding good clients is crucial for a consultant. A good client will not
only pay the bills but also give you opportunities to really make a
difference, learn new things and have fun. Let me tell some stories
about what has worked for me.
The department striving for Technical

Excellence
I knew the senior agile coach there, we had done a project together
a few years previously. They were advertizing for a Scrum Master
position in her department so I called her and explained to her over
the phone what kind of assignment I was looking for. She introduced
me to her department manager, I’ll call him Eric. The three of us met
a few days later so I could explain more fully what I could do, and
that it wasn’t what a Scrum Master normally did.
It turns out Eric had worked for this large corporation for his whole
career, but was fairly new as a manager for software development. He
now had about 50 people working for him, in several agile teams. Eric
had previously been responsible for a factory production line where
they used Lean methods.
Eric understood the relationship between speed and quality. His expe-
rience from manufacturing told him that early defect detection and
a culture of continuous improvement were crucial for productivity.
He was ambitious for his development teams and wanted to be the
best department in the organization. The one where all the really
good developers wanted to work. The one with the latest technologies,
the lowest bug counts, the most scalable products and the best agile
teams.
Finding an Organization and Teams to Engage with 103
I talked about technical excellence and agility in the codebase. I spoke

warmly about how working in an ensemble fosters collaboration and
teamwork. He understood the potential of this kind of coaching to
raise standards even further and make developers even happier to
work there. He wanted to try it.
The company struggling with defects

The Product Manager had previously heard me speak at a local event,
and knew I had worked with automated testing and test strategy.
I’ll call him Tom. He contacted me wondering if I could consult
with them on their automated testing strategy, since they had a
lot of defects in production and their customers were complaining.
Tom was in charge of strategy for their product range and reported
directly to the CEO. The company was less than 100 people overall,
of which about 25 were developers working on the software part of
their products.
At the initial meeting I explained that although I could help them
define a strategy and build an automated test suite for their products,
what they really needed was for the developers to change their
behaviour. Technical excellence, unit testing, continuous integration
- lots of practices to raise quality in the codebase and stop the defects
from appearing in the first place.
He invited me back for a second meeting together with the CEO and
the development manager. I spent some time explaining what I do in
terms that the CEO could relate to. I explained that the root cause
of defects is often technical debt and code that is hard to understand
and change.
I talked about the economics, too. They were spending about 50% of
their developer effort on investigating and fixing defects, and only
perhaps 20% on new feature development. We could work out roughly
what it would be worth for them to raise quality to the point where
they only spent 20% of time on defects. The ability to increase in new
feature development and happier customers would more than pay for
my consultancy fees.
The CEO understood this line of reasoning, and gave Tom a budget
to buy my services with.
The twenty-year-old codebase

Daniella was the Scrum Master for several teams in the same Release
Train in a large corporation. She and I had been colleagues at the same
consultancy company years ago. Daniella called me when she heard
about the work I’d done with Eric’s department. She met one team
who spoke warmly about what they’d learnt from me. They showed
off the ensemble station they’d built in their team area.
Daniella’s teams were in a somewhat different position from Eric’s
though. They were all developing in the same 20 year old codebase
that was difficult to work with. They had big ambitions to split it
into smaller services, improve the test coverage and start operating
as separate DevOps teams. They were struggling to get anywhere in
complex code that most people didn’t really understand.
I explained how I could help the developers to gain better control
over the code through refactoring and adding more unit tests. We’d
work on splitting apart the codebase into microservices in smaller,
less risky steps. Developers could learn to communicate better about
design decisions and keep to shared design goals by working in an
ensemble.
Daniella was keen to raise morale amongst developers and was
hoping this coaching would raise productivity and get the change in
architecture moving a little faster. She arranged with her boss to get
a budget to hire me.
Too stressed out and busy

A friend of mine, Simon, had a friend at company AcmeCorp, Ellen,
who worked as a developer there. Ellen heard about the kind of
coaching I do from Simon and realized her team would really benefit
from it. She talked to her manager, who talked to Simon, who got in
touch with me. I explained what I did and they booked a (paid) half
day initial workshop. I would introduce myself and I would facilitate
the team doing ensemble programming on a code kata. I thought it
sounded like a reasonable way for us to get to know each other and
work out if they’d like to book some more coaching.
A couple of weeks before the date we’d set for the workshop, they
called to ask if they could postpone it. They had an important release
coming up and needed to focus. So we set a new date two months
later. Unfortunately the same thing happened. The team was just too
stressed to find time to do a half day workshop. I reasoned that if they
couldn’t manage half a day, they were in no position to book any more
coaching. Since I was quite busy with other work, I declined to set a
new date for the workshop. You have to be able to slow down before
you can speed up.
Sales and Marketing principles

I hope you can pick out some common themes from the stories above.
• your network is crucial, people hire people they know.

• listen first to discover what their specific problems are
• adapt your pitch for the audience and their specific problems
• they have to be willing to invest their time, which can’t happen
if they are too stressed out
• your best marketing department should be your previous cus-
tomers
Sales pitch
Once an organization is interested in your services, you’ll want to
explain in more detail what you’re selling. An example sales pitch:
Samman technical coaching helps developers to change the way they
work, day to day, minute by minute, in their codebase. They learn to
raise the quality of code in their product and work more effectively
together as a team. The coach works closely with the developers while
they are writing code to remind, reinforce, teach and demonstrate
good coding practices. You should see:
• Reductions in technical debt

• Better automated tests
• Improved communication between developers within the team
• Smaller, safer changes integrated often and documented well
• Improved effectiveness using team development tools and IDEs.
The Coaching Proposal

During the sales process, you’ll be making a detailed proposal to the
potential client. Find a good way to convey the information to them.
Perhaps a document, presentation slides or a video of you talking and
sketching on a flipchart. That last one worked well for me, by the way!
The proposal could say something like this:
• The coach works with 2 teams over a period of 3 weeks, total 10

coaching days.
• The coach is away for 3 weeks while teams consolidate what
they’ve learnt.
• The coach returns for 10 more coaching days.
• Coaching continues three weeks on, three weeks off, until the
teams feel confident using the new skills they have learnt.
Each coaching day comprises 2 hours working in an ensemble with

each team, plus a learning hour. In the learning hour, we practice
skills and learn theory using exercises. In the ensemble sessions we
usually take one of the ordinary tasks from the team backlog, and
work through it together. We learn how to tackle it using new skills
and techniques.
Before the main coaching begins with a team, we hold couple of ‘kick
off’ meetings. It’s important for the coach to get to know the team and
to do more detailed planning. These workshops should be held at least
a week before the main coaching begins.
During the coaching, the team will want to reduce the number of
tasks they work on so that they have time and energy to devote to the
coaching. As a rule of thumb, allocate 1/3 fewer tasks when planning
the period when the coach is present.
The potential client might ask for more information. Below are some
questions I’ve experienced and some ideas about how to answer them.
Why only two or three teams at a time?

There are only so many hours in the day, and you want to spend
enough time with a team to make a difference. If there are more
than three teams, see the next section about working with larger
organizations.
Why only ensemble working for two hours

with each team?
You’re going to be coaching a team that probably hasn’t worked as
an ensemble before. At first, it will be awkward and tiring and most
teams won’t manage it for more than a 2 hour session with you each
day.
What if there are less than 2 teams in the

organization?
It’s difficult to do ensemble programming for more than 2 hours at
a stretch, at least while people are still learning how to do it. If you
have one team to coach, consider coaching half days 8:00 - 12:00. You
could spend the other half of your time on some other assignment,
perhaps remote development, or on developing new learning hours.
Another option is to spend your afternoons pair programming with
team members and continuing to coach in that style. At some point
the team might feel confident enough with ensemble work that they
want to do it for more of the day.
We have about 10 teams, which ones should

we start with?
For a medium-sized organization like this you could usefully bring in
a second coach right from the start. Otherwise you could choose to
prioritize:
• teams that are especially enthusiastic about being coached

• teams that are newly formed and would especially benefit from
teambuilding activities like this
• teams that are in particular need of encouragement and new
thinking about their problems
Why will the team work on fewer tasks while

the coaching is going on?
The team will spend 3 hours a day with the coach on each coaching
day. Although we will be working on their normal programming
tasks during some of that time, we will have a focus on learning new
skills, not completing tasks. In the longer term as the team learns the
new skills and the code quality improves they should become more
productive and compensate for this temporary slowdown.
What if the team works in more than one

programming language?
If they are a cross-functional team then working as an ensemble
will build up their teamwork and help them to learn one another’s
languages. You should be able to build a whole feature that crosses all
the language boundaries and do that more efficiently when everyone
is present and communicating well.
An alternative is to split the teams up into smaller groups for each lan-
guage. In one organization I coached, the architecture had three main
parts - Javascript front end, Java backend, and embedded C device.
Even though they normally worked in two cross-functional teams, we
split into in three language-specific groups for the ensemble sessions.
This arrangement helped us to focus on language-specific problems
with refactoring techniques and test frameworks. If I had worked with
these teams for longer I would probably have tried to re-combine
them.
What’s the difference between a Samman

technical coach and a Tech Lead or Architect?
All these roles are about helping developers to make better choices,
and to work more effectively together. Where they differ is in what
they do day-to-day to achieve that.
A Tech Lead will typically be a key member of one team, taking a lot
of responsibility for the overall design and direction of the code. They
may write the most challenging parts of the software themselves,

review code written by fellow team members, and mentor more
junior developers. This is typically a full-time role in one team.
There are different kinds of Architect, and different organizations
emphasize different aspects. What they have in common is that they
don’t tend to take direct responsibility for delivering any software
themselves, they rather advise and guide others. They may draw
diagrams, provide example code, build tools and frameworks, or
select standard libraries. All this is in the service of other developers,
helping them to succeed. An architect typically takes a supporting
role helping more than one development team.
A Samman Technical Coach doesn’t make individual contribution
to the codebase as a Tech Lead would, but they do take part in coding
activities. They aren’t a member of any one team, rather support
several as an Architect would.
The coach influences people through coaching techniques, facilita-
tion, mentoring and training, but they do not take responsibility for
design decisions or architectural strategies as a tech lead or architect
would. People in the organization being coached take responsibility
for those things.
Proposal for a large organzation with

hundreds of teams
The best situation I know of for people in an organization with
hundreds of teams is for them be working in a modular architecture
and each team has responsibility for a part of it. They have decision-
making authority over their area of the product, a link to actual user
feedback and a mandate to explore potential solutions. This is the
kind of organization that is described as an ‘elite’ performer in the
Accelerate DevOps research (Forsgren et al). Unfortunately what I
more typically see is that teams in a large organization work with a
highly interdependent architecture and only a tenuous connection to
users. The scope of what they are supposed to build is pre-defined
elsewhere in the organization.
If you’re working with an ‘elite’ ambitious DevOps organization, then

you’ll have fun! Improving code quality and increasing the practice
of TDD will be noticed. I expect them to have lots of metrics and
feedback loops that will improve with the fruits of your work. I think
technical coaching will make a good organization even better.
If you’re not working with an ‘elite’ organization then you can still
make a positive impact. They might not have the measurements and
feedback loops in place to really see what difference you’re making
though. You can still make life better for particular teams and in
particular parts of the codebase.
What is needed in order to transform into an ‘elite’ performing
organzation is a big effort and way out of scope for this book.
It probably involves senior leaders in the organization being very
committed to change. They should probably engage a lot of agile
coaches and invest in training.
In any case with a large organization I suggest starting small with
a few teams. As they grow and learn, highlight what’s improved so
managers understand the worth of the coaching. You can hopefully
start to bring in more coaches, both visitors and longer-term locals,
and increase the number of teams impacted. This is what I have tried:
• Work with 2 teams for 3 weeks, total 10 coaching days

• Work with 2 other teams for 3 weeks, total 10 coaching days
• Work with 2 other teams for 3 weeks, total 10 coaching days.
• Now you have 6 teams in play.
• Do another block of 10 coaching days with each pair of teams.
• Now about 5-6 months of coaching have passed. Evaluate what’s
worked and how to ‘turn up the good’.
• Bring in new coaches from outside, both visiting coaches and
more permanent local coaches.
Another potential source of more coaches is internal people who you

can train to do it. I have so far found it difficult to recruit such people.
Often they have a lot of internal knowledge and are more valuable to
the organization in their current role than they would be as a more
general technical coach.
Closing the Deal

Once you’ve found an organization that is interested in your services,
you need to secure the deal. That means discussing prices and
contracts and how to deal with the purchasing department. I find
this part really difficult.
In “Secrets of Consulting”, Gerry Weinberg has a whole chapter on
how to set your price. He discusses various aspects of pricing, and
it’s worth reading them, and the rest of the book, actually! One of his
recommendations stuck with me and I try to use it. He has someone
else do the negotiation with the client on his behalf. He reports that
his Office Manager, Judy, is a better negotiator than he is. She finds
it easier to put a high value on his services than he himself does,
and he ends up with fees that are 10-20% higher than he would be
comfortable asking for himself. I think that is good advice and it has
worked for me too.
Identify your sponsor

You’re going to be working daily with developers, but typically your
sponsor at the client is not one of them. A sponsor is probably
someone you have talked to during the sales process, and could be
the person who approved the budget for your assignment. It could
be a technical leader or architect who wants to bring you in to help
them achieve their goals for better technical agility. Your sponsor (or
sponsors) have a vested interest in you succeeding, and will want to
be informed about how the coaching is going.
Before you begin coaching any teams, be sure to get in touch with
your sponsors. It’s good to begin a good working relationship with
them as soon as possible. You need to confirm with them
• Which days you will be working and which days you are
away/unavailable
• Which teams they’d like you to coach
• Some means of contacting the teams they’d like you to coach
(email, slack etc)
Your sponsor can help you to book the kick-off meetings with the
teams. You could also ask them to make reservations in the teams’
calendars for 2 hours of ensemble working plus one learning hour for
the first 10 coaching days. Having said that, you might want to wait
with those bookings until you’ve met the teams and held the ‘kick-off’
workshops. More on that in the next chapter.
Beginning Coaching with
a New Organization
Plan to spend time with teams just getting to know them before
launching into the normal coaching routine of ensemble sessions and
learning hours. It’s really important to get a good introduction. This
section contains some advice about how to get started and spend that
time well.
Ideally you schedule this ‘getting to know you’ time a week or two
before the main coaching begins, so you can do some preparation
based on what you learn.
Present yourself
Soon after you arrive, you should present yourself to all interested
parties. Your sponsor should be able to help you to find suitable
occasions. Perhaps they have a regular all-hands meeting where you
can take 10-20 minutes to present yourself. Perhaps you can visit
some of the ‘community of practice’ forums for architects, testers,
developers etc. It might be useful to set up an internal wiki page with
useful information and links on the topic.
Developers will be curious about your background, the coaching
model, which techniques you will be working on. They will want to
know ‘what’s in it for me?’ - why they would want to be coached.
You could talk about scientific research into the benefits of pair
programming and Test-Driven Development. You could tell stories
and anecdotes of successful agile teams applying technical practices.
You should explain what ensemble working is and why it is such a
useful forum for a coach.
How you present all this is up to you. You might have some slides
prepared, that’s how I usually do this. Your style may be to use a
Beginning Coaching with a New Organization 114
flipchart or just tell stories with no visuals. Leave plenty of opportu-

nity for questions. Remember - the most important thing is that they
like you. Good relationships are key.
Kick-off Workshop with each team

Together with your sponsor you should identify which teams would
be good to approach about coaching. You probably want to talk to
their line manager, Product Owner, Scrum Master etc as well, but the
most important people to talk to are the team members themselves. If
they are enthusiastic about the coaching, and you have some support
from your sponsor, hopefully all the other authority figures will be
willing to give it a try.
I like to set up a 2 hour kick-off workshop with each team, where I
send out an agenda in advance and ask them to do some preparation.
Ideally they’ll have already seen you presenting yourself at some
company event already they will be willing to give you a couple of
hours of their time. They will be a bit curious to find out what this
coaching could be like for them, and willing to share a little about
their situation.
This the kind of agenda I use for this workshop:
• Team introduction round (10 minutes)

• Architecture overview (15 minutes)
• Issues in the codebase (45 minutes)
• Structured discussion (30-40 minutes)
• Takeaways (5 minutes)
You should adapt this sample agenda to your situation, of course.
Team Introduction round

Get everyone to introduce themselves, and say a few words about
their professional background. You’re not looking for their entire CV
here, just enough that you have some idea of where they are coming
from. I usually ask two questions:
• how long have you worked for this company?

• how long have you worked with software development as a
career?
Time spent is not the same as experience gained of course, but it

gives you a vague idea of how senior people are. It’s nice to know
for example if someone who looks middle aged has worked for 20
years at this company, or if they only recently graduated as a software
developer following a career change. It helps you to adjust your
assumptions.
While people are talking, I like to have a sheet of paper in front of me
and note down everyone’s names with a thick marker pen that I can
easily read by glancing down. I might note down something about
their background by their name.
I store this sheet in a coloured plastic wallet, together with a “team
diary” notebook. The names sheet helps me to learn the names
quickly, as I can have it on the desk in front of me when I meet this
team for an ensemble session.
Architecture overview
It can be helpful to find out about the architecture of the system they
work on. Sometimes it ends up not helping at all, because you find
yourself mainly working only in a small part of it at a fairly low level.
I usually try to spend a small amount of time at least gathering an
overview.
On some of my first coaching engagements I just asked people
to sketch the architecture on a piece of paper or a whiteboard. I
discovered that the diagrams I got back were pretty vague and hard
to interpret, and often omitted important details. Recently I’ve been
getting better results by explaining Simon Brown’s C4 model³², and
facilitating them to use that format to sketch at least the context and
container diagrams. Another thing that helped, was giving them time
to prepare such diagrams in advance of the meeting.
Once you can visualize the architecture, it can help you to orient
yourself in the code during future ensemble sessions.
³²https://c4model.com/
As well as the production code, it’s useful to know about the in-
frastructure around it. Is there a Continuous Integration (CI) server
or Continuous Delivery (CD) pipeline? How long does it take, how
reliable is it? Do you have access to test environments and good test
data? Is there any deployment automation? Are there security policies
or compulsory reviews? These are all aspects of the development
process which you might want to try to influence, that may not be
directly within the team’s control.
I try to ensure that if we write unit tests, that they will be run as part
of the build and release process. Ideally in a CI server or CD pipeline.
If they don’t have either of those things, then I will want to try to
address that. It’s great to teach developers to write unit tests and do
refactoring, but they are going to learn better if they collectively get
feedback about failing tests even when I’m not there.
Issues in the codebase

The next part of getting to know the team is to get them to talk about
the software they are working on, and any troubles they are having.
I like to ask them to bring some code samples to show me from the
system they are working on. At the meeting we put them up on a
projector so I can look at the code and ask questions. I generally ask
them to show me:
• a typical unit test (if there are any)

• a typical automated system or functional test (if there are any)
• any class or function that you feel is well designed and would
like to see more like that.
• a class or function that doesn’t have any unit tests, which you
would like to have tests for.
• any class or function that is notorious for having bugs in.
• any code that you’ve been working with recently that represents
your current design thinking.
I’m hoping to get a feeling for where I can help them best, and where
the challenges are in the code. Just seeing a few classes and functions
like this gives you a first impression and a starting point. During the
coaching of course you will get a much better understanding. This

initial information will hopefully help you to plan upcoming learning
hours at the right kind of level. It also gives you a heads-up if they are
using an unfamiliar testing framework or particular design patterns
that you should read up on.
Structured Discussion
Now you’ve had a look at the code you might have formed your own
opinions about what they are having difficulty with. That might not
at all match up with what they think the main issues are. You want to
spend some time listening to what they are struggling with, and that
might change your priorities. Your job is to facilitate the discussion
and mostly listen.
You could use a ‘Lean Coffee’³³ format for the discussion, so they set
the agenda and steer the conversation towards the most interesting
topics. In a similar vein I’ve found a game called ‘Speedboat’³⁴ is quite
good for focusing the discussion on what is holding them back. I’ve
also used the Liberating Structure ‘TRIZ’³⁵, to help people to bring up
issues that might otherwise be taboo. For a smaller group I might just
ask open questions and see where the discussion goes.
In a remote session I’ve done a kind of lean-coffee variant using a
shared online document (eg a Google doc or a One Drive Word doc
or a Miro whiteboard etc) to gather issues. I give them 5 minutes in
silence to write their top issues separately on their own computers.
The question I ask is something like “What are the main technical or
code-related difficulties you experience in your team?”
When the time is up I ask them to paste their lists into the same shared
document. At the same time I add in a pre-prepared list that covers
many of the problems I often see.
Example prepared ‘common problems’ list:
• Time pressure - no ability to reflect, learn or improve the way

we work
³³http://leancoffee.org/
³⁴https://gamestorming.com/speedboat/
³⁵http://www.liberatingstructures.com/6-making-space-with-triz/
• Excessive co-ordination with other teams - loads of meetings

and writing detailed documents
• Other teams mess up our code - they break what we build
• We do hardly any coding - at least nothing you’d need TDD for
• Our junior team members are idle while our senior team mem-
bers are too busy
• We spend a lot of time doing code reviews - pull requests rarely
get accepted the first time
• We have a lot of bug reports and incidents and it takes up all our
time
• Our managers think we are too careful and slow and accuse us
of “Gold Plating”
• We have too broad and diverse a codebase to look after and we
never get to know any part of it well enough to be productive
• The quality of the code and tests is low and we are afraid to
change it in case we break it
• We are working with outdated tools and technologies which is
demoralizing and slows us down
• We are working with cutting-edge tools and technologies which
are unstable and change to quickly
I give them a few minutes to read the combined list and put a vote
marker (+1) next to their top 5 issues. Once everyone has voted, we
spend a few minutes working out if two or more issues are actually
the same one and should have their votes added together. Then we
pick out and highlight the three or four issues that got the most votes.
We take a 5-10 minute timeboxed discussion on each one.
Your aim here is to give everyone a chance to speak so you can better
understand their situation. Depending on what you hear, you can
adapt the focus of your coaching. You may discover problems you
can’t solve, and will need to take up with other coaches or managers.
Hopefully though, you will discover that there are some problems
that you will be able to help with.
Takeaways
At the end of this first session, hopefully you will have gathered:
• everyone’s names in a format you can use to learn them

• a sketch of the architecture
• information about the build, test and deployment process
• some insights into the code
• notes about the main problems facing the team from their
perspective.
After you close the session and the team leaves, spend a few minutes
updating your notes with what you’ve learnt.
Tip: organize your notes by team

I find it useful to have a physical notebook for each team
I work with, where I store all the notes I make when I
meet them. I also keep a matching coloured plastic folder
containing the paper with all their names on from the
‘introductions’ part of the first meeting. During ensemble
sessions, I take out the coloured folder and notebook for
that team and have them in front of me during the session.
I can quickly glance down to remind myself of people’s
names, or check over my notes about previous sessions.
When you begin working with a new organization, there
is a lot to take in, and I find it really helps to have written
notes. Other coaches I know use an online spreadsheet
with a sheet for each team. Whatever works for you.
Chartering Workshop
People generally don’t like having help forced onto them, and you
can’t assume that you know better than they do what they need. The
kick-off workshop should have given you enough information that
you can tailor your coaching for the situation, and offer each team
something valuable to them. Coaching Chartering is about making
an agreement between the coach and the team about the aims and
contents of the coaching. It’s similar to Project Chartering³⁶.
³⁶https://www.agilealliance.org/glossary/project-chartering
I like to do this as a whole-team workshop a few days after the initial

kick-off meeting, perhaps as much as two weeks later. It could be a
few days or weeks before the actual coaching is scheduled to begin.
The purpose is to discuss in more detail what the coaching involves,
and why it would be useful and relevant for this particular team in
their situation. You aim to agree a kind of ‘Coaching Charter’ with
the team. The charter outlines what is expected from both sides and
what you are hoping to achieve. It will always contain some of the
same elements - ensemble working and learning hours for example.
The exact focus will be different for different teams though.
Recap their top issues

In the kick-off workshop, we identified three or four top issues for this
team. This is where you start. Show a slide listing these top issues and
relate them to some coaching areas that you would like to include in
the coaching charter. The rest of the session can be spent explaining
each in more detail and discussing whether they are interested.
Of course if nothing in your coaching is going to be helpful for one
or two of their top issues, be honest and say so. Perhaps they would
like coaching anyway, and you can propose something attractive for
the other top issues. If you can’t address any of their top issues then
perhaps you should reconsider the whole thing.
Structured discussion
I tend to structure a 90-120 minute workshop into sections of about
20 minutes where I present a proposed coaching area with slides and
possibly a short demo. I follow it with a general discussion question.
My aim is to learn whether people seem to understand and like the
suggestions, and whether they feel motivated to take part in the
coaching. For that to happen I definitely need to stop talking, and
regular slides reminding me to be quiet and ask a question helps
suppress my propensity to talk too much! With a team-sized group
of perhaps 4-9 people, everyone should be able to feel they had a say,
were listened to, and have the information they need to make up their
own mind.
Let’s go through some sample section topics and discussion questions.
Team collaboration
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?”
Iterative and Incremental development

All agile software development methods emphasize early and fre-
quent delivery of working software, and this means using iterative
and incremental development techniques. TDD is a way of building
code iteratively and incrementally. Ask “What do you know about
Test-Driven Development? Have you tried it?” Show a quick demo of
TDD on a short kata. Ask “Would your team get any benefits from
using TDD?”.
Code quality and Refactoring

Poor code quality is also known as Technical Debt, and it slows
you down. Refactoring is what you do to address this problem.
Ask “Do you spend a lot of time reading difficult code?” Demo a
short refactoring, preferably with some nice refactoring tool support.
“Could learning some safe refactoring techniques help your team
improve code readability?”
Test Design
Perhaps you noticed that the test cases they have at the moment
are not very well designed. Explain that good tests will find bugs
without getting in the way of refactoring. You could demonstrate

a few different ways to write the same test case. Perhaps show
a test framework they haven’t seen before. Emphasize you aim
for readable, simple test code that will expose bugs without over-
specifying implementation details. Ask - do your tests get in the way
when you want to refactor? Are your tests easy to understand and
maintain?
Testable Design
Sometimes the biggest problem getting started with TDD is that the
code is designed in such a way as to make it difficult to test. Perhaps
there is lots of global state, singletons, dependencies on external
frameworks or network calls. Demo - show some code that is difficult
to get under test because of an awkward dependency, and how to
get it tested. Would this team like to learn this kind of technique?
Object-Oriented design principles? Functional design? Refactoring to
Patterns?
Adding tests to existing code

Manual regression testing is not usually the best use of people’s time.
Having some automated tests will almost certainly make it easier to
produce high quality software releases on a more frequent timetable.
Even if code hasn’t been built with testing in mind, there are still
some techniques we can use to get that code under test. Ask “Are you
afraid to change your code in case you break it?”. Demo adding some
unit tests to existing code. Go through the coverage metrics shown
inline in a modern IDE. You could use Approval testing. Perhaps
show Mutation Testing. Ask “Would this technique be useful on your
code?”
Offer Samman Coaching

Towards the end of the chartering workshop, or perhaps in a follow-
up meeting afterwards, make it clear they have a choice. You are not
going to force them to take part in coaching. You’ve shown them some
short, inspirational demos with shiny tools and techniques they may
not have seen before. You’re being friendly and open and listening to
them. It ought also to be clear they’ll need to put in some time and
make an effort to learn new things.
This is a chance for everyone to be involved in deciding the exact
coaching areas for their team. This affects which learning hours you
plan as well as what kind of programming task you choose to do in
the ensemble sessions. Write down a summary of what you agree on
a single slide or flipchart paper.
I hope the team will happily agree to Samman Coaching because they
want to do this. They are intrigued and they want to learn. Everyone
understands the goals and most important activities of the coaching.
Persuading Reluctant Teams to be

Coached
In many organizations I’ve worked with, my sponsor has arranged
in advance which teams I should coach, and those teams have been
fairly happy to go along with it. In other cases, teams have been
reluctant. Since much of the sales process before the consulting
engagement is focused on managers and people with budgets, it
can happen that you arrive in the organization then realize the
developers are not nearly as keen on coaching as the managers you
met beforehand.
The two initial workshops are designed to get the developers inter-
ested and even enthusiastic about the coaching. You get a chance to
find out about their situation and what kinds of skills they would
benefit from learning. However, you might discover more than you
bargained for! If the developers either don’t turn up to the meetings,
or they are present but hostile or skeptical or apathetic, then you
clearly need to re-think.
Be prepared to postpone the start of learning hours and ensemble
sessions. Use the time to find out as much about the situation as
possible. You need to tailor your coaching and come up with a better
plan. In the following sections I’ve outlined some team situations I’ve
come across and a little about how I tackled each one.
Note: not all of these were shocks on the first day of a new assignment.
On many occasions the manager warned me in advance and/or it
wasn’t the first team I coached in that organization. Ideally you would
be looking out for these kinds of difficulties and anticipate the best
way to approach a particular team.
We are too important

Only half the team turned up to the kick-off meeting, which was a
warning sign I should have taken more seriously. This was before
I had begun doing a formal proposal workshop so in this case I
just carried on and began the ensemble programming. Unfortunately
still only half the team came. After a few days of this we stopped
programming and started talking in more detail about their situation.
The people who had come to the meetings were the more junior team
members. They were actually quite depressed about their team. The
more experienced people were largely refusing to speak to them, they
were so busy writing code by themselves. The team had important
deadlines coming up, and the more junior people didn’t know enough
to really help. The more experienced people were doing everything
themselves rather than slow down to explain anything to them. They
certainly didn’t have time to come to coaching sessions!
We paused the coaching for this team and I spoke to the sponsor about
the situation. He agreed we should try again in a few months when
the situation with deadlines was resolved. That eventually happened
with a much better result. A large part of the coaching is about
building up the team and strengthening their collaboration. It would
have been wrong to continue with only half the team present.
We already know TDD, we’re too advanced

for your coaching
This team was polite but firm. We already know TDD. The learning
hours we heard the other teams are doing are beneath us. We actually
design test frameworks for the rest of the organization to use. We
know all about test design, refactoring and design principles already.
I was skeptical, I’ve heard those kinds of things before. This team
agreed to come to a kick-off workshop and kindly showed me some
of their test cases and code. I found myself by agreeing with them
- it was good! My standard learning hours would have been boring
for this team. I also asked about their teamwork, and although they
worked very well together as a team, they had not done anything
together as an ensemble.
I presented a proposal to them - that we could work together doing
TDD (like they usually do) and learn ensemble programming too. For
the learning hours, proposed I should design some new ones for them.
We could study Approval Testing, Property-Based testing, using code
coverage and other legacy code techniques. We could learn a modern
test framework they hadn’t used before.
Happily, they liked the proposal. I also had to talk to the sponsor
about it and get their approval. I had to hold the learning hours with
this team only, not together with any other teams. I also needed
time to prepare some new learning hours. My sponsor agreed that
I could spend billable time on these extra learning hours and doing
this additional preparation. I believe everyone was happy in the end.
I certainly enjoyed working with such a competent team.
We aren’t writing any code, just configuring

in yaml files
I knew there was one person on this team who was already keen on
TDD. He told me he would like to spread this practice to the rest of the
team, but that they were not keen on being coached. The excuse they
gave was not so much that they didn’t want to learn TDD, but mostly
that they weren’t writing code, only yaml files. In their situation they
didn’t think TDD would be useful.
Rather than scheduling a coaching intro meeting with the whole team,
I tried to get to know the one TDD enthusiast a little better. We set
up some pair-programming sessions so I could see the kind of coding
problems this team were facing (and so we could have fun doing TDD
together). We did find a small problem to work on that was relevant
to the team and which we could do with TDD. However, it became
clear that the team’s assessment was correct. Their biggest job was
configuring a large Kubernetes system. They spent their days fiddling

with hundreds of yaml files and writing documentation.
We decided to wait with coaching this team until they had some more
interesting tasks to work on. I didn’t see a good way to do TDD in an
ensemble in their situation.
It’s impossible for us to write unit tests

This team was in the middle of a big job to migrate some 30 year
old legacy code from one compiler to a newer one. They had been
working on the migration for 6 months already and anticipated they
had over 6 months more to do. The code they were working with was
difficult to understand and change. They didn’t see that TDD was
relevant to their work - adding unit tests to the code was too hard.
They generally relied on experience, encyclopedic knowledge of C
and the ability to decipher compiler errors rather than feedback from
tests.
I suggested we should focus the coaching on learning safe refactoring
techniques and ways to add unit tests to difficult code. They were
curious whether I knew any techniques that would actually work in
their situation. I focused the learning hours on Refactoring and test
design rather than building new code with TDD. In the ensemble
we found a corner of the system to work in where we could get fast
enough feedback from the build to do unit testing, and wrote some
tests for some existing code.
It turned out the coaching went very well with this team. I did have a
few techniques up my sleeve that they hadn’t seen before. They found
the ensemble programming more helpful than they expected. Some
of the team members were much more experienced than others and
they were open to learning new ways to transfer expertise within the
team. Overall the coaching was a positive experience.
Persuasion Principles
Hopefully these stories have illustrated some guiding principles:
• Listen to concerns and take them seriously

• Find out more about the code they are working on

• Find out more about the teamwork and relationships
• Offer to tailor how you coach depending on what you find out
• Involve the sponsor/manager in any decisions
• (Perhaps) accept rejection gracefully and move on
• (Perhaps) wait for a better time and try again later
• (Perhaps) the tailored coaching will be a huge success for you
and the team
Practicalities Before
Coaching Begins
Once the team has accepted your coaching proposal, you’ll want to
sort out a few practicalities in advance of the first session.
When should we hold the coaching?

It might be a good idea to talk to the team’s Product Owner or
whoever co-ordinates their planning meetings. There might be some
dates to avoid because of other priorities. Remind everyone they
should not expect quite as many tasks to be completed during the
coaching period as usual. The team should have some time and energy
available to devote to the coaching.
Agree some dates to book in the team calendar. Find out what time of
day would suit to hold the ensemble work and learning hour. When
do people arrive? When do they usually leave? Also take into account
company events and public holidays. Be as accommodating as you
can.
What task should we work on in the

ensemble?
At the team’s usual planning meeting, the one immediately before
the coaching begins, the team will need to reserve a task to work
on in the ensemble. It shouldn’t be necessary for you to attend this
meeting if you have prepared them for what kind of task that should
be. (Anything to avoid actually having to go to that meeting! I find
sprint planning and in particular estimation just deadly).
Ideally, this task should be one that the team was going to work on
anyway. Perhaps not the highest priority task or anything with a
Practicalities Before Coaching Begins 129
deadline - you want the freedom to go slowly and learn rather than
feel pressured to finish it. Pick a task which involves writing code,
adding new functionality or improving existing functionality.
By working on a normal task that the team would have worked on
anyway, you get the opportunity to coach many techniques. You can
start by doing lightweight analysis, perhaps write a failing acceptance
test, then move on to discuss design alternatives and then write the
code using Test-Driven Development. You can coach the team to take
small steps, commit often, and get feedback from the product owner
or customer representative.
Alternatively you could invent a new task to work on specifically in
this ensemble coaching. You could decide to improve some existing
code. This should be in a piece of code they anticipate needing to add
functionality to, or which is notoriously buggy. You can add test cases
and do preparatory refactorings.
The team may be well aware of their worst class or can point out
a difficult method that they need to change. If they don’t have a
concrete suggestion for which particular bit of code to refactor, there
are analysis tools that can help you. For example something like
SonarQube³⁷ or CodeScene³⁸ can statically analyse a codebase and
produce a report revealing the biggest code smells and hotspots of
questionable design. It could be a good use of your time to teach
the team to use one of these tools to analyse their codebase, before
starting on the refactoring.
What physical space should we use

for ensemble working?
If you’re coaching in person, you need a good space for the ensemble
sessions. The absolute best thing would be if you could set up a
suitable space in each team’s normal working area, close to their
desks. I haven’t seen any organizations yet who have been willing
to invest in that before I arrived, although some have done so after I
had been with them for a while.
³⁷https://www.sonarqube.org/
³⁸https://codescene.io
A team ensemble working space consists of a long desk in front of

one or two very large screens. For a larger team, both screens show
the same - everyone needs to get a good view. Sit comfortably close
to one another in a large semicircle. Everyone can have their own
keyboard and mouse when it’s their turn to type. Alternatively you
pass a keyboard around when you switch typist, together with hand
sanitizer.
Furniture configuration for Ensemble sessions
Often you do ensemble sessions in an ordinary conference room.

I bring a full size keyboard and mouse with me, and one of the
team members brings their laptop. Sometimes they bring their own
mouse and keyboard too. You really don’t want to be using a small
laptop keyboard and touchpad if you can avoid it. The keys can be in
unfamiliar places and potentially only one person present is used to
using it. When you switch typist there will be mistakes and inaccurate
typing.
The best I’ve had so far has been a large meeting room with movable
tables, booked full time for my entire visit. Each team joined me in
that room for their ensemble sessions and learning hours. I enjoyed
having full control over the configuration of tables. I put the chairs in
a semicircle in front of the screen and prepared a spot for the typist
where they are sitting facing the screen.
In some meeting rooms you can’t sit the typist facing the screen
because the fixed table is too long and oriented so the only spot facing
the screen is right at the back of the room. In that case I’ll put the
typist much closer to the screen, sideways on to it. It’s important that
everyone is close enough to the screen to read the code on it. For two
hours a day for a couple of weeks, you can handle the twisted neck
you get by sitting side-on to the screen. It’s not a long term solution
though.
Should we use a branch for the code

we write in an ensemble?
You should probably use whatever branching strategy the team
already uses. Many of the teams I work with have a process based
on feature branches and pull request/code review before merge to
trunk (also called master, main). In that case I suggest the ensemble
works in a feature branch. It makes it easy to pick up where you left
off in the next session.
Research shows that trunk-based development is more effective than
other branching strategies. If they already do that then you should
continue doing that when working in the ensemble.
Syncing with trunk frequently will in general reduce the pain of merg-
ing. With a pull-request workflow, integration can get delayed and
syncing can become burdensome. You’ll probably want to encourage
them to merge often when you’re working together in an ensemble.
Send a pull request as often as you can, when the tests are green. You
could get someone in the ensemble to approve it straight away. You’re
aiming to change habits and make it normal to push to trunk at least
daily.
Turn Up the Good
After each set of 10 coaching days you will have some time away from
the teams and can reflect yourself on what happened. It might also
make sense to send participants an anonymous feedback survey. As
well as asking whether the coaching met their expectations and what
could be improved, you could ask if they have noticed any concrete
outcomes. Are they collaborating better as a team? Are they writing
more unit tests?
Be sure to discuss with your sponsor about how things have gone, too.
They might have heard feedback from the team or other managers. If
things have gone well, can you put your finger on why that is? Is
there anything in particular you should do more of?
Woody Zuill introduced me to this idea of “Turn up the good” in
retrospectives. Don’t get bogged down discussing all the things that
are going wrong. Get everyone to think about what was good, what
was great, and what was amazing. How can we make the good
great and the great become amazing? It’s the same thing with your
coaching. How can you turn up the good?
If the team you are working with has regular retrospectives, see if
you can get yourself invited to one. Hopefully they’ll be willing to
discuss and reflect on the coaching as part of the agenda. Otherwise,
see if you can bring in someone to facilitate a retrospective just on
the coaching. It’s really useful to have someone else facilitate the
discussion so you can take part.
Decide on the next coaching

Together with your sponsor and possibly a team lead or manager,
you will discuss whether another round of ten coaching days would
be valuable. In the original sales process with a new organization I
recommend starting with two blocks of ten coaching days. After that
Turn Up the Good 133
you will hopefully find the teams and the organization would be open
to more.
Enquire about bringing in a visiting

coach or two
There are lots of great coaches in the world and we all have different
strengths. A visiting coach will inject new ideas and ways of working.
I’ve experienced it being very valuable both for the ‘home’ coach as
well as the visitor to collaborate. Perhaps now the organization has
seen you in action they would be open to expanding the programme
to include more coaches?
Networking
As a consultant, the most important thing is that they like you. It’s
good to be friendly, and not just with your sponsor and the teams you
are directly working with. If you’re going to keep a steady stream of
new teams and organizations booking your services, you need to pay
some attention to networking.
Networking means deliberately getting to know new people and mak-
ing new business contacts. It’s about sharing information, contacts
and experiences. Perhaps you can help one another discover opportu-
nities or decide to embark on a shared venture. As a consultant, your
network is a crucial asset for finding work. It doesn’t just happen by
itself. In this section are some ideas about how to cultivate yours.
Lunches
Before covid-19 hit, I would recommend taking lunch with different
people each day. Get out of the building, be friendly and get to know
people. If you’re at an office working with development teams, there
are likely all kinds of other people around too. Be friendly and find
out who they are. Perhaps your sponsor can introduce you to other
managers, other coaches, other TDD enthusiasts.
Invite these people out to lunch one-on-one. Most people are flattered
to be asked. Just explain you’re relatively new to the organization and
trying to get to know more people. If you’re just two people eating
together it’s a better opportunity for a good conversation than in a
larger group. People open up more if it’s just one other person present.
That’s another reason to get out of the building, too. People are often
more relaxed if their colleagues are not sitting at the next table.
With the pandemic lunches are not so straightforward, you might
need some other tactics.
Strategic phone calls to expand your network

It’s useful to understand a little about the power structure of the
organization you’re working with. You can ask your sponsor to help
you to identify good people you should get to know. It’s in their
interest too that you understand the wider organization not just the
teams you’re currently working with. Get some names and phone
numbers. Keep a sketch of your own of the hierarchy and where
everyone fits in. You could even use a CRM (Customer Relationship
Manager) to keep track of people.
It’s not nearly as fun as asking people to join you for lunch at a nice
restaurant, but you can phone people and talk. A video call is better
than audio only. Make it clear who you are and why you’re calling -
your sponsor suggested it (if they did) or perhaps you wanted to ask
their opinion about something or just find out if they knew about
your work. Be friendly, be nice.
Keeping your sponsor involved

While you’re working with a particular team it’s useful to keep your
sponsor and other managers informed about what’s going on. Your
sponsor is the person who makes sure there is a budget to pay you, so
it’s important they feel they made a good choice.
I’ve tried a few things:
• A short daily email sent to the sponsor and the team’s direct
manager after the coaching day. I write 2-4 sentences describing
highlights and what the team has learnt
• A similar email sent weekly and slightly longer.

• A 30 minute meeting one-on-one every 2-3 weeks
• Speaking for a few minutes at the sponsor’s weekly status meet-
ing when the teams are all present. I explain a few highlights
about what we’ve been doing.
• Attending the team’s daily morning stand-up meeting where the
sponsor is often present. I say a few words about what’s going
well.
The aim is partly to remind your sponsor that you exist, that you’re
doing useful work, and that it was worth hiring you. More impor-
tantly, it gives them a chance to celebrate the successes with you,
and feel they are a part of them.
Other coaches
All the coaches working in an organization should talk together
regularly, so they can help each other and try to steer in the same
direction. (In the same way as other specialists from different teams
get together in a Community of Practice)
Days Spent Away from the Teams

Some days you spend away from the teams and the organization you
coach. These days are useful for the teams because they get to apply
what they have learnt - to try their wings without your guidance.
This is the real test of whether your coaching was any good. Do they
continue with the new techniques when you’re not there? Do they
at least think about using them and report back what they struggled
with when they tried?
Being away from the teams is useful for you too. You can prepare
learning hours, practice your skills, and learn new things for yourself.
As a coach, you need this time to stay at the top of your game, and
to be ready when you go back to the organization and coach some
more.
If you’re working on the schedule I mentioned before, with 10

coaching days spread over 3 weeks, then you should get a day or two
each week to yourself. If you need to travel a long way to your client
then that might not be the best choice. Other coaches I know will do
10 coaching days in 2 weeks then spend the third week at home.
When you come back you can ask the team whether they used any
of what they learnt while you were away. It might not happen the
first few times, but hopefully over time they will report a shift in
behaviour. I remember one team who really got good at ensemble
working while I was away. Others have not touched any of it. Be
kind in either case. There is always more to do and more to learn.
A Career as a Samman
Technical Coach
I learnt many of the coaching techniques presented in this book by
pairing with a more experienced coach, Llewellyn Falco. Since then
I have pair coached with others and spread knowledge about these
techniques by doing them together. I recommend pair coaching as an
excellent way into a career as a technical coach.
Pair Coaching in a larger organization

If you are working with a medium to large organization with many
development teams, it could make sense to be more than one technical
coach so you make a bigger impact sooner. It’s also a good way to
bring an inexperienced coach up to speed.
It will help both of you if you work with the same teams at the same
time at first. You want to be able to help one another and get to
know the organization. Prepare the learning hours together, and co-
present them. In the ensemble sessions, take it in turns to take the
coach/facilitator role. The other person can join the rotation and take
part in the ensemble the same as any other team member. If you don’t
feel confident to do that straight away, take a silent observer role until
you do.
Take some time each day to discuss together in private what’s
working well and what you want to improve. This is a crucial element
for getting the most out of pair coaching. You have to get private
feedback from one another.
After the first coaching block of 10 days, assess whether to continue
working like this or whether to split up and each coach your own
teams. Another variant is to facilitate the ensemble sessions sepa-
rately but bring all the teams together for a joint learning hour that
you co-host.
A Career as a Samman Technical Coach 138
A Visiting Coach Programme

When a technical coach has been working with a client for some time
they may feel confident enough to start a visiting coach programme.
They invite various different coaches to join them and pair coach
some teams in that organization. Each coach stays for a block of 10
coaching days with the same teams. A different coach visits for the
next block with the same or different teams. Over a period of months
you will host half a dozen or more visiting coaches.
The host and the visitor will learn new coaching techniques and
exercises from one another, but more importantly the teams being
coached will get a greater variety of experience and opportunities to
learn. The client organization generally pays the visitor at the same
rate as their regular coach. Everyone’s a winner!
If you are invited to join a coach at their client, they are offering you
a valuable gift, and placing a great deal of trust in you. They will have
sold your services to their client, and prepared a programme for your
visit. You should expect to teach perhaps 7-8 of the 10 learning hours
that will happen during the visit, and spend some time preparing
these. Otherwise, bring the best of yourself and be prepared to learn
fast.
Preparing for a Technical Coaching

Career
A Samman technical coach is going to be teaching and mentoring
developers, so to do this job, you need a background as a developer
yourself. You should be a competent software developer with expe-
rience building production code and automated tests. If you’re not
comfortable doing agile practices like Test-Driven Development and
Refactoring yourself then you will struggle to coach others in these
skills.
In addition to coding skills, a Samman coach needs excellent people
skills. As a developer you also need many of these skills but you may
not have identified and practiced them as much.
There are lots of ways to learn and improve as a developer. Engaging

a Samman technical coach to work with your team is one of them of
course! If you have the chance to be coached that would be a great
help when you start to become a coach yourself.
When you work as a developer in an agile team then you probably
have a Scrum Master or Agile Coach supporting your team. Talk
to them about your ambitions to become a Technical Agile Coach.
There is a lot of overlap with the skills of an Agile Coach. Perhaps
they would be willing to mentor you and pair-facilitate with you on
occasion.
I’d say there is a core of skills you should be comfortable using before
you take the step of changing your career from developer to Samman
technical coach:
• Test-Driven Development and Refactoring

• Software Design with loose coupling and high cohesion
• Continuous Integration (commit and sync many times a day)
• Pair programming, including strong-style pairing and pairing
with a more junior developer
• Designing test cases both at unit level and larger
• Standing in front of a group and presenting about a topic you
care about
• Chairing a meeting and facilitating a retrospective
• Standing at a whiteboard sketching and explaining a design to
your team while they ask questions
• Live code a prepared demo of a coding technique to a group of
your peers
Depending on which skills you feel most in need of, here are some
ideas:
• Start a regular Coding Dojo with your team

• Attend a Code Retreat
• Study books and videos on agile development practices
• Go to agile conferences
• Attend formal training for a Scrum Master or Agile Coach role
• Join a meetup and organize meetings
• Give presentations at an internal Community of Practice or
meetup
Ideas for how to get started

I recommend you to find an opportunity to learn from an experienced
coach in person. So much of what you do in this job is about people
and relationships that it’s best learnt from a person rather than a book.
At the time of writing there is nothing formal available in the way of
Samman technical coach training or accreditation. Perhaps if the idea
takes off that might change in future.
Attend conferences and workshops

Coaches like Woody, Llewellyn and I often facilitate workshops at
conferences and company events. If you get the chance to observe a
coach facilitating a ensemble, take notes and listen actively. If possible,
book some time to talk with the coach one-on-one afterwards, so you
can relate what you observed, and ask questions.
If you’re at a conference or event with open space, perhaps schedule
an ensemble session that you plan to facilitate yourself. Go out of
your way to invite experienced coaches to attend and ask them to
mentor you. Most coaches are friendly people and if they are at the
conference anyway they may be able to help out.
Join an online walk-up ensemble or mob

Since the covid-19 pandemic a plethora of online ensemble and mob
programming sessions have sprung up. Some are publicly announced
and free to attend, others ask for a small fee. Find out about them
through following technical coaches on twitter.
Shadowing
One thing I’ve done with several people is to have them shadow me
for a day as I work. That has helped them to learn how a coach spends
their time, and whether they might enjoy doing this too.
When you shadow a coach for a day at work, neither they nor
the organization they are coaching will pay you anything. They
will expect you to pay your own travel costs, if there are any. The
coach might ask you to pay them for any additional time they spend
mentoring you. In ensemble sessions you will see the team’s code, so
you may need to sign an NDA.
Although I recommend this, whether you yourself could find a coach
to shadow could be tricky. Any coach you approach will want to get
to know you a little before they bring you with them for a day. They
take a certain amount of cost and risk by having you join them at their
client. You should be gracious if they are not willing or too busy.
How I became a Technical Coach

For some years I’ve been teaching Test-Driven Development and
using the Coding Dojo as a forum for that. In 2011 I published a book
about it ‘The Coding Dojo Handbook’. This is a fun and useful way
to introduce TDD and to get good at it.
However, over the years I noticed that although developers can fairly
quickly pick up how to solve a Code Kata with TDD, they struggle
to apply the same method in their production code. There is a gap
in level between exercises and ‘real’ code. It’s more than that though.
The change of habits and mindset that’s needed is difficult to achieve
in a production code situation. You have so many pressures on you
already, it’s hard to work differently.
With that in mind, I had largely stopped doing coding dojos when
in 2017 I received an invitation from Llewellyn Falco to join him at
one of his customers. He asked me to be a “Visiting Technical Agile
Coach”. He offered to show me his coaching method, and teach me
to do it too. I was intrigued by what he told me and felt this was
something I should try.
I wrote about the experience at the time in this blog³⁹. It was like
a revelation. This coaching method was fun and challenging, and
seemed to actually be effective for getting developers to change their
behaviour in production code, not just in exercises. I came home
planning to do more of this kind of work.
³⁹http://coding-is-like-cooking.info/2018/10/effective-technical-agile-coaching/
I realized that I needed to look for a new kind of customer, who

would be open to my working in this style. After a few months of
networking and sales meetings, I found two companies willing to try
it out. Llewellyn was really helpful, we had regular video calls to
discuss how things were going both before and during the coaching
weeks. I find the coaching work continued to be fun and rewarding,
and more effective than any other method I’ve tried for spreading
agility amongst developers.
So now this is what I do. This book is an explanation of what’s
entailed so you could do it too. I think the world needs more coaches
using the Samman method, and that better software will be the result.
Final Thoughts
Before I close, a few last thoughts about Samman technical coaching.
What is the most important thing to

remember?
The most important thing is that they like you. This is probably true
for all consulting. They won’t listen to you if they think you’re a
moron, or a nasty person, or a fake. Cultivating good relationships
can be hard, but it’s crucial.
Where can I find out more?

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 inspiration 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 techni-
cal 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.
I would like there to be a global community of Samman technical
coaches, exchanging ideas and experiences. I’ve started a website
sammancoaching.org⁴⁰ which I hope will become a resource for this
community. At the time of writing, I don’t yet know what this will
⁴⁰https://sammancoaching.org
Final Thoughts 144
turn into. If you’ve read this book then perhaps you’re interested
enough to check out the site and find out what’s happened since the
book came out.
References
In this section I’ve listed some references for where I learnt about
technical agile topics myself. I don’t want to suggest you have to read
any of the books I mention here. There may well be newer and better
things to read these days. This is a selection from my shelves of books
that have made a significant impression on me in my coaching work.
Working incrementally in small steps

• “Test-Driven Development By Example” by Kent Beck.
• “The Pragmatic Programmer” by David Thomas and Andrew
Hunt
• TDD⁴¹ by Jason Gorman
• “The art of Agile Development” by James Shore
Refactoring safely
• “Refactoring” by Martin Fowler - the 2018 edition is a classic
already
• “Refactoring to Patterns” by Joshua Kerievsky which bridges
into the software design topic
Legacy Code
• “Working Effectively with Legacy Code” by Michael Feathers.
It’s still a classic.
• Arlo Belshee has written a lot of useful stuff on his blog⁴², par-
ticularly worth reading his posts about ‘Naming as a Process’⁴³
• I hope to write a book called “Approval Testing”. Watch out for
that one in the next few years.
⁴¹http://codemanship.co.uk/tdd_jasongorman_codemanship.pdf
⁴²http://arlobelshee.com/
⁴³https://www.digdeeproots.com/articles/on/naming-as-a-process/
References 146
Testable Design
• “Practical Object Oriented Design in Ruby” by Sandi Metz.
• “Agile Software Development Principles, Patterns and Practices”
by Robert C. Martin. It describes the SOLID principles amongst
other things.
• “Software Architecture for Developers” by Simon Brown
Designing Tests
• “Growing Object Oriented Software Guided by Tests” by Nat
Pryce and Steve Freeman covers many related topics, but since
they largely invented the idea of using Mock Objects, it’s
particularly worth reading what they have to say about that.
• “Modern C++ Programming with Test-Driven Development” by
Jeff Langr
• “The art of Unit Testing” by Roy Osherove
Behaviour-Driven Development
• The BDD Books⁴⁴ by Seb Rose and Gaspar Nagy
• “Specification by Example” by Gojko Adzic.
Teaching
• “Training from the Back of the Room” by Sharon Bowman
• “The Ten-minute trainer” by Sharon Bowman
• “Using Brain Science to Make Training Stick” by Sharon Bow-
man
⁴⁴http://bddbooks.com/
References 147
Other
• “Accelerate” by Nicole Forsgren et al. She has the data to show
which development practices make a difference. Successful orga-
nizations have a Generative culture and do Continuous Delivery.
Well worth reading.
• “The Phoenix Project” by Gene Kim. A good story with a
purpose.
Image attributions
• movement, passengers, jump, drawing by Adrien Coquet from
the Noun Project
• listening by Ragal Kartidev from the Noun Project
• flipchart by Simon Sim from the Noun Project
• Book by Ronald Cortez from the Noun Project
• Stopwatch by celine labaume from the Noun Project
• Calendar by Shmidt Sergey from the Noun Project
• Cat, Chicken, Teddy Bear by Amethyst Studio from the Noun
Project
• Paper People Cutout by Andrew Koszkalda from the Noun
Project

Techagilecoach

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Techagilecoach

Uploaded by

Copyright:

Available Formats

Technical Agile Coaching with

the Samman method

This version was published on 2021-04-07

This is a Leanpub book. Leanpub empowers authors and publishers

© 2019 - 2021 Emily Bache

The purpose of Samman Coaching . . . . . . . . . . . . . . . . . x

Part 1: Ensemble Working . . . . . . . . . 1

Let the Ensemble give you Superpowers . . . . . . . . . . . . . 7

Coaching Behaviours in an Ensemble . . . . . . . . . . . . . . . 11

Kindness, Consideration and Respect . . . . . . . . . . . . . . . 17

Coaching Situations Illustrated with Stories . . . . . . . . . . . 22

Part 2: Learning Hours . . . . . . . . . . . . . 44

The Theory and Practice of Teaching and Learning . . . . . . 53

Sample Learning Hours . . . . . . . . . . . . . . . . . . . . . . . . 64

7. Arrange - Act - Assert . . . . . . . . . . . . . . . . . . . . . 83

Remote Learning Hours . . . . . . . . . . . . . . . . . . . . . . . . 98

Part 3: Samman Coaching Engage-

Beginning Coaching with a New Organization . . . . . . . . . 113

Practicalities Before Coaching Begins . . . . . . . . . . . . . . . 128

When should we hold the coaching? . . . . . . . . . . . . . . 128

Turn Up the Good . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A Career as a Samman Technical Coach . . . . . . . . . . . . . 137

Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Samman Technical Coaching

team collaborates together with the coach in applying agile develop-

Why would an organization engage in

• Good technical practices mean the organization can build new

Why would you choose to coach using

I can’t cite statistically sound research to prove these points, unfor-

Elevator pitch for Samman Technical

Day in the life of a Samman Technical Coach

16:15 Debrief, reflect, write a summary report

What is in this book

• Part 1: Coaching in an Ensemble - why and how.

I have deliberately gone straight into some detail about ensemble

Of course I won’t be offended if you choose to read the parts in

How this book relates to my other

Better unit tests

Safe refactoring in legacy code

Incremental and Iterative Development

Levelling up a whole team together

coaching based on your reputation but soon afterwards they will

That quote is from “Mob Programming - a Whole Team Approach”³

out loud, explaining the development activities they have in mind in

Experience from many ensembles suggests it’s a good idea to ask

Other ensemble roles

The Coach role

Everyone understands the code

Think about this for a minute. If everyone on the team understands

Skills are multiplied

Visitors are quickly contributors

Joining a smoothly functioning

A Coach is a Visitor with an Agenda

• Explain how this refactoring is similar to one they already know

• Step to the whiteboard and explain the new refactoring with a

Take Short Breaks

working without you. One of your ultimate goals as is to make

Breathing space between and during

everyone leaves, take a picture of all the retrospective sticky notes,

Woody’s Legacy Code rule

We want to create a space that is safe. Safe to experiment, to learn, to

Take time out

Too much thinking at the keyboard