The Hitchhikers Guide to Agile Coaching
The Hitchhikers Guide to Agile Coaching
If you're thinking about becoming an Agile Coach, read on to get a great overview of the position, and where you'll fit in with the development team.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Agile coaching is, at its core, not such a complicated thing. It is the art of observing, listening, forming an understanding and validating it, then working with the coachee to come up with and enact solutions. By coaching and observing others coach, you build up your own collection of patterns and tools. Where a junior coach will have to rely on written material and the support of others, an experienced coach can quickly form and validate hypotheses and pick the right tools from the toolbox.
What Is Agile Coaching?
Agile coaching is the art of helping people see reality using an Agile and Lean perspective and change their paradigms, habits, and roles accordingly. Agile coaching has two very different sides — agility and coaching — and you will need to know a bit of both. Being good or skilled in only one of these two domains is not sufficient.
Agile is an umbrella term for all kinds of methods and practices that are based on the values and principles defined in the Agile Manifesto. At present, the most widely used Agile methods are Scrum, Kanban, and XP. When we refer to “Agile,” we usually mean any and all of the Agile methods, but we will sometimes specifically address one in particular.
In our experience, most Agile Coaches typically have a background as Scrum Masters, project managers, general managers, process specialists, or quality managers. Working with different teams, they have noticed that they can help the teams work better by introducing or strengthening the team’s Agile thinking. At some point, they may start calling themselves Agile Coaches, or they keep their Scrum Master title. Through failures and successes, they have slowly learned how to approach and work with different teams. They have started out as new Agile Coaches with reasonably good Agile knowledge, but do not know enough about coaching. If you belong to this group, this article is for you.
Agile thinking and Agile practices are easier to learn than coaching skills. There are Agile books, Scrum training, workshops, conferences, communities, and a lot more available, however, for many people the main problem is, in fact, the unlearning of old patterns of thinking.
Coaching is also a skill that you can pick up and improve on, although perhaps not as easily as Agile knowledge. This is because coaching is a way of acting, almost a personal habit, and habits are notoriously difficult to change.
In order to become a good coach, you must learn to observe and listen, to keep your own biases in control, to not jump to premature conclusions and to communicate well. This naturally affects how you are aware of yourself, how you react to other people and how others perceive you. Many people are unwilling to even start this journey. For example, people who enjoy the feeling of power that comes from bossing people around, do not necessarily want to give it up.
Agile Coaching is not magical handwaving. It is a soft, but very very structured, skill. We don’t want to encourage the perception that an Agile Coach can just walk into an organization, talk to people, run some workshops, slap stickies on flip charts, and make everyone super-agile. Instead, we see Agile Coaching as structured and long-term work that stretches over months, sometimes years.
The difference between a newly started Agile Coach and an expert coach is simply that the expert knows more structures by heart and remembers more tools; and has more experience to help him/her choose the right tool or structure for the job. Where an experienced coach can pick and choose from memory, new coaches may need to consult lists, books, or mentors and are perhaps more likely to occasionally choose the wrong tool for the job. We hope that our posts will give you the tools and structures you need to become an effective Agile Coach.
We would encourage you to think of coaching as an additional set of tools in your leadership toolbox. Coaching is something you can try out and adopt gradually, tool by tool and technique by technique; and it is very likely that you will find the skills and tools in this post useful in many different situations. For example, the skill of listening will be very convenient when interacting with customers and colleagues, as well as your mother-in-law.
Other Kinds of Coaching
In this section, we would like to position Agile Coaching by comparing it to two other well-known coaching domains: systemic coaching and sports coaching.
If you haven’t heard about systemic coaching before, you can think of it as the classical therapy or counseling approach. Imagine a patient sitting in a comfortable lounger and a calm, neutrally dressed counselor in a hardback chair with a notepad in her hand, asking “And how can I help you today?”
A systemic coach works with the system. The information, interpretations, goals, and actions all come from the coachee and the systemic coach merely facilitates discovery through discussion. She asks neutral, open-ended questions related to keywords that pop up in the discussion. For example, “Tell me more about your time there?” or “How did the others react to this piece of news?”
Agile Coaching borrows a lot from systemic coaching. However, where the systemic coach is non-directing, the Agile Coach usually has an agenda of making the team more agile. Both systemic coaches and Agile Coaches usually have a sponsor and have been hired to achieve a goal. The difference is that systemic coaches try not to impose their own thoughts and ideas in the discussions. For an Agile Coach, part of the goal is to act as a role model, infusing the organization with Agile ways thinking and practices.
|Sports Coach||Agile Coach||Systemic Coach|
|Sets goals and targets for the team||Supports the team, provides benchmarks May discuss roles with manager||Accepts any result|
|Defines the team||Helps team members find ways to improv||Accepts the team as it is Helps team members find ways to improve|
|Tells the team what to do in a given situation||Outside the selected method, helps the team understand the approach in a given situation||Helps the team explore scenarios and choose which one to pursue|
|Has a somewhat linear understanding of cause and effect||Uses Lean and Agile thinking to understand cause and effects||Has a circular understanding of cause and effect|
|Very transparent emotions||Moderate display of emotions||Aspires to be neutral|
Every coach should always have a clear goal. Unfortunately, Agile Coaches are often called in to do something vague or implicit, such as “we’ve been told to deploy Scrum” or “my team isn’t meeting their sprint goals” or “could you just look at this team and say what’s wrong?” Part of your job is, therefore, to observe or quickly assess the organization, make a diagnosis or draw up some hypotheses and agree on the goal with your sponsor. Without an understanding of what the organization wants and needs, it is difficult to achieve results.
To do this, you will need to allocate “access time” with the organization. In some cases, this might mean a concerted, structured assessment carried out in a very short time. Other times, it may be more informal and unstructured — to the extreme point of hanging around in the coffee room trying to meet and interview as many different people as possible.
The Agile Coaching Stances
Interestingly enough, an Agile Coach needs to be able to do many different things that are not coaching. One of the basic skills of Agile Coaching is to understand when to coach and when not to coach and to know what else you might do instead.
For example, you may notice that a team doesn’t understand why they should split work into small independent tasks. If you were only allowed to coach, you would need to ask the right questions in sequence, patiently guiding them forward step-by-step until they connect the dots, understand the implications, and come up with the right methods.
This would require almost inhuman leaps of logic and induction from the team, as well as almost inhuman coaching skills from you. It would be more effective to just step out of the coaching role and spend a moment as a teacher.
Coaching and teaching are two different “modes of operation” that we call coaching stances. There are five stances in total, and we will explore them in this section. You should always be aware of which coaching stance you are taking at any given moment. You will change stances regularly as the situation dictates and you will need to take a different approach in each stance.
Coaching —For the most part, you should operate as a coach and stay in the base stance of coaching. This is where you listen and observe how the team works; challenge and question their assumptions and status quo, and facilitate and lead the activities.
The coaching stance is very close to systemic coaching as we described in the beginning of this post. It is the most “neutral,” in that the coach tries to be unbiased and not push their own ideas on the team. In order to avoid biasing the team that you are coaching, you should try to step back into the coaching stance as soon as the situation allows.
Teaching — The teaching stance that we mentioned in the beginning of this section is one that you will find yourself using quite a lot. In contrast to systemic coaches and to some extent also sports coaches, Agile Coaches need to be able to educate and teach people.
In this context, “teaching” means the ability to detect when the group you are coaching is lacking knowledge on some Agile topic, explain the concepts in a clear way, answer questions related to those concepts, and verify that the group has indeed acquired the new knowledge. It does not necessarily mean planning and carrying out engaging and informative multi-day courses. Although many Agile Coaches also work as Agile trainers and vice versa, the skillset required for giving multi-day courses is quite different.
As mentioned, you should find your way back from the teaching stance to the coaching stance as soon as possible. Asking questions like, “How do you think this new knowledge will affect your future actions?” or “With this knowledge, from your perspective, what would be the best thing to do now?” can help you return to coaching.
Mentoring — This is the process of transferring knowledge from the mentor to the mentored person, the mentee. The mentoring stance is useful when the mentee has knowledge to some extent but lacks experience in the topic. The transfer of experience often happens through discussions, stories, anecdotes, and advice. It can also happen through hands-on demonstrations or through collaboration and pair work, in which case one could talk about apprenticeship.
Mentoring is often confused with coaching, possibly because a good mentor must also be a good listener and a good coach. Many mentoring programs contain aspects of career or life coaching. Similarly, coaches must sometimes act as mentors. An Agile Coach would most commonly mentor a junior Agile Coach or a Scrum Master.
Your mentee is likely to find it convenient to have a mentor and she will encourage you to stay in that stance. Again, remember to return to the coaching role as soon as possible. For that, you can state something like “That was the story I wanted to tell you. What kind of thoughts did it give you?” or “Now that we have done this together, let me see you do it on your own.”
“I refuse to answer that question on the grounds that I don’t know the answer.” — Douglas Adams
Advising — Being an Agile Coach also includes the capability of giving advice to a client when necessary. This includes giving options, creating insights and evaluating their experiences. If you have opinions on a topic, you will also need to justify and motivate.
You should be very careful when giving advice, as coaching and advising are conflicting activities. As a coach, you are supposed to be neutral and unbiased, but as an adviser, you are expected to provide opinions and suggestions. You cannot do both at once. This is one of the reasons why you are most likely better off adopting one of the other stances rather than advising.
Another reason is that people who ask for advice are not always looking for an honest answer. It happens that people just want to vent their frustration or would like to know whether they can use you for support when driving their own agenda.
The third reason is that when you give advice or recommendations, you must also take responsibility for that advice. Sometimes you should not have any say in the matter or you may have conflicting interests. Sometimes a simple question requires a complex answer (or several complex answers) and sometimes the client takes your answer and implements it without understanding the implications.
We commonly find ourselves answering “it depends” and then perhaps explaining the relevant theory (training), helping them find their own answer (coaching) or providing examples that are hopefully illuminating (mentoring). Only occasionally do we actually give straight-out answers (advising) and it almost never happens that we carry out the work for them (consulting).
Even when giving advice, you should always leave the responsibility to the coachee. One trick to make that happen is to form your suggestions as hypotheses: “Could it be a possibility for you to...?”, or provide several options: “Another approach that could be worth exploring is... ” This sends a signal to the coachee that it is their call to come up with the solution since they are the ones that know the context best. It also indicates that you are now stepping back to the coaching stance. When you push your solution onto someone else, there is a risk that the other person will not be fully committed to achieving the desired result.
Role modeling —As Agile Coach, we constantly need to demonstrate integrity. Some of the key pillars in your career as an Agile Coach are transparency, honesty, commitment to helping people grow and maximizing the benefits for your clients. Role modeling is primarily about living the Agile and Lean values.
An Agile Coach cannot simply say one thing and then do something else. For example, stating that meetings always start on time and then arriving late yourself, or asking the Scrum Master to be prepared but showing up unprepared for your own engagements.
Role modeling is different from contracting or consulting. A contractor or consultant is hired to do a job on behalf of the client. The difference is that role modeling is a form of on-the-job training for the organization’s own Scrum Masters. The role model also only assumes responsibility on a limited level and for a limited time, e.g. ensuring that a retrospective is well facilitated or that the team is paying attention to the resulting actions.
As a role model you could, for example, facilitate a couple of Sprints, gradually handing them over to the organization’s own Scrum Masters, which falls nicely within the scope of almost any coaching engagement. This is in sharp contrast to sports coaches who typically do not go out on the field to score goals during a match, and to systemic coaches who can’t change themselves on behalf of their clients.
If your coaching engagement explicitly includes contracting or consulting, we would talk about embedded coaching. An Embedded Agile Coach is expected to work full time as a team member or Scrum Master for a period of months or years and simultaneously roll out Agile practices or promote Agile thinking in the team and the surrounding organization. While this may seem like a great idea — two for the price of one, so to speak — we try to avoid this mode of engagement as it has several pitfalls for both the coach and the client organization.
As the coach is now inside the organization, some of his/her credibility and leverage will be lost within months and managers will start bossing him/her around. Much of the coaching effort is spent on running the mechanics of the chosen Agile method and the coaching progress is slower than it could be. The organization also easily becomes dependent on the coach, so that progress stagnates after the coach eventually leaves the building.
Embedded coaching is also problematic for the coach. Working with two different goals seldom leads to satisfactory results, especially if the goals are conflicting. Furthermore, personal professional development can come to a standstill. Compared to a dedicated Agile Coach, an embedded coach has twice the number of professions to learn about but even less time. The experience they collect will be limited to this particular client and they will lose out on the wide, generalized knowledge that comes from working with many diverse clients.
As an embedded coach, it is important to make it explicit when you are stepping from one role to another. Do not constantly move back and forth or linger in between, because that will only confuse people around you. You will also need to find somebody to train as your replacement.
As an Agile Coach, you should always be careful not to involve yourself in content and product decisions when advising and role modeling. It may be tempting to propose new and nifty features or nudge the user interface just so. Remember that you have been engaged to improve the organization and not the product.
When you position yourself inside the system you are making it difficult to stay objective and unbiased. And unless you happen to be a recognized domain expert, it is very likely that the organization you are coaching understands their customers better than you do.
1) When working with a team, regularly remind yourself of your coaching stance. Try to return to the base stance, coaching, as soon as possible.
2) The next time someone is asking for your advice, try a different stance than straight out advising. Teach the relevant underlying theory (in a nutshell). Coach them to bring out the pros and cons of different options. Mentor them by giving examples from other teams or organizations you have worked with.
Published at DZone with permission of Marion Eickmann . See the original article here.
Opinions expressed by DZone contributors are their own.