You Have To Be Agile To Coach Agile

1. You Need to Be Agile

Software development is not easy. Finding the right architecture, the right design, even the right system to build is not easy. Couple this with the fact that team members have different backgrounds and potentially different political and religious affiliations, the challenge is even greater. It is under such a context in which coaching takes place. No wonder coaching is not easy. You really need to open your eyes wide. You really need to be resourceful. You need to be agile as a person to coach agile. Not just doing agile, but being agile.

As I always say, “The greatest risk is not knowing the risk. An even greater risk is that you or me might be the source of the risk.” So, it is important for a coach to remind themselves to check their assumptions, to understand what is really good for the team being coached. Where are they in terms of agile practices? Are they understanding correctly? What are their strengths and weaknesses in the application of these practices? Did they make the common mistakes? You can usually find check lists that contain these questions easily on the web.

In addition, a coach needs to check the temperature of all those involved in coaching. The person who brought us into the team would likely be supportive, but the person who is assigned to be the contact person might not be. This contact person is extremely important. Their enthusiasm or the lack thereof has significant impact on the success of coaching. So, do spend time with this person and understand what excites this person. It might be a personal hobby or something. Of course, the team members to be coached are important. Some treat you as God, while others could not be bothered. The key is to get everyone to be honest about their feelings and put this in the open. Hear them out. Let them speak. Do not be too eager to dump a load of agile practices on them without listening to their feedback. Of course, this is not entirely democratic. Many of the good practices take hard work. A coach needs to filter the noise and excuses.

In larger projects or departments, coaches need to work as a team. Of course this provides a reservoir of knowledge to draw from, but it also brings yet another set of challenges – that of speaking in one voice. Different coaches have their different competencies and likings. Coaches tend to emphasize what they think they are knowledgeable in. Moreover, you cannot expect all coaches to know as much as you. Every coach is also learning. They are evolving their understanding, they are evolving the way they communicate their understanding. This might result in confusion amongst the people being coached who get different responses about the same question. So, set expectations. Have a place for coaches to log their opinions – what are non-negotiable positions, what is still open to debate. It is useful to maintain a group blog accessible by the project members.

Dealing with people is unlike measuring temperature. It is not instantaneous. It takes a while. Their understanding changes, their posture changes. So, you always need to be on the lookout. Yet, you do not want to be so political that it wears you out.

2. Continually Clarify Objectives

It is important that everyone knows what they are aiming for and what they are in for. Building consensus is important. Firstly, I would list practices or approaches to be introduced jointly with the team. This list should of course help 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 out a defined practice or method.
• Process. A full-blown process is established to meet business needs.

Coach Role. What role does the team want the coach to play?

• Instructor. Coach acts as instructor to train in generic success scenario.
• Advisor. Coach acts as advisor to assess situation and provide warnings.
• Mentor. Coach acts as mentor to look ahead, show the way, and push forward.
• Leader. Coach acts as leader to take over responsibility of the project.

Coaching Involvement. What level of involvement or contribution does the team want from the coach. Some teams want to do it mostly by themselves. Some teams want the coach to sit beside them daily.

• Review. Consider lessons learned only at the final review of project.
• Reactive. Check progress of improvement regularly, and adjust plans as needed.
• Proactive. Do retrospective and set new improvement goals at each iteration.
• Continuous. Assess work status daily, decide quickly, and take immediate action.

Team’s Receptiveness. How willing is the team to accept the recommendations from the coach?

• Scrutiny. Every piece of advice is met with scrutiny.
• Adopters. Small group of innovative adopters lead improvements.
• Majority. A majority within the organization tries it out.
• All-aboard. Everyone accepts it, and tailors to their needs.

Evaluation of Effect. How do the stakeholders and sponsors want the results to be evaluated.

• Feeling. Results judged by members' feel for change in comfort level.
• Indicator. A single key performance indicator is gauged.
• Metrics. Project quality, cost and delivery (QCD) metrics are employed for full evaluation.
• Objectives. Effectiveness intimately tied to success of business objectives.

I do not have any presumption of which option is the best. Rather, Figure 2 is used to gather consensus on which set of options is the best fit for the context you are dealing with. It is about what works for the team. As you get to know the team, as the team grows, and as the team get to know your strengths and weaknesses as a coach, the appropriate options changes. So, do review expectations frequently.

4. Continually Engaging the Team

A coach’s job is never done as you lead the team members to really practice what they need to do and what you strive for is that they will do it right even without being told. Even when and especially when there is time pressure, they will still do it right. This is stage 5 of the approach as depicted on the Kanban in Figure 1 and when it becomes part habit.

Once a coaching engagement starts, I strive to become an active member of the team quickly and contribute effectively and seek out the issues.

For example, when coaching teams to apply test driven development (TDD), I often have to help the teams improve their system testability, often going through some of their code and highlighting places in their code where additional controllability and observe-ability are needed. This might require me sitting beside developers to show them how to do it. This also involves helping members determine which areas they should concentrate their TDD efforts to reap the most and immediate rewards. At other times when the members’ capabilities are better, just providing some advice is sufficient.

Another example is when a team wants to adopt iterative development, we need to determine how the work is being divided, by roles, by components, by releases and how many members are on the team. If the number of members is small and co-located, then a simple SCRUM approach works with little tailoring. For larger projects where roles have been defined, I would work with the team to define a lean value stream(s) and clarify responsibilities.

The agreed coaching role, involvement, speed (see Figure 2) has great impact on what the coach does. Things like daily meetings and retrospectives. provide avenues to engage the team members, but you should not be limited to these. You should seek every opportunity to work with the members. The social aspects are important. In some cultures, after work at the pub do wonders for coaching. It provides the atmosphere for members to let their hair down. At the same time, you do not want to be a nag. So, you have to be sensitive.

5. Continually Sharpening Yourself

The challenges facing the teams are wide and varied. In some areas, a coach would be fairly knowledgeable having worked with other teams and seeing how they have been solved elsewhere. But there will be cases when the challenges go further. As a coach, you need to help the team think out-of-the box to seek solutions. Usually, there would be someone in the team that has greater expertise. You need to draw from their experiences and their knowledge, or you draw from fellow coaches. Seek every resource to help the team.

It is important not to shun away from areas which one is not particularly strong. Seek to build up your knowledge in these areas. I am reminded of biblical verse of being all things to all men in the hope that I can save some (1 Corinthians 9:19-23). This spurs me on quite a lot. I have to be honest where I am weak and put in the effort to grow in those areas. Thus, every coaching assignment is also a learning opportunity for me. This has increased my breadth and depth significantly and for each new coaching engagement, I know in my heart that I can do better. I am sure you can too!

I believe your desire to learn and grow will be an inspirations to the people you coach.