Good Agile coaching is contingent and situational. I think that how you coach a person, team, organization, or company depends on who you are talking to, what they think their problem is, what you think their problem is, the current context, history, and so on.
Still, certain principles have proven themselves useful to me in a wide variety of situations. I'd like to lay out some of these Agile coaching principles here. Perhaps you will find them useful, or at least interesting.
To be a high-quality Agile coach, you must have a strong grasp of certain types of knowledge and certain skills. For example, depending on the types of Agile coaching you provide, you may need to know how to facilitate a meeting, install a unit-test framework, teach a course, design an organization, sooth hurt feelings, debug a team's planning event, set up a continuous integration server, split backlog items, or a thousand other things. As an Agile coach, you are hired partly because of your expertise. You must be an expert on what needs to be done.
It's necessary but not sufficient for you to know what needs to be done, though; you also must have insight into the factors that make Agile practices work. You must know why they need to be done. Your knowledge of the underlying factors and mechanisms will guide both your own actions and the options you provide to others.
You cannot study Agile too much or too deeply. Read books. Attend conferences. Join user groups. Ask for advice. Learn everything you can from the best people you can. When you learn something that really resonates for you, ask yourself, "In what context is this false?" When you hear something that seems stupid or wrong, ask yourself, "In what context is this true?" Check your answers with other people.
Your Agile expertise needs to be broader and deeper. Get to work.
Your coaching clients are the people that your sponsors are paying you to coach.
You must understand that your clients are frequently world experts in the domains, technologies, and systems they support. If your clients say that your advice doesn't make sense or doesn't apply to them, then you need to take what they say seriously. Your clients aren't right, necessarily, but then neither are you.
If you want your clients to stop and listen to you, you need to stop and listen to them. If you want them to be open to changing their minds, you need to be open to changing yours. That doesn't mean you abandon your principles; it does mean you need to engage with your clients as partners, as fellow experts in your respective fields.
Your coaching sponsors are the people who are paying you to coach your clients.
If you want to keep coaching, you need to connect your coaching services with something that your sponsors desperately want to accomplish. Your sponsors may already have something in mind that they want, or you may need to foster that burning desire in them. Sometimes both.
However it happens, whatever it takes, you need to connect the dots between what you do and what your sponsors passionately want. Your sponsors will not connect those dots for you; you need to do it yourself. In other contexts, this connect-the-dots work is called "sales". It's real work, and it's important work.
Once you have made that connection and your sponsors get it, you constantly need to give your sponsors evidence that you are giving them what they want. Your job is not just to do your job; your job is also to tell everyone—including your sponsors—that the job has been done.
Do not assume that the first thing your sponsors tell you they want is the thing they are truly passionate about. Dig deeper.
Never give just one answer. When you give your client a single answer, you take away your client's ownership of their results. Now the solution becomes "what the coach told me to do" rather than "what I decided to do". Also, giving your client a single answer reinforces a "best practices" mindset—the mistaken belief that excellence in a person, team, or organization takes a single form.
Instead, try giving your client at least three options and make them choose which option they want to try. If you can't think of three options, you know know where you need to deepen your knowledge—go study, go ask for help.
If your client complains about you giving them three options, threaten to give them five options next time.
It's not good enough for you to know the what and the why of Agile. You need to be able to express yourself fluidly, easily, in the moment.
You need to be very, very good at expressing Agile ideas. Practice your delivery over and over again.
Book a conference room just for you. Explain Scrum to the empty room in fifteen minutes without slides or other supporting material, using only a whiteboard. Now erase the board and do it again. And again. Get better, get smoother, learn the most important points you want to hit, in what order you should hit those points, what your timings should be for each topic, how you phrase your explanations, how you draw a product backlog, Scrum team, sprint diagram.
Got your Scrum delivery down pat? Now explain what Kanban is in a software development context. Now explain what user stories are. After that, explain the Agile Manifesto. Then the next topic, and the topic after that. Get smoother and smoother.
If you can't deliver an hour on most Agile topics without a slide deck, then you still have work to do. Not that you have to deliver without a deck, but your ability to deliver without leaning on a slide deck is a key test of your knowledge and skill.
If speaking in general is something you want to develop for yourself, Toastmasters can help. Note that not all Toastmasters clubs are at the same level of quality—try several until you find a club that works for you.
You are not your clients' manager. You may have informal authority in your clients' organization that is rooted in your knowledge and skills, but you have no formal authority over your clients.
This means that all the coaching you do for your clients must be done by their consent, not by fiat from you. That's why you need to ask for explicit permission from your clients before coaching them, and you should respect whatever their answer might be, whether it's "yes", "no", "maybe later", or whatever. It's quite common for your sponsors (those paying your salary) to be far, far more positive towards Agile than your clients (those whom you are paid to coach). If the client doesn't want Agile coaching for any reason, you need to stop right there and work on this organizational misalignment instead of going ahead with delivering what will most likely be a doomed coaching engagement for you.
Giving people the ability to opt out of Agile coaching is crucial to setting a context where your clients are willing to change their minds. It means operating from a position of respect for your clients' needs and desires.
If a client says "no" to your invitation to coach them, you have an obligation to make it clear to them that they may still be held accountable by their management for accomplishing certain Agile objectives, regardless of whether they accept your help or not. You may also send their decision up through their management chain, to make sure everyone is clear about what is going on with regards to their opting out. Your intention should not be to get anyone in trouble. Rather, before giving up on a client, you need to confirm that everyone with formal authority over this client agrees that not coaching them is the right thing to do. But if the client doesn't want Agile coaching and their management is cool with that, then who are we to say otherwise?
Your primary goal as a coach should not be to solve your clients' problems—though their problems will get solved as you work together. Rather, your primary goal should be to work with your clients until they can solve their own problems.
That means that for every problem that your clients bring to you, you should look at their problem from two angles simultaneously. First, what insights can you provide that might fix or mitigate this particular problem? Second, what is your client thinking or doing that creates or perpetuates this type of problem? Both of these perspectives must be addressed for coaching to take place.
That second angle is close to the heart of coaching. The more you address it, the more your clients will become stronger, more independent, more resilient, more capable, less reliant on coaching.
People frequently ask about "resistance". As in, "How do you deal with team members who are resistant to coaching?" or "What about people who are resistant to change?"
I almost never run into resistance when I coach. That's because before I begin coaching, I ask my clients for permission to coach them. Then I ask them what's worrying them most. Then I give them some options on how they could address what is worrying them. Then I help them design an experiment so they can try that idea out in their world. Only after they have run an experiment and evaluated the results do I ask them whether they would like to adopt that practice as part of their ongoing style.
When you work with your clients in this way, resistance disappears. Your clients do all the work of convincing themselves that change is possible, that change is desirable, and that they themselves can make change happen.
That doesn't mean "anything goes". I have my boundaries—I hope you do too. As an Agile coach, you have a responsibility not to support experiments that contradict the values and principles in the Agile manifesto. But within those guardrails, make your clients needs and wants your top priority. If your client wants to try an experiment that doesn't contradict the Agile manifesto—even if it's not a traditionally "Agile" practice—be open to giving it a try and seeing what happens.
Once you have proved to your client that you truly are willing to support them in their way, on their terms, your counsel becomes much more valuable to them. You have made yourself their partner rather than their adversary. When that point comes—if it comes at all—you then will have the opportunity to direct their attention to problems that they might not otherwise consider, raise sensitive issues, and so on. But that happens only after you have gained their trust and demonstrated your value to them, not before.
← home