them solve the key challenges they face. A possible list might be:
- Introduce daily meetings to get members focused.
- Introduce feature/use case/user story driven development
- Introduce Value Stream Mapping (VSM) and Kanban
- Improve code quality
- Increase the coverage of unit testing with test driven development
- Reactor legacy code
Each approach you are getting the team to adopt follows a lifecycle as shown the 5 stage Kanban depicted in Figure 1.
Figure 1 - A Process Improvement Kanban
This kanban is used as a way to track the progress of each approach just like you would use a kanban for features or requirements in software development.
For each approach, describe the approach and simulate or role play the approach to determine if the team members know what they are supposed to do. This gives the entire team a common and agreed understanding of the approach and what each individual needs to do. This role-play also provides a chance for them to raise their concerns and help understand their context and constraints.
As an example, I worked with a team with on-site contractors. The local law forbid direct contact between my client and their contracted engineers unless through their managers. So, daily meetings have to be conducted through these managers. So, the daily meeting is like a rated movie. Yes! Parental Guidance is advised.
Some of the practices and approaches have measures. If this is the case, the measures are quickly listed. If the measures can be automated, this is even better. If the measures can be generated by a continuous integration environment, this would be the first thing to do. For example, if the project team wants to do re-factoring or improve code quality, the first thing that has to be done is to introduce some static code checker and have it running in the continuous integration environment.
The list can be broken down further and become a process improvement backlog and I can check the items off as they get embedded into the teams way of working. Once an approach gets adopted, get the team to conduct a retrospective to help them understand the improvements they have made. Let them all pat each other on the back and to say to each other well done. Of course, there is a long way to go. Some team members will stay focused on the unsolved challenges, but constant encouragement is important.
The process improvement backlog and the kanban provide valuable feedback to stakeholders and sponsors. It tells them of the results so far and is also a mechanism to seek their active involvement to remove blockages, to encourage the team. Keep them in the loop. Don’t bury yourself too deep within the team. Show your head. Don’t mind getting shot at.
3. Continually Clarify Expectations
A coach cannot simply barge into a team and tell them to do change their behavior and expect everyone to share their enthusiasm. Some teams may not have worked with coaches before. This affects how you would install an approach into the team and how to adapt the approach for the team (see stage 3 and 4 in Figure 2).
Figure 2 below summarizes a simple way to clarify expectations.
Figure 2 - Coaching Expectations
I describe the cells in the above figure as follows.
Improvement Target . What objectives do the team being coach want?
- Skills. Introduces a limited set of new skills and techniques to the team, such as through some training.
- Approach. A new approach is applied to solve a specific problem area.
- Method. Initiative is planned to roll