AMIA#23 | 3 things experienced Scrum Masters do that you probably don't
Aha! Moments in Agility
Live in your inbox every Sunday to help you build valuable software sooner
AMIA: #23
Reading Time: ~ 5 minutes
As you begin your Scrum Master career, you will quickly find that there is a world beyond the few pages of the Scrum Guide, the two day course and the relatively easy test that gives you the CSM badge.
The real world is a complex web of conflicting priorities, old school departmental politics and the continuous gravitational pull of old ways of working.
As Scrum Masters earn the scars from experience, they learn to be ok with silence, intervene with truth bombs in a way that doesn’t ruffle feathers and ask the right questions at the right time.
How do they do it? You want to learn too?
Here are three things you can do starting tomorrow.
The Hypothetical Value
The Big Chunks vs Layer Based Dogma
The Scrum Master As A Diminishing Role
The Hypothetical Value
Pavel A. Samsonov, a UX Lead at AWS, writes on Twitter… or X as it’s called now:
You will come across this a lot.
I don’t disagree with the premise. It is about learning by doing.
There does need to be some discovery before hand though. You would want to know which direction you have to go, even if you don’t know exactly which destination you will end up stopping at.
Where things go wrong, in my experience, is when discovery takes too long.
You want discovery or UX to point to a direction.
Regardless of how much time and effort is spent on UX discovery, it is still hypothetical value.
We think this is the solution to the customer’s problem or this is how the user would like to use our system.
Here is the deal: Unless we build it, and deliver it in the hands of our users, and get the feedback, every bit of ‘value’ we produce is hypothetical.
So at some point, there will be a diminishing marginal utility of continuing to refine cheaper, faster and better based on hypothetical value.
Beginner Scrum Masters don’t challenge this perceived value.
Experienced Scrum Masters question the value of over producing at the discovery stage.
The Big Chunks vs Layerd Based Dogma
Here is the screenshot of the front page of the manifesto for agile software development:
The question is: If this manifesto wasn't written, would we have continued to work on solving business needs with software the way we had in the past?
My hypothesis is that the nature of writing software is iterative on a developer level.
Developers break the problem they are solving into smaller chunks.
They structure code so it is purposeful and reusable.
Developers write some code, run it to see if it works and then go on to the next piece of code.
Yet, left to their devices, developers tend to do things in layers (Matt Riley).
On the other hand, It's the business that has to catch up to the nature of writing software so it can make full use of this capability.
Left on their devices, business tends to look at value as big chunks, big bang releases.
The Disconnect:
Catching up to and benefitting from the nature of writing software means the business has to change how it's structured and operates.
Whereas writing software has continued to evolve, business has been struggling to structure itself to make use of it.
As long as we continue to accept prescription based ways of working, business will be in the state of current cognitive dissonance.
Developers will continue to work in layer-based ways.
None of these approaches, Big Chunk and Layer Based Development, produces valuable software sooner so we can learn by doing.
Beginner Scrum Masters don’t understand that their job is to expand influence upstream of the team.
Experienced Scrum Masters understand that the Business and Developers both contradict the basic tenant of agility: the ability to change with quick easy grace.
Experienced Scrum Masters focus on helping business define small chunks of meaningful value, and they help developers slice work in deliverable slices, not layers.
The Scrum Master As A Diminishing Role
So, you got certified and recently got a Scrum Master role?
Have you considered the nature of your role?
Does it not say that the Scrum Master helps the team align with the Scrum Guide?
How long does it take? How do you measure your progress? When do you know it’s done?
Scrum Guide defines roles, not titles. This is a bit hard to understand sometimes.
The roles of PO and Scrum Master can be played by existing team members. They don’t have to hire new people to do it.
Now, I understand that teams new to Scrum may need some help in the start. That’s why an external Scrum Master may be hired.
But the role of the Scrum Master is to actively become irrelevant for the team.
In this graph with ‘hypothetical’ data, you can see that:
Blue line: Increasing level of team’s self-organization
Red line: Decreasing relevance of the Scrum Master
Beginner Scrum Masters don’t understand the transient nature of their role.
Experienced Scrum Masters understand that as they help their team become more aligned with agility, there methods and practices change too.
At some point, they will need to change to an observer and facilitator role and perhaps move to a team that is in early stages, or pick up another role.
Conclusion
Your value as a Scrum Master is to enable radical change in ways of working that delivers working software sooner.
No prescriptive framework and methodology works for different teams within the same environment.
You must go beyond your title and role to help the team.
When you’re ready…
I can help you in 3 ways:
Check out the resources list
Forecast timelines like a Pro in under 1 minute - Zero Estimate System
Fix the root cause of bugs & defects in your team - Root Cause Analysis Template
Book One on One coaching with me - Become a go-to Scrum Master in your organization.
Find me on LinkedIn and introduce yourself :)