It’s the last day of 2025 and, despite everything that happened work wise for me this year, I am coming out of 2025 very grateful. I have taken some time to write down a few reflections from the year.
There has been a dwindling number of available roles for Agile practitioners such as Scrum Masters and Agile Coaches. Yet there is still a lot of work to be done, as long as there are teams that struggle to ship software consistently and many more teams operating as a feature factory with little clue about how much value they are delivering.
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
I spent the better part of 3 days last week in a Certified LESS practitioner course with the awesome Bas Vodde, one of the creators of the LESS framework. I had so many ah-ha moments, and this is my attempt to document some of the key learning moments for me over the course of the 3-day course. These are my notes, and there is a lot more context that might help you as a reader.
“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?
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.
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.
With the recent news about Scrum Masters and Agile Coaches being laid off in organizations, the question that comes to mind is whether we are at the end of the road with regard to these roles that have in the past focused on building agile capabilities in organizations on a full time basis.
My opinion is that organizations will continue to have a need for people focused on helping teams to continuously improve their ways of working, improving team and organizational effectiveness.
Increasingly, I encounter developers who don’t seem to enjoy using the Scrum Framework to deliver software, and this is a cause for concern because I have fond memories from my days as a developer working on a Scrum Team. I relished the collaborative atmosphere within the team, where everyone supported each other in development, testing, deployment, and held a shared sense of accountability.
However, nowadays, I hear developers express their discontent with Scrum for various reasons, including:
The Product Backlog Refinement session is not an official Scrum event, but it is a crucial activity that helps Scrum teams to achieve a shared understanding of the product backlog items in preparation for the sprint planning. Teams that adopt the product backlog refinement as a complimentary practice tend to have smoother sprint planning events. The number of refinement sessions within a sprint depends on various factors such as the state of the product backlog, the maturity of the product, the Scrum team’s availability and experience.
