Coaching Technical Practices

About me

In the past 4-5 years, I have been working as software development coach, helping organizations improve their technical practices.

I found myself working as a coach by chance. In the beginning, I panicked a bit. I had never done this before. I had run isolated sessions on TDD and Software Design but never had to organize a program in a logical sequence.

My first challenge was choosing the subjects of the program.

What subjects?

After a few iterations on the course materials, I focused on coaching around XP practices, specifically TDD, Pair Programming, Refactoring and Simple Design.

As I got more experience, I was able to break the practices into more fine-grained subjects.

My goal was to find a path as smooth as possible to avoid big learning jumps. Another goal was to find subjects that were programming language agnostic. Some subjects are heavily biased towards an object-oriented paradigm as most organizations I've worked use the object -oriented paradigm. Below is my current breakdown of subjects:

• Pair programming
• Driver-navigator
• Ping-Pong/Popcorn
• Chess clock
• Pomodoro
• Pair Rotation

pair programming cheat sheet

• TDD
• Classic TDD
• Outside-In (Mockist) TDD
• Test Doubles

• Transformation Priority Premise

• Refactoring
• IDE Productivity
• Refactoring smells

• Refactoring legacy code

• Simple design
• Object Calisthenics
• Code smells
• The four elements of simple design

• SOLID

In what order?

Through the years I kept making experiments in the order of subjects as I got more feedback. I now reached a point where I'm no longer making significant changes to the order.

This does not mean that I always use this strict order. In some circumstances, I find it beneficial to make adjustments on the fly. Sometimes I work with people that need a preamble session on object-oriented concepts. I also have a session on design patterns that I sometimes use. Another optional session is on domain driven design

I struggled to find an order that does not require big jumps, but at the same time avoids adding material that is not put to use in subsequent "modules".

Test doubles appear quite late for this reason. I used to introduce them way earlier. However until Outside-In-TDD no other module heavily requires test doubles, so there is no point in addressing this too early and then leave it dormant for an extended period.

Below is my current order of subjects:

1. Object-Oriented fundamentals (optional preamble session).
2. Pair programming.
3. Classic TDD.
4. Transformation Priority Premise.
5. Object Calisthenics.
6. Refactoring techniques.
7. Code Smells.
8. Legacy code.
9. Four elements of simple design.
10. SOLID Principles.
11. Test Doubles.
12. Outside in TDD.
13. Design Patterns (optional).
14. Domain Driven Design introduction (optional).

Once I had the order of subjects my next goals were finding exercises for people to practice. Practicing is crucial. Information only is not very useful. Applied knowledge equals mastery. Deliberate practice is the key to achievement.

How long?

"We are what we repeatedly do. Excellence, then, is not an act, but a habit." Aristotle

In my early days of coaching, I tried to run sessions by pairing with people on their working tasks. I found out that people got frustrated with this approach because they would lose velocity on their tasks and not all tasks were the most suited for the material we were studying.

Attempting to sort this frustration I tried to use publicly available code katas. This worked better, but because we were still pairing on peoples desks interruptions were a problem. My solution was to take them to a quiet place away from their desks and work on the exercises with me.

Later on, I tried to work with a pair of developers instead of doing a one on one coaching session. I found this format worked better, probably because people learn from each other and not just from the coach. Later I experimented with mixing people from different teams to create pairs. I tried this to see if it would improve communication between teams, it worked better than expected.

I have used many exercises in the past; some worked some didn't. In the next table, I present the ones, I realized, work well in mastering the practices.

I only run the optional sessions if there is time left and I feel the pair is ready for it. As for the preamble, I only run it if I feel the need for it.

While discussing with a fellow coach, he pointed me in the direction of Bloom's taxonomy. This is a model used in education to set learning objectives according to levels of complexity.

The model defines six levels of objectives: Remember, Understand, Apply, Analyze, Evaluate, Create. When I apply this model to technical practices, I make sure people achieve at least the apply level.

I always stay in a subject until people feel comfortable applying the specific practice. Just remembering and understanding a practice is not enough. I try to resist the temptation to allow people to learn only at an intellectual level and consider a practice learned only when people apply it correctly.

Scenarios

In my work as a coach, I face several challenges. In this section, I describe the most frequent ones and how I deal with them.

Scenario I - "I don't need to learn/improve practices."

I usually get this from more senior developers. If they believe they are not ready for coaching sessions, I do not push. Coaching should be a pull not a push. I work with anyone on the team eager to learn and work with me. Over time they start spreading what they have learned and usually people that were not so eager to participate become more inclined to do so. This strategy has worked very well for me.

Scenario II - "I want new information, don't make me practice"

I believe very firmly that information without practice is of little value. I make sure to explain this very clearly. If someone refuses to practice and wants to focus on information, I refuse to continue. I never actually had to go to this extreme. At some point, people realize the importance of deliberate practice. Sometimes I challenge people to show me what they can do with the new information. Another option is to start the exercise and gradually pick their interest.

Scenario III - "I don't want to pair"

