This was the name of a session that I hosted at the Agile Open Florida on October 26, 2018. It was just an idea rattling around in my head coming off a month of screening candidates for scrum master, product owner, and agile coach roles. Honestly, I think wanted to talk about it to help me solidify some ideas and maybe some criteria around each of those roles, but especially the agile coach role. I had no idea that day that some many others would be interested in it as well.
When the session started I was surrounded by three quarters of circle of people seated three rows deep. It was a big draw and you could tell just looking around the room where two other sessions were going on. It was loud in the room. People were milling about not far off having conversations unrelated to what we were speaking about, but everyone in my session was straining to hear. Nor were they shy about asking me to speak up or repeat myself or repeat questions asked by others seated on the far sides of the group.
We ran long. I talked a bit and took notes on a flip chart. But I also asked them questions. It was a lively and very engaging session. We ran long. We didn’t mean to, but so many people had so many questions. I only hope that I was able to answer them all, to give those who were striving to become agile coaches hope and direction, to instill in those who were ready but hadn’t taken the leap the confidence to take that next step in their agile journey, and to confirm for those who had that they were not alone facing the challenges they faced every day.
Here are my notes from that session…
So, you want to be an agile coach…
An Agile Coach is…
The first thing we did was take a look at what an agile coach perhaps should be and what the differences are between an agile coach and a scrum master.
Understand Your Why
The very first suggestion was to understand your ‘why’. Why do you want to be an agile coach? What are you doing now? And what is the distance, figuratively speaking, between where you are now and where you want to be?
For me, I didn’t even consider wanting to be an agile coach until after I had already been a product owner, a member of at least one high performing team, a ring leader in a successful guerilla agile transformation at a large enterprise, an agile product manager, earned two scrum certifications, been a scrum master, an internal scrum trainer and coach, a member of another high performing team, earned three more scrum certifications, been the single source of all things scrum and agile for a major division of an international enterprise, a student of and later internal change agent for at least two agile scaling models (including adding another scaled agile certification), an active member of my local agile community, and then one of only two agilists responsible for shepherding and coaching the agile transformation across an entire international enterprise. Phew! After all that, then I allowed myself to entertain the idea that I might actually have what it would take to be a successful agile coach. For me, at the time, it seemed like a natural progression from what I had already done and what I was already doing. That was the bulk of my own ‘why’.
But each one of us needs to try and understand our own personal why before we start down the path of the agile coach. Because, contrary to popular belief, the job gets harder, not easier, the farther down the rabbit hole we go. The problems become larger, the number of people affected increases, the sums of money invested by our clients becomes greater, much greater. No, it’s definitely much safer to be a great product owner or scrum master than it is to step out onto the metaphorical limb and try to become an agile coach.
It’s All about Scope
The second thing we took a look at was scope. What is the scope of an agile coach versus that of a scrum master? If we take a look at the official Scrum Guide(™), it looks for all the world like the scrum master is already positioned on the path of the agile coach.
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
- Leading and coaching the organization in its Scrum adoption;
- Planning Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact Scrum and empirical product development;
- Causing change that increases the productivity of the Scrum Team; and,
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
So, the scrum master is already in service to the organization, just from the perspective of an individual scrum team. Your work as a scrum master should, arguably, lead you into working with the organization as it interacts with your team.
If we take a closer look at the differences in focus or scope between a scrum master and an agile coach we get something like this:
|One agile methodology
So, a scrum master tends to focus on one team within the framework of a single agile methodology (at least in the beginning) and an agile coach is focused on the organization, some or all of the agile teams within it, and on multiple agile methodologies or frameworks. Lastly, the scrum master is largely focused on the adoption of scrum within his/her own team, whereas the agile coach is more likely to be focused on a wider agile transformation that likely includes multiple agile methodologies along with championing a shift to greater agility in general across the organization.
Breadth and Depth
As we can see from above, an agile coach has a wider focus. In order to effectively (i.e., successfully) handle this wider scope, an agile coach must have greater breadth and depth than a beginning scrum master. Indeed, it is this greater breadth and depth that is another major differentiator between a scrum master and an agile coach.
Any agile coach is going to field an incredibly large number of questions about agility every week. Some will be trivial and take little thought as the answers to those kinds of questions will have been ingrained in the agile coach from their preceding years of experience. Others will be more difficult, more nuanced, and more subtle, requiring greater thought, understanding and awareness. Some questions will be tactical. Some will be strategic. An agile coach must be able to provide solid answers to them all. The only way to do that is have greater breadth and depth, greater understanding (usually stemming from greater experience).
Study, Study, Study
But how can we acquire that greater breadth and depth and thus prepare ourselves for the daily influx of questions That Must Be Answered. The first is experience, but that usually comes at its own pace. And that pace is dictated by the environment you find yourself working in. A startup is markedly different that an established enterprise. An enterprise is markedly different than a government agency. And any organization in a highly regulated industry is going to come with its own constraints unique to the sector it operates in.
Luckily, there is a second option that isn’t so contextually constrained – studying. One of the greatest allies that I’ve had in my career is my habit of studying. I read constantly. I read blogs, case studies, frameworks and methodologies, books, opinion pieces, and more. I watch videos and subscribe to channels that are focused on agile. I try to stay active in my local agile community, listening and learning from them as well as offering my own experience when I feel that can be helpful.
It’s one thing to study for a certification exam, and we all have to do that from time to time. But that is not what I am talking about here. I’m talking about cultivating a habit of study, of feeding your mind. This accelerates your understanding by exposing you to different perspectives, which, in time, will allow you to see the common patterns beneath the surface. It is my firm belief that the more I study, the faster I grow. So, I make it priority to study at almost every opportunity.
All of that studying usually leads to something. In the case of the agile coach it lends itself directly to one of the major responsibilities of the job, explaining agility. While a scrum master will absolutely end up trying to explain agility to his/her team, he/she will also end up trying to explain it to the team’s stakeholders. This can be daunting for a fledgeling scrum master, but we all usually find a metaphor that we like and then refine our approach over time. But an agile coach isn’t anywhere near as lucky.
An agile coach winds up trying to explain and even sell agile not only to teams, but also to middle managers and executives who can, at times, have a somewhat skewed understanding of ‘all this agile stuff’. An agile coach needs to educate the entire organization on what agile really means and what it entails. An agile coach must be prepared to educate the organization not only on the various methodologies (i.e., the mechanics, a.k.a. ‘doing agile’), but also on the deeper culture and mindset of agility (i.e., the agile mindset, a.k.a. ‘being agile’ and/or ‘business agility’) and how the organization can get there. This is where the real resistance in any agile transformation begins, by asking the organization to change (even a little). And this need to explain agile runs the gambit from helping middle managers understand where they fit in these new methodologies to educating executives in the very real costs and benefits of, and real world needs to become truly agile.
All of which leads us into our next two topics, Soft Skills and Internal Training Offerings.
Both the product owner and scrum master roles require soft skills. Product owners need to communicate effectively to stakeholders (who are more often than not some flavor of executive), customers, and the development team. Scrum masters need to communicate effectively with everyone, period. And scrum masters and product owners need to be able to communicate effectively with each other. Both need to understand how to defuse tense situations and productively resolve conflicts. And both need to understand the arts of persuasion and negotiation. It has been often said that a good scrum master wears many hats, from process coach to team cheerleader to amatuer psychologist. I feel this description roughly fits both roles. And the need for these soft skills only amplifies and intensifies in the role of the agile coach!
If you’ve ever had a rough day as a scrum master or product owner, then imagine yourself now having console a group of scrum masters or product owners (or both!) who have had that same rough day. As we said earlier, the deeper down the rabbit hole you go, the more challenging it gets. But rewards also increase, especially in the area of relationships and interpersonal interactions. And as such, it is not uncommon at all to hear agile coaches talking about emotional intelligence and how important it is both for them personally and for their work.
Internal Training Offerings
If you are able to both explain and sell agile, one of the next places that you will likely find yourself will be in designing and delivering internal training for your client organization. This includes training for executives on what agile really means, training for managers on how they can help in the process of agile transformation, as well as training for teams on how to ‘do agile’.
Some certifying bodies provide materials to help agile coaches as they go down this journey of educating and training organizations. Others, perhaps, not so much. In those cases, agile coaches often find themselves spending quite a bit of time creating training materials from scratch, and this is no small task. And even after we have all of that, often times we need to tweak our existing materials to meet the needs of our current client organization (for content, for time, for audience, etc.).
Some organizations want Scrum. Some of them want the Scaled Agile Framework for Enterprises (SAFe). Some want Kanban. Some want Scrumban. Some want all of the above and some don’t know exactly what they want. Some say they want one thing, but what they really need is something else. So, it really behooves us as agile coaches to have our own standing library of materials that cover all of these needs and can be easily and quickly customized to our current client organization. And this includes not only our own training materials that we use to present, but also any materials that we need to leave behind with those people, groups, and teams that we have trained (things like agile self-assessments, role quick guides for scrum masters, product owners, and development teams, and one-page methodology diagrams).
And once we have all of that, we still have to organize, schedule and deliver training classes. All of which can take months to create and deliver even if you have an agile transformation team. Longer if you’re working by yourself. And don’t even get me started on continuing coaching. That will eat up your bandwidth after every group or team that you train because they will need time and attention to grow into agile teams. So, please be aware of that.
Metics. Now there’s a double edged sword if ever there was one. Metrics are essential for understanding how a team or a team of teams is performing and what might be impacting or influencing their performance. But metrics are often used, incorrectly, by organizations to push or punish teams as they attempt to develop meaningful software and transform themselves into agile software development teams. As an agile coach, it is our responsibility to know which metrics to use, when to use them, and how to use them to both protect and foster the agile transformation as well as delivering valuable software. Not an easy balancing act all.
Personally, I used metrics predominantly as a measure of role, team, and organizational health. Similar to how a doctor uses measurements of temperature, blood pressure, weight, blood composition, etc., the agile coach uses a wide array of metrics to understand individuals, teams, and organizations. Metrics should paint a picture for us, but the metrics themselves are not goals. Let me say that again, the metrics themselves are not goals. They are only indicators in the same way that a high temperature in a patient can be indicative of a fever. Metrics only tell us what is going on (they symptoms), not why (the root cause). But for the agile coach, these metrics, when examined together, often point to the why. Always look for the root cause. Use metrics for what they are, indicators, but don’t take them as the whole truth.
Personality Traits of an Agile Coach
After the discussions above, several members of the audience wanted us to explore the personality traits of an agile coach. These are traits that help us, as agile coaches in our day-to-day work, and they seem to run the gamut of what it takes not to be just a good professional, but what it takes to be an amazing human being. Here is what we came up with…
|able to navigate conflict
|serves as a mentor
I don’t know about you, but that looks and feels like a very tall order to me. And even though I absolutely do have some of those traits, I don’t have them all and I don’t have them all developed to the same level. Developing these traits to their fullest potential is ongoing effort for me. One I have to practice daily and reflect upon often, knowing that I will never ‘get there’ but always striving to be just that much better today than I was yesterday.
Challenges of an Agile Coach
Finally, we took a look at some of the common problems agile coaches face. These problems are not just the ones we run into on the job, but ones that often affect our careers for the long term. These issues can be real stumbling blocks in our careers and, as such, I feel it important for us to call them out.
Legitimacy – What makes someone an agile coach? Are there certifications? If so, which ones are ‘better’? Which one is the ‘best’? Does experience count? How do we prove our legitimacy to our clients? What is the difference between an agile coach that ‘talks the talk’ and one that ‘walks the walk’?
Growth Opportunities – How can I grow as an agile coach? And how can I help others while I do it? While some of the issues in this section didn’t have ready answers, this one seemed to; be a mentor and have a mentor. Sure, there are lots of other things you can and should do, but don’t forget this one – be a mentor and have a mentor.
Time, Money, and Opportunity – There is no easy way around this three-headed monster. Agile certifications can be expensive. And the more you have and the deeper you go, the more expensive they become. They also require time, sometimes lots of it. From two-day classes to four-day classes, to ongoing certification journeys that can take weeks or months or years. And lastly, opportunity. Sometimes it is simply difficult to find a certain certification class in a certain area as a certain time. Many of us wind up taking time off work to travel for training and certification. This can be anywhere from a minor inconvenience to a major drag on your finances, time, work, and family. But if we know these things ahead of time, we can spend a little of our time and at least attempt to mitigate their severity.
Agile Community – The obstacle here being the lack of one. And this is tough. A strong, active, supportive agile community can take someone merely curious about agile and, over time, transform them into an exemplary agilist. Likewise, the total or near lack of an agile community, can, I’m sure, break even the best of us. A support network is crucial, especially considering that dealing with organizational resistance in all in a day’s work for an agile coach. If there isn’t an agile community in your area, then start one! You might wind up a coffee shop alone for a few weeks, but eventually, someone will show up and you’ll have the seed of your very own agile community.
Agile(™) – This certainly qualifies as an 800 pound gorilla in the room. Agile(™), capital ‘a’, trademark sign, is the military-industrial complex of the business of agile. It’s out there to make money and use agile, at least in name, to do it. Now, please understand, I am not taking a stance on this here. Everyone needs to eat and I get that. I do what I do because I love software and I love helping people. And that’s good enough for me. I don’t need a bigger reason. But I think we should all be cautious of Agile(™) as a means unto itself. The jury may or may not still be out on this, but many, many people have very strong opinions about it. Be aware of it. Then do you. And just remember, there is no little pill that will make you, me, or some organization instantly and wholy agile. It doesn’t work that way and that’s why agile can be a hard sell sometimes.
If you are still here, then thank you so much for sticking with us! And on behalf of everyone in attendance at the session, we thank you and we hope you found some of what we had to say helpful!