Article original en français ici
CONTEXT
In your Scrum Master mission, a manager has asked you to support the implementation of an Agile framework in a team that, according to him, really needs it!
You find yourself accompanying a team that shows little commitment to adhere to the framework, little desire to challenge itself, to be in a continuous improvement process, to help each other to reach a shared goal.
The quality of the product is not fantastic and that only seems to bother you.
When you try to energize the team, or to provoke reflection by asking open questions, you always feel a heavy feeling of loneliness in front of the lack of reaction.
Development team members stay late in the evening, especially on production watches. They do their hours and work conscientiously, what can you blame them for?
Finally, when the development team encounters technical difficulties, they are disappointed by your lack of technical expertise. And yes, you haven't been up to date for many years now that you've become an expert in the art of using sticky notes.
SYMPTOMS
Whether it is for an internal mission in your company or at a customer's, your intervention mandate is plagued by an ocean of ambiguities.
Too many innuendoes and implicit elements create all the tensions that you observe and that make you live through difficult days.
Finally, you don't really know who really wants your accompaniment and to whom you have easy access to carry out your mission.
Probably the principal, who is often a manager. But what about the client/coachee/team itself?
Do you accompany the development team, the Scrum team only, the Product Owner only, the Scrum team plus its managers?
How should your coaching take place?
Beyond your title of Scrum Master, you also don't know with which stances you are expected by your client: Agility trainer / individual coaching / team coaching / facilitator / Java expert / test automation expert / DevOps expert / reporting-master / Jira-master / magician?
Are you only able to say what you are (or are not) responsible for?
And do you know who is responsible for what?
Have you clarified with the principal and the client whether or not you bring technical expertise to complement your Agility expertise?
CAUSES
From the very beginning of your intervention, you have entered the premises full of good will, full of the desire to do things right. In this start, sometimes in the urgency of a crisis or in the serenity of a calm departure with no visible traps, no one really took the time to clarify your mandate.
You really want to help the client, and you are paid to do so!
But very often, the client has not expressed a request for help, or not the kind of help you have in mind.
If the client is also the principal, the request for assistance is explicit and it is quite likely that the client's motivation is real.
But if the client is not the principal, it is quite likely that he or she does not share the stakes of the principal. The client then has no desire to change and observes with indifference or even suspicion the pawn that the principal has assigned to him.
POSSIBLE REMEDIES
A simple remedy is to clear the land of mines before accepting and starting the mission.
If you feel obliged to accept a mission with conditions that you cannot discuss, then don't be surprised to get poor results.
To frame the mission, you can clarify the relationship with a contract drawn up during a tripartite meeting, specifying what you receive as a mandate for intervention, and who will be the client / system that will receive your accompaniment.
You are free to challenge the client and his vision of the intervention from the outset.
For example, for a Scrum Master, are you there to grow the development team or are you there to help the organization understand and implement more agility beyond the Scrum team?
For a Product Owner, are you there to receive more or less capricious orders from users or managers and transmit them as User-Stories to the development team, or do you really have the levers to maximize the value of the product?
Framing by a contract is a good way to agree on the expectations of the different parties.
For example, how long will the support last - is it to help a team on a one-off basis over 3 months or to support the entire transformation of a department over several quarters?
In order to achieve which results - How do the client and the principal intend to measure the achievement of their own results?
With what responsibilities - Who are you accountable to and on what, taking care not to endorse the client's own objectives? To whom will you have access to carry out your assignment?
With what means - are the different clients committed to saving time so that you can work with them? For how long and how often?
With what tools - your tools as a trainer; coach; technical expert; facilitator; diplomat; mediator; negotiator?
CONCLUSION
Just like a contract established by a professional coach, a contract for a Scrum Master (or a Product Owner) is a powerful foundation for building a healthy partnership between different individuals, and also for clarifying the boundaries of the mission.
The clearer the contract and the boundaries of the intervention, the healthier the relationship, the better the chances of success.
In line with the Agile Manifesto, the contract does not aim to create a separation between the actors, but to increase the transparency of the system for better collaboration.