Agile Coaching

I finished a 5k on Saturday morning in 35 minutes and 15 seconds, despite recent runs coming in around 38 minutes. What did I do differently?

It was a decision I made in the first kilometre about where to spend the effort, and then readjusted at every kilometre after it.

I’ve been running this 5k for a couple of years. My personal best is 32 minutes, and somewhere in the back of my head sits the ambition of going under 30. Inconsistency had pushed me out to 38, which is where I was starting from on Saturday.

I’ve noticed something across the teams I coach: when ad-hoc meetings pile up, work in progress tends to pile up with them. I wanted to know if that was a real pattern or something I was reading meaning into, so I went looking at what other people had observed and whether the reasoning held up. The more I sat with it, the more I think I had the causation backwards.

Barry Overeem, in his paper on the 8 Stances of a Scrum Master, describes the Scrum Master as a Coach, Teacher, Mentor, Facilitator, Change Agent, Impediment Remover, Manager, and Servant Leader.

While all eight stances are valuable, three of them form the bedrock of an effective Scrum Master: Coach, Teacher, and Mentor. These roles are often blended, but each serves a distinct purpose in helping teams grow and thrive.

The Scrum Master as a Coach

“Scrum would never work for us here.”

It’s a phrase I’ve heard countless times, and it often reflects a deeper resistance to change or a misunderstanding of what Scrum truly is. While it’s true that Scrum isn’t a one-size-fits-all solution, it’s an incredibly powerful framework for teams focused on product delivery. When implemented correctly, Scrum can transform how teams work, prioritise, and deliver value.

So, why do so many teams struggle with Scrum? In my experience, the resistance often boils down to three key issues:

Product teams are under increasing pressure to deliver value that delight their customers, and proactively respond to changing market conditions. However, this will only be achieved when teams work effectively together toward common goals within a culture of trust and collaboration. While I wouldn’t recommend the Scrum Framework for all teams; I believe that the Scrum Value lays a solid foundation for building the required culture of trust and collaboration.

I often get attendees at our Scrum Training ask me for my preferred format for a Daily Scrum. I don’t know that I have a preferred format, but definitely not “What I did yesterday, what I plan to do today and discussion about Blockers”. However, if I can get you to reflect on the purpose of the Scrum Guide:

… to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

A good format might be:

Most Teams that regularly run a Sprint Retrospective use the dreaded quadrant, What worked well, What Didn’t work Well, Ideas and Actions (and variants of this quadrants). I am sure your team has used this format many times. I coach Scrum Masters and their team to always prepare for Sprint Retrospective, and part of planning is observing the team all through the Sprint and experiment with different formats for running the Sprint Retrospective.

I was invited to a meeting titled “Let’s hang and code”; it was for 2hrs and out of curiosity, I attended.

This meeting was an idea by the Tech Lead of a startup that I am currently working with. This is a startup where the entire team works remotely and the purpose, I learnt was to foster relationships between the team members and support people who might need help with the task they have picked up for the current sprint.

1. You assign tasks to subordinates and chase up for updates as soon as you feel they should have been done.
2. Regardless of what your subordinates are currently doing, you believe they should be working on something else.
3. You have just assigned task to a subordinate and immediately you follow up with instructions on how they should be doing it.
4. You are so bothered about how they spend their time; and you just need to ensure that they have enough work for 40 hours a week, that’s what their contracts says anyways.
5. You feel that your subordinate should be able to multitask as that’s inherent in humans.
6. Your subordinate shared a better idea but you don’t trust that they are smart enough; so you insist it must be done your way.
7. You subordinates are part of a product team but you want to keep them in a siloed functional team where they report to you.
8. You really need a daily status report - What they are current working on and what they did the previous day.
9. You believe that you need to help your subordinate prioritise their work as they must be struggling.
10. You need to make a decision, even when your subordinate could have made these decisions; at the end of the day you are the BOSS.

Does any of these resonates with you? Managers have a crucial role to play in organisations but managers can become too helpful that they get in the way of effective work. Oftentimes, the ways of working is an attempt to optimise for efficiency which ultimately affects the effectiveness of the team. The behaviours listed above might be appropriate in the complicate domain such as Manufacturing, where managers have a desire to maximise the utilization of “machines”. In the complex domain such as product development, these sorts of behaviours tend to have adverse effects on people and are counter-productive. People are a product of their environment and Managers micro-manage for a myriad of reasons, include pressure of deliver, lack of trust, immature teams among others.

Within a Scrum Team, there are no sub-teams or hierarchies.

An autonomous and self-managing team thrives when hierarchies take a backseat, allowing Scrum accountabilities to drive the ways of working. While organizational hierarchies persist, especially during the formation of Scrum Teams, it’s crucial to discuss privileges and their impact on a team’s ability to self-manage.

Privilege is when you think that something’s not a problem because it’s not a problem for you personally…

Hierarchical Privilege: This explicit form of privilege arises when a Scrum Team comprises employees with varying levels of seniority. Senior employees wield influence, sometimes making unilateral decisions that affect the entire team. For instance, a line manager, also a developer within the Scrum Team, might cancel a Sprint retrospective without consulting other team members.