Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Transition to Agile, How does it work (part 3)

Being an agile coach it is not always that easy. Sometimes you have to defend why you are needed. Agile is a lightweight framework with a small set of practices to teach, which makes it quick and easy to get teams up and running with it. So what is your added value?

Agile coaching is not only bringing in agile techniques and practices to teams. The agile coach helps the teams to collaborate, to be open, honest and transparent. The agile coach helps the team in doing agile well. That means finding the balance in tailoring the framework to fit in the project situation and organization without losing the values and principles. It also means bringing in examples, best practices, pitfalls and lessons learned. This asks for a coach who really believes in agile, breath agile, being agile and act as a role model. You have to honor the values that are underlie the agile techniques and practices. A good coach walks the walk and creates a path the team can follow. You are what you’re trying to teach them to be. It is a challenging role which requires new skills and a new mind-set, because most of us are not born as an agile coach.

Before I started as agile coach I was a project manager of fixed price IT projects with a command-and-control mindset. This was needed to negotiate with customers about the scope and control the team not doing more than was agreed. Luckily I was also experienced as facilitator  and (work/life) coach, before I started as Scrum Master and agile coach. This background gave me already the soft skills of asking questions, listening and facilitate people to find the solutions themselves. But despite of this combined background I’m still learning as a coach and recovering from command-and-control behavior. Not being a perfect agile coach is not a problem as long as you notice your mistakes. When I make a mistake by manipulating people in a direction I think is best, the best what I can do is being open and transparent. By telling the team which agile principle I undermined, they can learn from my mistake and I learn at the same time.

As an agile coach you need to be flexible, patient and resilient. In spite of all your effort and enthusiasm sometimes you don’t see  improved results on a daily or weekly base. It happens that not everybody has time for you and sometimes your good prepared retrospective, agile presentation or poker session is canceled because of external pressure, budget problems or other reasons. Sometimes they try to avoid you, especially when you exposes the dirt people have been sweeping under the rug for years. As a coach you don’t want to keep it out of your way, because mostly they undermine the success of the agile teams. When bringing these difficult subjects to the surface, there will be people who will not be very thankful for that. That asks for perseverance and a thick skin.

Last week I was talking with a team manager about how to measure team spirit and team value. As an example I showed him a thermometer with the terms “I feel very motivated” at the top and “I feel not so motivated” at the bottom. The idea was to let people give a dot on the thermometer during a face-to-face conversation with their team manager and discuss it. The team manager start laughing and pointed at the bottom. He said “no way that someone will say that he is not motivated”, I said “Why not?”, he said “well, I will never say to my manager that I’m not feeling motivated, because that will not help me in my career”. Probably it was a step too far and not a good example, but his reaction was very valuable to me. It gave a wonderful example that the environment for the team manager and thus the team members is far from safe and trustful. When topics like motivation and feelings of human beings can’t be discussed without (the idea of) consequences, than things will always stays the same and nothing will change.  The negative effect of unmotivated team members on the team results stays invisible and in worst case the unmotivated person will leave the company, while maybe a simple solution was  enough to solve the problem. The team manager asked me to focus on the project results and not on the soft skills. My first reaction was to convince the team manager about the importance of a safe environment for agile teams and how important trust is for a learning organization, but something in me said that is was too early. So I did what he said and focused me on the team and actually he was right. I shouldn’t discuss this subject with him. Why should the team manager have to solve motivation problems of team members? We have to trust the teams that they can solve this by themselves. Creating a safe environment within the team will have a positive effect on the team performance and thus the project results. In the retrospective we spend time on the practices Whole team, team spirit and team value. There are several techniques to use, like the thermometers (how warm/cold is the team temperature?) or weather forecast (how sunny, partly cloudy, cloudy or miserable is the team spirit) to start a discussion with. Maybe a developer is not happy because he/she has to work with miserable tools, or the work pressure is too high or the collaboration with other departments doesn’t work well. Addressing these issues, it gives the team the opportunity to define improvements or solve them. If they can’t solve them by themselves, they can raise them as impediments and ask for action at another level outside the team without referring to individuals. There is still a lot of work to do, but I see it as a first step in the right direction.

Much more about coaching agile teams and being an agile coach is described in an excellent way in the book : Coaching Agile teams, of Lyssa Adkins.

Link to Transition to Agile, How dows it work (part 2) Link to Transition to Agile, How dows it work (part 1)

About the author


Leave a comment

Your email address will not be published. Required fields are marked *.