Thread by @ClareSudbery

I really enjoyed @EmilyBache’s talk about her Samman Technical Coaching technique (@CoachingSamman) yesterday at #AOTB21. Here are my notes.

Samman = Swedish, means "together".

An agile journey includes technical agile, and that's the part that the Samman technical coaching method focuses on.

Emily did a survey in the talk (using @Mentimeter) about what makes coding fun. The top choices were:
1. An end product that users care about, and
2. Code that is clear and easy to understand.

"Tech debt = deficiencies in internal quality that make it harder than it would ideally be to modify and extend" - @MartinFowler
Research in 2019 suggested that companies waste 23% of their time due to technical debt.

Iterative and incremental development automatically creates tech debt. There will always be a gap between the design in prod and what you've realised (via user) you actually need.
We can't eradicate tech debt, but we *can* minimise it by creating code easy to extend and maintain.

“Satisfaction and wellbeing correlate with productivity" - Forsgren (@nicolefv) et al.
What you want is developers who are skilled, take pride in what they do, and have a team culture of creating excellence.
If you practice TDD, this will have a big impact on that goal.

The Samman technical coaching method consists of
1. Daily learning hour
2. Ensemble working.

The daily working hour is planned and articulated with learning goals, using the techniques from Sharon Bowman (@sbowperson) - Training from the Back of the Room (bowperson.com/sharons-books/).

Emily's coaching website has suggestions for katas and other exercises for a learning hour: sammancoaching.org

The first step in the learning hour will be a short “Connect” activity, to discover what people already know, and connect that with what they’re about to learn.

The learning hour should be a bit like a skiing lesson. You might already know how to get yourself from the top to the bottom of the slope on skis, but not how to slalom. A learning hour might involve people who can already code, but don't yet know TDD.

Learning TDD in a learning hour is like learning how to ski on a smooth simple slope with no obstacles and no other skiers. TDDing in real life (rather than in the artificial environment of a learning hour) is much harder!

This is where the second part of the Samman method - ensemble work - comes in. Ensemble working is another (more positive) name for mob programming.

This is described by Woody Zuill as “All the brilliant people working on the same thing, at the same time, on the same computer.”

Ensemble roles:
- Typist
- Navigator, getting / requesting help from team members
- Team members, providing input
Rotate roles often - it’s a good idea to use a timer. But experienced teams may stop using timer once they're confident in their ability to work together effectively.

The coach will teach the team the ensemble working technique and the basics of TDD, and once they get comfortable with it take more of a step back, just giving extra guidance when needed.

Ensemble working is much more likely to be successful if you start out with a facilitator.

Emily has a training course about good ensemble working techniques.

A Samman coach will have the technical skills and experience of techniques such as pairing and TDD, and also the coaching skills to facilitate teams to learn these techniques.

Part of the process is gaining manager trust - showing the cost of tech debt and the value of TDD.

Another component of Samman is onboarding workshops:
- Gain the trust of the team
- Set expectations
You have to have a good relationship with the team before you start working with them.

The coach will not be working full time with the team.
Coaching comes in chunks of 10 days spread over 3 weeks - typically in half days.
10 days is enough to move the needle.
In the break between coaching sessions, the team can do business as usual...

(although it’s worth noting that the ensemble sessions will also involve working on their day-to-day work - this way, they can learn the techniques in a real-world scenario).

There might also be a break of a few weeks for knowledge to sink in, before another 10-day coaching session (spread again over three weeks).

You can do the coaching remote or on site.
Remote coaching has some benefits and can work well.

User feedback: "We've talked about TDD for years, but these coaching sessions have given us a proper idea of what it actually entails.”
Outcomes:
- Improved teamwork, better collaboration
- More likely to write unit tests
- Committing code more often
- More likely to refactor

“There must be five million makers working under the thumb of Scrum, and most of them simply do not have the skills you need to work effectively in Scrum.” - @RonJeffries

“There is a huge unserved market out there… it seems either to have no money, or not to know that it needs help.” - @RonJeffries

TDD makes coding more fun, and @EmilyBache has been on a mission for a long time to spread that joy to other programmers.

There's currently no obvious career path for a technical coach. @EmilyBache wants to change this!

Emily aims to offer training to technical coaches wishing to use the Samman coaching method.
See @EmilyBache's book, Technical Agile Coaching with the Samman Method: leanpub.com/techagilecoach
Also her website: sammancoaching.org.

I've just realised that I should have mentioned: I already have a copy of @emilybache book, Technical Coaching with the Samman Method, and am thoroughly enjoying it!
leanpub.com/techagilecoach