Following a tweet I sent this weekend: “ultimately an agile coach is a scrummaster who no longer makes decisions”. Here is a draft attempt at a supplementary response.
Scrummaster? Agile coach? Normally, ideally, in my eyes these two expressions designate the same thing, the same role, the same intention, the same attitude (you know I like these two words). It’s the same job. I agree that the scrummaster designates someone less experienced than the agile coach. But if experience is often a quality criterion, it’s not always. So I agree to start by saying that the scrummaster generally has a more limited scope than the agile coach. For example, the scrummaster is dedicated to one team, and the agile coach to an organization, or at least something that goes beyond one or two teams, a department, a domain, etc. Hence the snake that sheds its skin, to simply represent the molting. A molting that doesn’t necessarily open onto something different unlike the chrysalis.
If I’m trying to answer this question it’s because I read articles about these professions (like the recent one by Claude, or the older one by Géraldine), and I’m asked quite often: how does one become an agile coach? I used to answer: just make a blog and put “agile coach” on it, or a CV and change the terms.
A real terminology problem
Problem: no term is good. Whether it’s scrummaster or agile coach. Defective English translation? Semantic or semiotic issue? Both: The semiotic (the sign) must be RECOGNIZED; the semantic (the discourse) must be UNDERSTOOD (É. Benveniste, Probl. de ling. gén., II, Sémiologie de la lang., 1974).
Coach: the one who drives or who carries? Master, the one who directs or who masters? Ambiguity reigns. And everyone seizes this ambiguity to put in it what they want. Especially since proximity to other terms increases the confusion: promiscuity between scrumMASTER and project MANAGER, proximity between the agile, organizational coach and the individual coach (the real coach).
To stay in linguistics I also suggested for a time following Henrik Kniberg’s advice (I no longer know where I heard or read it) to prefer coach to scrummaster because at minimum coach implied support.
I remain however without an answer on the subject of the title, the term to use. For my part I prefer to speak of “agile mentoring”, or organizational management (the word agile is also indeterminate…). I’ve evolved a bit but I’m still in line with this article: I am definitely not an agile coach.
Path from scrummaster to agile coach
Reading the articles mentioned above or the conversations I can have, what do I want to highlight in this path from scrummaster to agile coach? Does gaining experience and opening up to spaces larger than the team generally lead to a transformation?
There is no value judgment between scrummaster and coach, the two functions are noble and self-sufficient.
Both roles should cloak themselves in neutrality and clarify the framework, the rules, hold the space, make visible what should be seen (at beNext I learned to prefer “NoBullshit”, telling the truth, one of our values, to transparency, which can be experienced as endangering intimacy), propagate and support feedback, learning, facilitate. But they’re asked to come with know-how. The danger being in the belief in repeatability and linearity of applying this know-how (strong difference between Agile and Lean in my eyes). We mainly come with a culture, values, a way of thinking, an approach, and not a recipe. Often it’s a crossed path: we start with a strong way of doing, a well-described recipe, a list to apply without deepening what’s hidden behind. We’re vague about the meaning, we’re strict about the form. The more we advance, the more we develop the meaning, the less the form matters.
Like Shu-Ha-Ri from scrummaster to agile coach, we first practice the gesture, then we understand variations in patterns, then we’ve integrated the meaning.
Some questions I would ask myself to calibrate in this path:
- Do the path and direction possess more value than the way of doing?
An agile coach will work on the framework and not make decisions for the team or people. They will clarify the framework, the rules, the objective, feedback, learning, etc. The first steps of a scrummaster apply to addressing the method, following the guides.
First we communicate, then evolving we open the channels of communication, we don’t do the communication, next step we indicate that communication channels are dysfunctional and we allow people to seize the problem, then we put people in position to highlight their meaning and their path, and to discover that their communication channels may not work well. At the beginning we’re a scrummaster then we become an agile coach.
- Do you make decisions for the team that relate to the value to create (and not to respect and maintenance of the framework)?
In fact the agile coach doesn’t make decisions that are linked to the value of their client, their interlocutor, they try to clarify the framework… bis repetita. Neutrality is an essential attitude for the proper realization of these scrummaster/agile coach roles. Each decision made in place of the team generates an accompaniment debt that distances it from a certain fulfillment and therefore from performance (being well, being good). Often scrummasters are inclined to make more decisions than agile coaches, or unfortunately this is expected of them, and they feel constrained to do so.
Not making decisions doesn’t mean that we’re weak or that we don’t have conviction. Our strengths and our convictions are located at another level: we believe in our analysis of the world, in our approach to thinking, in our philosophy (but like everyone we can also doubt).
Making decisions about the meaning and value of one’s client is pretty bold too, even pretentious. But sometimes being bold is good. Well, I don’t know anymore. To open their eyes surely. But that won’t help them change, it will even slow down their change. Hence “agile mentoring”: we open their eyes (that too is pretentious) by acting in a certain way for ourselves. It’s up to them to decide whether that interests them or not. This position is possible when we address levels of organizations beyond the team, beyond an ultimately reduced operational aspect, so it’s difficult for the scrummaster.
- Do you project yourself beyond teams, at a broader level, with this understanding of “seeing the whole”, of the systemic?
As mentioned above it’s perhaps the scope that most differentiates the agile coach from the scrummaster. Generally we ask the coach to address a larger space, to integrate the notion of “seeing the whole”, to have a systemic approach. The scrummaster is generally focused on one team.
- Are you uncompromising or filled with doubts?
The answer isn’t so simple. Naturally as we advance we become humble because we know the extent of possibilities that open before us. The more patterns we observe, the more we know they are numerous. But our intuition is forged and clarified. Our doubts and our uncompromising stances are not the same between the scrummaster and the agile coach.
Rate and presence
To return to one of the mentioned differences: experience. It usually leads to a rate difference. The rate plays a role on presence time. And presence time induces more or less good behaviors.
An agile coach has a higher daily rate than the scrummaster. But they don’t necessarily cost more overall because they should be less present. We hope that the agile coach won’t act. We hope the same thing from the scrummaster but it’s harder because generally they’re there all the time, and it’s very difficult to explain to organizations that to allow everyone to be more performant (being well, being good), the scrummaster must never leave their neutrality to facilitate as well as possible, and thus produce nothing at all. That’s my philosophy anyway. They can and should support, back up, sustain, but not produce. Difficult, because often the pressure is strong, from the organization, from their employer. So having a scrummaster at 100% is also the risk of perverting their role. And yet a scrummaster hired and present at 100% is also proof of involvement in the approach on the part of the organization. I’ll let you sort that out, I can’t.
In my attitude as an agile coach, but I prefer “agile mentoring”, or “organizational management” you know, I explain to my interlocutors that I’ll be there from two days to six days per month (exceptionally eight). Below two days my presence is too diffuse to bring value. Beyond six days we start to say that I’m going to do the work in place of people, and we completely forget the transmission and appropriation on the organization side that are an integral part of a lasting success. A sales presentation last week, I was asked what responsibility the agile coaches took on the declared project, I answered “none”. Which doesn’t harm our involvement in any way. (post-scriptum: presentation won).
4 paradoxes of change
During my last presentation on Open Adoption (I’m doing one soon at NCrafts on this subject, see you on May 12/13!), I mentioned the 4 paradoxes of agile change (which I already mentioned here), let’s see how the scrummaster and agile coach position themselves:
“Shu-Ha-Ri Combo”
Emergence is based on orthodox learning (and not on our habits or our desires). This is the beginning of agile learning: we try a practice to confront it, learn, discover our adequacy with it. Before deciding in advance how to adapt to it (which is a frequent mistake). The scrummaster as well as the agile coach (but they’re the same!) are normally comfortable with this because it’s precisely about applying a way of doing to perceive the meaning.
Difficult however sometimes for the scrummaster who comes from the organization, and who has strong muscle memory (the return to the organization’s habits, a strong imprint of what it was). Easier often for the agile coach who is paid more: so they’re listened to more, and who is often external: so they’re listened to more.
No stable state
“The stable state of a living organism is death” said Schrödinger. Like organisms, our organizations are not stable. This is also one of the useful messages of Holacracy: like an organism, change in our organizations is and will be continuous.
We must therefore adapt to a context that doesn’t wait to evolve (so we constantly adapt). This message is often carried by agile coaches, generally equipped with more experience and with a more stable footing to be heard on this sometimes disturbing message (again no linearity, nor repeatability, even often within the same organization).
We ask people to adapt to the context but it is changing. It generally takes the footing of an agile coach to keep the coherence of a thought beyond the context. More difficult for the scrummaster.
Suspend your beliefs
A team I was meeting had amused themselves by teasing me by displaying a Ka on the wall “have faith”. Which meant: “try” or was I playing the sorcerer’s apprentice?
Moving in a direction by suspending our beliefs (trying, daring). The paradigm shift linked to Agile thinking demands real experimentation. Try without preconceived ideas. This comes either from an agile coach who will know how to recall the philosophy, the meaning, of Agile thinking to guide experimentation, or from an innocent scrummaster who will try with all their good faith to apply what they’ve learned. This second option is naturally riskier but it can bear fruit. The most dangerous moment comes from the scrummaster who molts toward the agile coach, at the border, they’re sure enough of themselves to make their organization take enormous risks, they don’t doubt enough yet to measure the risks they’re taking.
Change is facilitated if we can go back
To change no one must be obligated. Invitation is the motor of change. Invitation is reinforced if we can go back. Change is therefore a set of experimentations in a direction (which allows trying by suspending one’s beliefs, trying to integrate this new paradigm), with possible return back. Ideally these experimentations are the fruit of proposals from the people brought to change. We’re really here in the heart of agile coaching in my eyes. Well beyond the application of a method like Scrum. This is unfortunately not something generally expected of a scrummaster. Wrongly, as I told you ultimately it’s the same role in my eyes. The retrospective and its continuous improvement is generally the first tool that opens this kind of practice, attitude.
Scrummaster or agile coach?
All that to return to the snake. It bites its tail. Ideally scrummaster and agile coach, no difference, just a simple molting linked to experience, to the path in one’s journey. Ideally we should find an identical word.
The thing to avoid is not being reduced to simple display (“we’re agile”), to simple decorum.
Feedback
Dragos
- Look Dragos
- (beNext power!) tells me: *Benevolent feedback
- the last article too long, split in two, see three. Very interesting, shame to lose some only because of its size.*
I answer: I don’t find myself too long, but very messy. I let people take what they want from it. The fact that it’s messy is just the fact that it’s not yet clear in my head.
Julien
Julien gives me a thunderous response, to which I don’t really know what to answer.
“Thanks for this article Pablo.
My little contribution on this subject:
An agile coach is often useful to start agility or make it grow (quantity and quality).
When we have to accompany a product owner, a manager, a software architect… having done their job helps.
Understanding the difficulties of their responsibilities, their commitments. And thus allowing them to have new automatisms and to unite with the rest of the group is essential to go beyond team agility.
Going from scrum master to Product Owner trainer or Product Owner coach, without having done the job of Product Owner seems difficult to me.
Like coaching without having been coached.
Moreover there are trainings on coaching and agile coaching in particular.
We can do this job with professionalism and without passing ourselves off as what we’re not yet 😉.
And agility is not limited to scrum nor to accompanying IT development.
In business we talk about HR, marketing, Business, customer relations, support…
Similarly the interactions between 6 sedentary people and a service is a different accompaniment with the subject of silos for example.
The agile coach is in my opinion someone who knows at minimum how to do the scrum master job (product management via the team) but quite a few other things in addition.
Moreover there are not only team subjects in a company.
And individual coaching also makes all its sense when we work with a manager on posture for example. We no longer talk about product or ritual but indeed about relationship and interactions.
So the agile coach in my opinion navigates from individual service, teams via scrum master coaching, to the organization.
I hope this clarifies more than it confuses but the subject as an agile coach particularly challenges me.
But I have a biased opinion by what I’ve experienced so not very objective.
Thks”