We know from the experience of the industry that the techniques promoted by the Software Craftsmanship movement have the potential to increase the productivity of the development teams. Test Driven Development helps obtaining solutions with better design and more stable in a shorter period of time. Pair Programming helps eliminating the mistakes while the code is produced, fast knowledge dissemination in a team and finding simpler solutions. Continuous Integration helps solving integration issues between components fast and without stress. Continuous refactoring helps keeping the code flexibility, so that when the customers ask for unforeseen functionalities, the team can add them very fast.
There is though the other side of the coin. Test Driven Development can lead to tests hard to maintain and to abandon them in time. Refactoring is often understood as "iterations" or "periods" of refactoring, that can go up to weeks, sometimes without any result. Trying to do pair programming can be interpreted as lack of trust for the programmers: "someone will be my supervisor while I write code". Continuous integration can generate a lot of problems when it is applied on projects that have tens of different components, resulting in an arguable return of investment.
What specifically makes the difference between the success examples and the failures? What can lead to a successful adoption?
The answer consists of managing change. Here the coaching part comes into place; in this specific case, because the practices that want to be adopted are uber-technical, we speak about technical coaching.
A technical coach is concerned with several important aspects of adopting a practice:
The technical coach can be from inside or from outside of the company that wants to adopt TDD, refactoring, or event Extreme Programming. Both approaches have their advantages and disadvantages. The internal coach has the advantage of understanding the structure of the company and the projects, but has usually the disadvantage of being part of the system and so it is harder for them to see some things that need to be changed. And external coach has some advantages that need to be considered:
It is sometimes difficult to understand how an external technical coach can become productive very fast in a team with a completely new application. Sounds magic, right? The explanation is in fact simple: the technical coach does not need to understand the business and all the internal details of the application. The product of the coach is the team; the team makes sure they understand the application and the business. The technical coach relies on the solid knowledge about the practices that will be adopted and on architecture, design and code patterns, but also on human interaction to bring the entire team to a higher level of productivity. The coach cannot work without a team, in the same way as the software product cannot be created without a team. Only through tight collaboration with the team, by having discussions, honest and continuous communication, through trust and mutual respect, the coach can help the team adopt a new practice.
Until now we have discussed about adopting one new technical practice inside a company. On the individual level, the things are similar but much simpler.
A motivated programmer that has the necessary conditions can learn alone a new practice. Using individual practice techniques like coding kata or having pet projects is recommended, together with following web resources (ex. http://katacasts.org) and reading two or three recommended books on the subject. Further on, everything resides in the tenacity, willingness and self-motivation. Attending coding dojos, code retreats or technical conferences is useful to keep the motivation. Pair programming with chosen people is another way that can be applied to continue learning.
Not all the developers, though, have the will and the necessary self-motivation to sustain this process. For them, a technical coach is one of the means to reach their purpose of learning a new practice by:
On the individual level, the coaching activities are very similar with those of mentorship or with the craftsman - master relationship. A technical coach helps you to identify and reduce the impediments more than a traditional mentor. The typical impediment declared by the programmers is the lack of learning time, that can be easily solved by short learning sessions each day (30-45" per day), better planning or more intense but less frequent sessions (ex. pair-programming, coding dojos or code retreats).
It is worth explaining the role of pair-programming during the learning process, because it is fuzzy sometimes. Pair-programming can be used in production, with the purpose of learning the project and to prevent coding mistakes. In the context of adopting a practice, pair-programming can be used as a means by which the technical coach passes the knowledge related to a certain practice (for example Test Driven Development) to the programmer. To apply pair-programming in production, an adoption period is needed as well, and adopting pair-programming is done by pairing session between two programmers under the supervision of the technical coach. While the programmers focus on solving the problem they work for, the coach will focus on the interaction between the two and on eliminating the communication problems and the inefficient discussions. So there is a major difference between adopting pair-programming, using the technique in production and learning other techniques by using pair-programming. The technical coach needs to master very well the pairing techniques in order to succeed in sending the necessary information even to those programmers that have never done pair-programming, but want to learn one of the techniques described above.
In conclusion, a technical coach manages the adoption process of one or more technical practices on individual, team or 2-4 teams level. The expertise of a technical coach can make the difference between success and failure when a company or a programmer wishes to adopt practices like unit testing, TDD, incremental refactoring, improving design, minimizing the issues for existing code that is hard to understand, etc.
The coach can be internal or external to the organization. The advantage of an internal coach is that they are familiar with the organizational context and applications, but has the disadvantage of limited experience and belonging to the system. An external coach has the advantage of being part of tens of projects with different constraints and needs and can look at the organization with a fresh view, outside of the system. The external coach needs to understand just briefly the business needs of the application and trusts the team with the specific details of the project. The product of the technical coach is the team; a team that learns new techniques, that they can apply directly in production with trust, succeeding in the same time to reach their business objectives. The tight collaboration between the technical coach and the team, based on mutual respect, communication and honesty is the main success factor of the adoption. After the initial coaching period, the team has the necessary means to continue the learning, the coach having only a support role ("the voice of the conscience").
So think what you miss every time when you are saying you do not have enough time to adopt a certain practice. Maybe you lose customers, opportunities, innovative potential, a better job. A technical coach can help you decide which practice is useful in the context of your business and your existing applications and can help you adopt the practices that will help you reach your potential.