In my last assignment as an Agile Coach, I coached Scrum masters. In addition to leading the transformation and actively contributing to the Scrum master chapter, this meant that every other week, I had the opportunity to sit with each Scrum master in a one-on-one session.
Agenda or autonomy?
A critical decision in these coaching sessions is whether to set a structured agenda as an Agile Coach or to allow the coachee complete autonomy in determining the session’s focus. Opting for the former risks overlooking personal struggles and challenges faced by the coachee, even if it enables us to discuss topics that align with the broader transformation goals.
Conversely, the latter approach allows for personalized attention tailored to the coachee’s specific needs, but it may be influenced by their own perceptions. For instance, what should one do when a Scrum master believes everything is fine despite evidence to the contrary?
In a particular case I wish to discuss, I had limited opportunities for independent observations. Instead, I relied on the insights and perspectives of the Scrum master in question. This approach led to productive and intimate sessions where we delved into team dynamics and the Scrum master’s personal challenges.
Typically, the Scrum master came prepared, initiating discussions with updates and specific problems from our previous sessions. By the end of the session, we’d explored various options and solutions, empowering the Scrum master to implement or try them in practice.
During one of our evaluations, the Scrum master shared that my external perspective — unencumbered by team dynamics — allowed me to provide objective advice. My detachment from the system and organization contributed to an unbiased viewpoint, which she found valuable. However, it’s important to consider that the coachee can have blind spots, leading to certain problems being overlooked. If every session revolves around the same topic, we risk never addressing long-term issues.”
What should we discuss when coaching a Scrum master?
To mitigate the aforementioned risks, I developed the Clover Model, which is depicted in the illustration. It serves as my answer to the following question: “What should we discuss when coaching a Scrum Master?” (Of course, the Clover Model can apply to situations other than to an Agile coach or Scrum master, but in this article, I will focus on the original setting in which it was created.
1. Challenges of the day – What is hot?
While I believe we should not get stuck on a single day’s challenges, discussing hot topics is still effective. It acts as a check-in question. If urgent matters arise, discussing long-term strategies becomes futile, as the coachee is unlikely to be receptive to other topics when the office floor is metaphorically ablaze. However, if there’s cognitive space to move beyond the current day’s hectic reality, we can then address other important topics as well.
2. Role fulfillment – Full width of the SM role
When Scrum masters are doing a good job and are effective in firefighting the challenges of the day, this does not always mean that they are practicing the full scope of the Scrum master role. It may not be required today for their team, but it may be important tomorrow or for other teams.
Being aware of personal preferences and biases is crucial. In coaching sessions, we explore the root causes behind overemphasized or neglected responsibilities and strategize to achieve balance. Role fulfillment matters, especially as organizations aim to enhance Agility and encourage their Scrum master to grow to a new level of proficiency.
3. Team metrics – What can we learn?
Many teams have a set of team metrics (e.g., team happiness, velocity, or predictability) that are measured at every iteration. Agile Maturity scans are also often used, albeit in a less frequent cadence. It’s worthwhile to examine these metrics and assess whether they align with the Agile coach’s perspective on the team.
Here are a few examples:
- “You mentioned that the team is gaining momentum, but the velocity is decreasing.”
- “Earlier, you highlighted a toxic atmosphere, yet team happiness is currently at an all-time high.”
In this context, there’s no absolute “good” or “bad.” Instead, these discrepancies spark valuable discussions about the metrics themselves, the insights they provide, and their significance. Furthermore, analyzing metrics can help uncover blind spots or biases on the side of the scrum master.
When metrics are outdated, it’s essential to redirect the conversation toward the Scrum master’s roles and responsibilities. While not every Scrum master may be enthusiastic about metrics, it’s part of their role to collect, analyze, and understand them.
4. Growth & training – Development of the Scrum master, the team, and stakeholders
The fourth question centers around knowledge enhancement and skill development. As we delve into previous topics, it’s not uncommon to uncover gaps in knowledge, blind spots, or the need for a deeper understanding of certain practices. The coachee can benefit by defining specific short-term actions.
For example, reading about a development practice can help the Scrum master better understand the team’s activities. Alternatively, the need can also be a long-term investment when the Scrum master wants to master certain skills to take the next step. Regardless, it’s essential to articulate these needs clearly.
However, the need for growth and training extends beyond Scrum masters alone. Consider whether stakeholders and the team would benefit from training. Perhaps we want to enhance their understanding of their roles or ensure alignment with Agile software development principles. Perhaps we want the team to work on, e.g., better refinement or host a workshop on giving each other feedback.
Anything goes when identifying the needs for growth and training.
Bottum-up transformational driver
Using the Clover Model not only enriches individual one-on-one meetings; it also acts as a bottom-up transformational driver. When applied, it immediately triggers important questions. For instance, during discussions about role fulfillment, we may have the same expectations within our coaching session. But how is the role perceived in the Scrum master’s chapter or center of expertise? Do leaders comply, or do they have their own definition of what the Scrum master should do? Additionally, how is the role defined within the organization? What serves as our reference point?
Discussing team metrics in coaching sessions can trigger discussions about the metrics we want to use and what insights we could gain from them. This becomes especially relevant when these metrics are gathered on an OBEYA dashboard. Alignment is crucial both between the teams and with leadership.
“Discussing team metrics in coaching sessions can trigger discussions about the metrics we want to use and what insights we could gain from them.”
The last question also prompts us to align expectations. If we want to send all Scrum masters to training, do we receive support for this initiative? Furthermore, if we believe that teams would benefit from workshops on topics like Continuous Deployment, BDD, or other engineering practices, do we receive support? Does this align with the IT and development strategy? Can we allocate time for developers to participate? If not, what does this say about the transformation process?
As a transformation coach, I have consistently advocated for addressing these topics within the organization. Unfortunately, there have been instances where leadership did not fully grasp their importance, and in response, they asked me to focus solely on the teams.
With the Clover Model, I am pleased to have defined a set of questions that allow us to do so at the team level, while simultaneously triggering relevant discussions for those topics that are relevant for successful transformations.
While the Clover Model covers essential aspects, I welcome additional suggestions or insights. How do you envision using this model, and what benefits do you foresee beyond those discussed here? Your input is valuable – please share your thoughts below.
