Update: Thanks to Adrian Perreau (@eidrien) for fixing English mistakes in this post 🙂
I have been visiting many companies since 2009. The experiences I’ve been having as mentor/coach these months are teaching me lots of key aspects of software development teams. I am learning more about us, technical folks. Sometimes I make mistakes, sometimes I apply techniques that are successful. Let’s share them 🙂
To really coach a team from the beginning and make it a real team, you probably have to work with them for 6 months. You can’t change the team in a week. If the team is small, willing to learn and change, and they are already walking the agile journey, then you can do more in a single week. You can help in a short period of time. Right. You can also try it out if you face a team which is starting a sprint and have time to listen (everyone in the team), including product owners.
If all those circumstances are not in place, just act as a mentor, don’t try to coach any team. Don’t even try to coach one by one unless you can help an individual, as a person, not as a team member. Why? Because you just can’t help in those few days. You might open wounds and then not be able to close them because you leave too soon. Or at least, you will disrupt people without any benefit. Specially if you arrive to the team at the middle or at the end of the sprint or they are feeling pushed against a deadline, you will be more an obstacle than helpful. Try to discover who are the guys that are available and willing to be mentored. Sit down and code with them, well, if you are and XP mentor 🙂
When you do pair programming with them…:
- Have a look at the code they have written before you arrive. This will tell you if they need a refactoring session, a redesign session, a TDD session to implement a new feature or a code kata.
- Refactoring session: small refactoring steps to make sure nothing gets broken, running the tests after every refactoring. Just finding better names and removing duplication will teach deep lessons.
- Redesign session: you sit down and don’t understand the code at all, although it does not look that ugly. You redesign the code together to understand it. That would be a big refactoring. Don’t commit the outcome to the repository, you are probably breaking things. The lesson is, how the code can explain the domain itself.
People love conclusions, so if you don’t think the redesign can be done in the time frame you have, avoid it. - Development of new features: Test drive the features together. I don’t have to tell you the huge benefit of this, have I?
- Code Kata: None of the previous strategies seem to apply. OK, lets enjoy a code kata together to learn more about TDD and design principles.
- Be aware of the pair programming rules. If you haven’t practiced enough pair programming be very careful, read some books before.
If you plan to give a workshop and also coach, do the training before the coaching. There are some reasons for this:
- People start knowing who you are. You gain the credibility you will need when coaching, specially if is the first time they see you.
- The impact of a good training can open their minds so that they will be happy to be mentored one by one.
- The whole team realizes from the beginning that something good is going on.
Make your rules clear to management. I have a TDD workshop that works very well when it lasts all day long, starting from 9 o 10am (2 days). Sometimes companies have asked me to start after lunch and run the workshop over several more days in order to make it fit. I have accepted and the outcome hasn’t been as good as with my required time table.
Language and culture are fundamental aspects of communication. If you mentor/coach people with different culture or language than yours, you have to readapt your approach:
- Start coaching or mentoring one by one, rather than approaching the team, you will see how the communication is with everyone.
- Expect for the unexpected and always have a B plan. What happens if too many points are being missed in the communication channel?
- Take more breaks if you need it.
- Work less hours than you are used to. You will need more energy.
- Don’t worry if you don’t have the time to explain everything you wanted, make the people understand clearly what you teach, make communication a priority and don’t worry for the things you don’t have time to study.
- If you can’t speak in the language you choose, as fluent as they do, just don’t work with them, it will be a failure.
Custom in-home training/workshop is very risky. By custom I mean something the company ask you to teach, but which is not the training/workshop you are used to doing. In my case, I love teaching TDD and other XP techniques but sometimes people ask me for specific training on some languages or tools. If that is the case, try the following:
- Send a short questionnaire to every attendee, trying to figure out what topics they really want to approach. Usually the topics are arranged by managers and sometimes they don’t match what attendees really wanted. Even if management sent a survey to attendees, make sure you ask them one by one before, to let them be responsible for what they asked. It is a good way to start the commitment.
- Make sure attendees have similar skills.
- Make sure groups are very small, I’d say about 10 people max. You will need to find the time to sit down with individuals.
- Be able to split the group into smaller groups on the fly.
- If you are not really passionate about the subject of the workshop, don’t do it. This happens to me with some tools. Sometimes I get the feeling that people can just read a manual and get the same knowledge as they would by attending the workshop, and in those cases I prefer to refuse giving the workshop.
As in a speech, coaching/mentoring has three parts and the most important ones are the beginning and the conclusions, not the work in the middle as one might think (well, this is the case if the visit to the company is really short. The case of the coach working with the company for several months, is very different). The beginning is really important to catch people attention and motivation. Conclusions give the people a last feeling which summarizes their experiences along the work. Usually people don’t give you real feedback about what they were taught, they give you feedback according to their feelings as human beings. A nice conclusion is even more important than everything else. Remember that we need purpose (feel that what we do has a clear meaning) to get motivation. Conclusions should bring all the purpose of your working sessions and make it crystal clear.