Based on the execution of a successful Transformation, we have demonstrated the increase in quality and reduction of maintenance cost. The next challenge to tackle is how do we scale it? How do we scale it within that team, as the team grows? How do we scale it across teams, across the organization?
Our approach is to optimize team performance (and later organizational performance) rather than individual performance. For this reason, our Technical Coaching uses Mob Programming (and may use Pair Programming until we reach Mob Programming) rather than one-on-one coaching. If worked on-on-one with a developer, the value would be too low - because the majority of the code would not be improved, and the team capability would not be increased. By working in a team context, we are simultaneously raising skillsets across the team, and also helping the team learn how to work together, raising quality consistency level across the team and codebase and helping the team become future Internal Coaches to spread the practices across the company.
Scaling within the team
During the actual Transformation, we used Pair Programming and/or Mob Programming with the intention of already setting up the team for scalability. Indeed, the biggest benefit that organizations have in using Pair Programming and Mob Programming is that they enable knowledge sharing and gaining skills in teaching others. They minimize silos within teams, minimize key-developer risk, minimize single point of failure, increase consistency and increase quality at the team level. The following is a general sequence we tend to use
Pair Programming I: The Coach guides the direction we want to go in, whilst the developer is coding at the keyboard. The Coach aims to guide the developer through questions, rather than providing answers. The developers rotate amongst each other, so that each one has opportunity to work with the Coach. Generally we switch at 30 min intervals, though later we may even try shorter intervals typically 15 min.
Pair Programming II: Afterwards, the Coach guides developers in pair programming with each other, whereby one developer is the Driver, and the other is the Navigator. Over time, a developer will have the opportunity to pair with different programmers, and will have both the role of the Driver and the role of the Navigator. The typical Driver-Navigator interaction is: the Driver is at the wheel, the keyboard, focused on writing the code and getting the code to work; whereas the Navigator is the observer, giving directions and reviewing the code, thinking about the bigger picture. The Coach will allow failure in a safe zone, which means it's ok for the developers to try their best, and then the Coach will interject with additional questions (e.g. something that was missed by the Driver and/or Navigator).
Mob Programming: After having gained practice in Pair Programming, we move on to Mob Programming (see also Remote Mob Programming). We use the Driver/Navigators Pattern (DRVR), whereby the Driver rotates approx every 15 mins. The Driver is doing very mechanical work - focused on typing the code, and listening to the Navigators who are providing instructions at a higher level of abstraction. Since the Navigators are verbally expressing their ideas, this enables team discussion around the ideas. The Coach also takes on the role of the Navigator, in asking additional questions to help the team arrive at even better ideas.
Through this transition, we move from solar work to actual team work, and we've built-in scalability within the team. This means, when a new team member joins, the team is equipped to much more rapidly and efficiently share knowledge, and in building a self-organizing teams. As we've seen above - the team is not reliant on any single authority figure - the Coach is not the authority, the Team Lead is not the authority, but rather the team has learnt collective decision making skills, which leads to far superior results than what is possible in traditional command-control leadership styles. Self-organizing teams are scalable.
Scaling across teams
Whilst the Coach works with one team (or a small number of teams) the question is, how do we scale out the transformation to other teams? How do we build Internal Coaching capability, so that the company does not need to rely on the external Coach in scaling the transformation across the teams. This is especially important to mid-sized and larger companies, in order to build a learning culture inhouse. This is indeed, the most important competitive advantage that an engineering department may have, an advantage which is very hard to replicate by competitors.
Now, during the Coaching sessions themselves, all participants experience what it's like to be coached, so they implicitly observe coaching in action - helping people to unlock answers by themselves, as opposed to providing answers. In particular, this skillset is of value to the Team Lead, as well as the rest of the team, because coaching is far more effective than training, because the coaches themselves discovers answers - unlike training, where they are dependent on the trainer to give them the answers.
Now to scale effectively, the company needs to choose a certain person (or people) who will be an Internal Coach. The typical choice is the Engineering Leader - because unlike the Team Lead who is restricted to one team, the Engineering Leader's role is to increase capacity across the engineering department. Or there can be the choice of another person, does not matter. The key criteria for choosing an Internal Coach:
Leadership: Internal Coach should have capacity to work with multiple teams, they are not operationally constrained to one team. In most organizations, this corresponds to an Engineering Manager level position (not a Team Lead position) because the Engineering Manager spans multiple teams and their goal is to raise performance across teams.
Technical Expertise: Internal Coach should have already have some background in TDD and/or Clean Architecture and/or Clean Code, and has learnt any of these technical skillsets through our Transformation of one team. We do recommend that the Internal Coach also spend time with the team doing some pair programming as additional practice.
Coaching Skillset: During our Transformation we may interchange roles with the Internal Coach, as well as providing direct feedback to the Internal Coach. Some feedback we may give on-the-spot, other feedback we may provide through additional sessions with the Internal Coach (we provide Management Consulting sessions for Engineering Leaders whereby we can provide them with feedback regarding their performance as an Internal Coach and what to improve).
The Internal Coach then needs to be assigned to coach teams. We may be present during those sessions, whereby the Internal Coach has the spotlight and we are in the background in order to observe and provide feedback. This model may be scaled out by engaging several Internal Coaches, and adopting the "Coach the Coach" approach, whereby our focus shifts towards helping the organization build a strong coaching capability so that they can scale out technical practices across the company.
The outcomes of scaling transformations is to achieve:
Building high-performance engineering organizations with a culture of technical excellence
Growing Internal Coaching capability so that engineering leaders can unlock the potential of their teams
Increasing software quality, accelerating delivery and reducing maintenance costs across the entire product portfolio
Building collective knowledge, building scalable teams, building strong systems is the biggest competitive advantage, it becomes the organization's DNA