Anyone who has been in a coaching role working within an “agile transformation” has been asked or assigned to a team or teams. Often times the people on these teams are not asking to be coached and being in that role you are left asking that question “How do I coach a team that doesn’t want to be coached?” Short answer: You Don’t.
People as individuals or as teams that do not want or feel they need a coach are not in a coachable place. For whatever the reason and these reasons are completely legitimate. But let’s really understand the situation everyone is in.
Pressure is being put on I.T. management to deliver more, faster, with less bugs and better predictability. The organizational leadership or management has decided they need to “do agile” or “be agile” and go through an “agile transformation”. This “agile transformation” is going to take place in I.T. . The management in I.T. has done some level of research on how to solve these problems and comes across people talking about agile and all of the benefits. The frameworks of Scrum, and SAFe and videos on Kanban dominate the search results. I.T. management seeks funding for training and hiring people to acquire these “agile frameworks” skills. And after a short time an announcement is made via an all hands call and a slide deck presentation lays out “The Path to Agile: Our Transformation Journey”. Or something along those lines. During this presentation a statement is made:
“With agile in place, we will be able to have greater predictability, better quality software, and do twice as much in half the time.“
The gauntlet has been laid down. Think of the people on the teams. They have been told by the rest of the company and with the support of their management/leaders that what they have been doing sucks. And that it is all on them. Everyone else is fine in this organization. The software people need to get their shit together. Not a very healthy or safe mental state to be in.
Now here comes this “coach” or worse yet “master” to tell the team how to do it better. Oh yeah, this sounds like a recipe for success. But here we are. What do you, as the coach, do now?
I have no idea. But here is what I have found to work.. sometimes…
After the introductions and initial pleasantries have been exchanged, ask some questions. Some are just human things, some are more work direct. And offer to help in different ways. And in no particular order.
- How’s it going?
- What are we working on?
- Does anybody else play an instrument or have something they like to do outside of work?
- What tech are we using?
- What tools do we use?
- Can someone set aside some time, or if we want to do this as a team, to put me in the context of the problems we are solving?
- I would love to help with <insert thing here>, is that something we can do?
- I always wanted to learn <insert thing here>, can someone guide me through that?
These questions are not the best questions, not the worst. But given the situation, it is better to be curious and ask questions with the intent of really learning and understanding. Nobody wins if there is suddenly a member of the team that is now dictating how things should happen.
Then hang out. This sounds like nothing is happening. Learning is happening. There are some questions being answered in this learning.
- How do people treat each other?
- What are the skills of the team? (Some team workshop or exercise stuff could expose this as well.)
- What does our value stream look like?
- How is the work actually getting done?
- What practices are in place already?
- Are the practices beneficial?
- Does the team understand the things they do and why?
- Are we following a process framework? If so, why?
- Is the process framework working? If not, where is the pain?
- How are decisions made?
- Is the work assigned, volunteered for, or does the team make a decision what’s next in collaboration?
- How does something really get into production?
- What does the pipeline look like?
That’s quite a bit of stuff you are trying to answer. This is all to help you understand the current context of the team. Where they are. You haven’t even begun to think about where they want to go next.
The focus is not on pain-points and problems to solve for the team. Nor is it so much on pain-points and problems for the team to solve on their own. It is finding spots of good in what the team is doing. The things the team likes to do, clearly is getting something out of, and is helping them. Great things come from there.
This is not the only way to gain trust from the people on the team. It just feels like a much better experience then coming in and installing a framework with set cadences and events everyone needs to attend essentially turning you into the enforcer of the process framework.
Over time, someone will ask for your help or your input or if you have an idea about something. Listen to understand as best you can. Don’t be afraid to ask more questions or say you don’t understand and need to wrap your head around it a bit more. Try to jointly come up with an experiment. One tiny experiment that we can learn from. And go from there.
Do we try to fix the faults in the logic of the management/leadership? Absolutely. Engaging with management and leadership to understand the purpose for the “agile transformation”. The goals they are striving for and why those goals are important. In the scenario laid out in this post, there is quite a large amount of work that needs to be done at the management level as well. Paying attention to managements/leaderships understanding of agile will also help with the teams ability to trust in you.
So does the short answer of “You Don’t” to the question: “How do you coach a team that doesn’t want to be coached?” hold true? It depends…
In closing, if you find yourself in this unfavorable position; be kind, be considerate, be respectful and look for opportunities to experiment and learn together.