This usually comes from the fear of exposing one's weaknesses. As a coach, I need to work around this fear. I make sure I convey that coaching is a safe environment to learn. Often in the opening session, I make some silly mistakes or expose my ignorance on a subject to make others more relaxed regarding exposing their technical weakness points.

As a coach, I also pay attention to how to create groups. I try to avoid having power dynamics in pairs, so I usually form pairs from different teams and try to create pairs at the same experience level. I found out that it's easier to pair with a stranger in a coaching scenario.

Scenario IV - "How do I measure the success of coaching sessions?"

My usual answer to this question is: how do you measure quality? It's entirely subjective.

Even if there is no way to measure it in the short term, I did notice some side effects in the medium term:

1. There is a correlation between people completing the program and job promotions;
2. The noise level in teams increases;
3. The amount, length and focus of the discussions coming out of teams before and after the coaching increases;
4. Discussions are more focused on design and less on new technologies, products and shiny toys in general;
5. People start caring and sharing more;

Case V - "I want to understand these practices, but I cannot write code."

I have had a few people interested in learning the practices, but they were not software engineers, or they had written code so long ago they forgot how to do it. In this case, I perform the exercises myself making sure they understand what I'm doing step by step. Some finally start to do the exercises, some never, but all leave understanding the materials at a much deeper level.

Performing the same exercise before adding new material and after

This technique works wonders. I ask the pairs to do an exercise on their own with no help from me on the implementation. I only clarify requirements. I usually tell them I'm not going to look at the outcome.

After the first iteration, I introduce the new material and ask the pairs to perform the same exercise by applying it. I provide help if they struggle. In the end, I suggest them to compare the two versions of the exercise.

Letting go

As a coach, I work towards an exit strategy where people I coach should no longer need me.

As the sessions progress, I offer less and less help, but I am always present to avoid mistakes turning into bad habits. I do let people make mistakes and then offer advice.

In the first sessions, I act as a feedback loop. In later sessions, people should have developed their internal feedback loop.

On the last sessions, I usually leave the pairs alone, offering no help while they perform an exercise. I only provide feedback once the exercise is completed and usually as questions.

Format

I have worked in several formats:

• Run sessions for a few days with a group (I never went beyond 20 people).
• I found this format to be the most challenging.
  • It's difficult to avoid interruptions by people outside the group.
  • It's arduous to find a time and a place suitable for everyone in the group.
  • It's not easy to provide the same level of personalized feedback.
• If I can overcome the obstacles this is probably the most efficient format.
• Divide the group into pairs and work in two 90 minute sessions a week per pair.
• Divide the group into two pairs and work in a 120-minute session a week.

Summary

In this section, I offer some general advice for software coaches:

• People should master the more individual XP practices (TDD, Refactor, Pair programming, Simple Design)
• Make sure they spend time practicing until they reach, at least, the apply level in Bloom's taxonomy.
  • Avoid coaching just at the intellectual level.
• Ideally run sessions with a pair.
  • This allows practicing pair programming and promotes sharing.
• Be flexible. If you work with small groups, you can bend the rules a bit more.
• Constantly work towards creating a very safe learning environment.
• If you set up a program consider using a pull model instead of a push model.
• Explain the learning goals of exercises and keep people focused on those goals.
• Make sure you do not make people dependent on you. Give them more and more space as the sessions progress.
• You wear three different hats as a coach. Usually in the following order:
  1. Teacher. In the first sessions, you are teaching most of the time, filling any gaps in knowledge.
  2. Mentor. As the sessions move on, you assume a mentoring role, offering advice only when needed.
  3. Coach. You let people go on their own. Try to guide by asking questions where appropriate. Don't offer solutions.
• With the years I found out that what is lacking the most in average is software design skills.
• All the practices and disciple mean nothing without good design skills.
  • Simple design is the most ambiguous practice in XP.
  • Spend generous amounts of time working on software design.
  • Give feedback on design issues, discuss alternative approaches..
  • Encourage people to connect the dots on design
    • Object Calisthenics -> Code Smells.
    • Code Smells -> The four elements of simple design.
    • The four elements of simple design -> SOLID.
• Make sure to point out that people should include all other XP practices in their Agile development/culture.
• Point out that teams should not stop in XP practices.
• What practices are they using to find out what to build (requirements)?
• What practices are they using for macro design (architecture)?
• What practices are they using for team dynamics (SCRUM/Kanban)?
• What practices are they using to release software (DevOps culture)?
• Be nice, be patient, "be water my friend" Bruce Lee :)
• Have fun.

I'm writing a more in-depth book on Agile Technical Practices. Follow me on twitter for updates on the book's progress (@pedromsantos).

About the Author

Pedro Santos has over 25 years of experience in software development. In more recent years, he has focused on educating and inspiring other developers. 
He spent hundreds of hours doing pairing sessions, coaching and teaching developers. He has worked with developers on programming basics, object-oriented design, refactoring legacy code, testing practices, architecture decisions and career development choices.