As the end of the year celebrations approached, I proposed to the community of Scrum Masters of my current client to animate the session for them. It was like my Christmas present! Indeed, most of the time we rather went on a co-construction of 2 Scrum Masters and me in support but I told myself that they had the right to a break! 😛
I propose in this article a description of the proposed session and as usual, an explanation of its construction mechanics.
Intention
By exchanging with different Scrum Masters here and there, I realized that the heart of their job, "being responsible for the method" as I can often hear it, was often reduced to the theoretical knowledge of Scrum and the accumulation of this or that practice, not to say the reflection around this or that retrospective format.
One of the points that seemed important to me to deepen was the ability to transmit, to communicate around what Agility is and what we are trying to achieve through it.
Indeed, for me there is a big difference between to know / know and transmit / raise awareness and I have the impression that we never really give the time to practice this second element.
It is therefore with this objective that I wanted to build this session:
Accompany Scrum Masters to structure a discourse around Agility, adapting as well as possible to their interlocutor.
And for that, I'm going to offer them a few bricks of content that I think are important to have in mind for this kind of exercise.
Structure
- 2 hours of time
- a maximum of 10 people
- (30′) Complexity
- (30′) Agile Principles
- (30′) Bad Agile practices
- (30′) Construction of a discourse around Agility
Complexity
The objective of this sequence is to raise awareness of the fact that there are different areas of context and therefore different ways of addressing issues. Indeed, one of the errors that can often be found in organizations is the use of the same strategy for different problems.
If our only tool is a hammer, then all problems will look like nails
Being the first animation sequence, I wanted to be able to put the participants in motion and therefore based myself on this quick workshop to introduce the notion of complexity.
After having debriefed the exercise, we took some time for contextualization in order to concretize a little more this notion which tends to remain very theoretical for the most part.
I therefore asked everyone to find situations / problems of their daily life for the 3 areas studied:
- Obvious : Feel, Categorize, Respond
- Complicated : Feel, Analyze, Respond
- Complex : Probe, Feel, Respond
Note: For a more precise description of these different areas, I invite you to see This article.
After a few minutes of reflection in sub-groups, we all shared together around the various results.
Note: it is important to specify that each element was positioned according to the wearer's perception and that this exercise is far from simple!
Something that appears Complicated for one person could appear Complex for another and both would probably be right, each at home! 🙂
Our point of focus was therefore more on the practice of reflection around the context of the problem (and the associated resolution process) than on the accuracy of the positioning.
Agile Principles
The objective of this sequence is to restore the basics on which to rely during an exchange, a reflection. I therefore naturally relied on the Agile principles, which I like to call “vaguely precise”, in the sense that I find them more easily actionable than Agile values – which are rather “precisely vague”. 🙂
Rather than simply listing them and discussing them, I wanted to give participants the means to anchor the main ideas a little more in order to be able to transmit them more easily.
So we went on the Pocket-Sized Principles.
The concept is simple: summarize each Agile principle in a maximum of 3 words.
For this, I had prepared each Agile principle individually laminated, which I placed on the ground to be visible to all and a simple support to allow everyone to put their own results and keep them on their desk afterwards.
| Note: Doing it in a small sub-group can be of interest to stimulate discussion but above all to realize that we don't always see the same things first. The formulation then becomes important to anchor and crystallize the notions that we will keep: and at the same time, there are only 3 words! 😛 |
bad practices
Now, rather than simply telling them that such and such a way of doing things is not the right way, it seemed to me much more interesting to make them think first about For what it was considered a bad practice (in other words what impact this practice can have) and then on How we could do otherwise.
| Note: This is a way of not focusing our attention only on the practices but also on the intentions and therefore the associated mindset. We are therefore working both on the "Be Agile" and the “Doing Agile” which in my opinion are inseparable to be truly relevant. |
Choice of cards
More than the specific phrase titled the card, it is above all the theme addressed around the phrase that was a criterion of choice for me. After displaying the different cards on the board, I asked the participants:- first of all to define on orange Post-it the reason why this situation could be considered problematic
- secondly to define on yellow Post-its how they could do otherwise
| Basingometer | Posts |
| 10 |
If we focus on “as much as possible, as quickly as possible”, we risk focusing our attention on quantity more than on quality, on the cost generated more than on the value produced. This does not necessarily lead us to take the time to define what is the right thing to produce when to have the maximum impact. Note: The tendency is more to do less to do well than to produce more to increase the chances of a fair hit. |
| 20 | The more players there are, the more the organization and the responsibilities are blurred. There is therefore more risk of having ego games, unaddressed activity zones and overlapping zones. This is one of the reasons why in a Scrum team there are only 3 roles defined:
|
| 36 |
There is a problem of intention and implementation here. Intention : The retrospective actually brings people to express what may have hindered them in achieving the goals they have set themselves, but it is in no way a crying office. These different elements should be taken into account as a basis for discussion so that together, as a team, we can learn from how we operate and try to do better next time. In other words: having more of what you want and less of what you don't want. see Accountability process Implementation : If the retrospective is felt in this way by the participants, it is probably because the structure of the event needs to be reviewed! 🙂 Often, it is the difficulty not in bringing out possible solutions but in their effective implementation that can generate this kind of feeling. This is an important point to take into consideration during the post-Retrospective follow-up. Another reason may be the difficulty in taking ownership of the problems and therefore in treating only the symptoms without treating the root cause. |
| 39 |
The notion of Target MVP simply doesn't make sense to me. If he's an MVP, he's not a target in the final version of what I want to achieve. The MVP is a way to learn about its value proposition by releasing its minimal version that can bring value to its users. There is therefore intrinsically a right to error accepted and assumed. This is mainly what we will take away from the teams when talking about Target MVP. |
| 40 |
Imagine that you are a sprinter on the starting line of 2 simultaneous races obviously not going in the same direction. When the tee shot sounds, where will you run? In another way, the fact of having developers who are members of several teams creates dependencies in the very structure of its organization and therefore increases the probability of situations of unavailability and delay. |
| 43 |
The Gemba-Walk is mainly intended for Management roles who, rather than waiting for information from the teams through reporting, will rather go and see what is happening on the ground in order to listen to the real conversations and therefore to see the real problems. The main risk in organizations (and all the more so at scale) is to see a layer of management that detaches itself even more from the operational teams rather than adapting its posture to give itself the means to be in support. |
| 51 | The situation described specifies the Daily but I will extrapolate it to any mechanism of the same type such as the Scrum of Scrum or even the PO Sync in certain aspects. We are talking here again about 2 things: the intention and the implementation. The main intention of feedback mechanisms is not to report to anyone but rather to acknowledge the current situation together to decide together of the best strategy to come. In the implementation, it is to allow everyone to express their difficulties |
| 52 |
We are talking about testers here, but the intention is to speak more generally of having a potentially deliverable product increment at the end of the sprint. This explains the desire to have multidisciplinary teams and to go more into the fine cutting of value production. |
| 66 | When we hear this discourse, it is because the review (abusedly called "demo") is considered as the event resulting from what we have succeeded in producing rather than the event at the heart of the feedback loop. on the product. The review is only a pretext to take a step back from the product and a way to create a link with stakeholders if they do not have the opportunity to interact more often. It is a difficult exercise in spite of everything in many teams which do not always manage to have a functional vision of what they produce. |
| 92 |
To focus on the hours consumed is to consider the costs more than the value produced. The discussions are therefore likely to turn much more on how to reduce costs rather than on how to identify the value produced and increase it. |
| Note: I did not use Bashingometer scores as proposed in the original game mechanic. I just used them above for ease of reading 🙂 |
Explain Agility
- consolidate knowledge,
- structure a message,
- and practice transmission to a target interlocutor.
| Note: The idea was to address sufficiently different roles and positions to have sufficiently different adapted messages! 🙂 |
I asked the participants, individually or in groups, to write on an A3 sheet the argument of their speech based on the content elements seen previously and the needs of the chosen interlocutor.
This could take the form of bullet points, tables, graphic facilitation… which could help them build their message.
After a few minutes of work, everyone practiced conveying their message in front of the group before our final debriefing! 🙂
Conclusion
This structure seems to have been appreciated by the participants both in terms of content and form:
- The sequence of 30-minute blocks means that we don't stay too long on each subject, but given the mechanics of contextualization, we try as best we can to make each notion concrete at the very least.
- The content is quite dense and the pace quite sustained in terms of facilitation.
If I had to do it again, I think I would manage to save a little more time for the last sequence in order to consolidate and play a little more on the differences between the messages for one interlocutor and another.
Do not hesitate to test and give me your feedback 🙂
