The patterns behind Scrum and its master
As I wake up, there’s quite an atmospheric ambiance with raindrops drumming on the skylight above my bed. It’s still a bit dark, and when one of the garbage trucks passes by my house it shakes just a little. It isn’t just winter, it feels like it too. Every year seems to bring at least one day in which I wake up and things feel slightly different than before. I get out of the regular flow and realise I’m here, in the now, and just enough pieces of the mess-of-a-puzzle that’s in my head suddenly fall into place.
Time to write my very first blog.
I have been a Scrum Master for well over two years now, and since the start I’ve taken on many different beliefs on what exactly the role entails. I’m pretty confident that I’m bound to search for the answer forever (and that I’m not alone in that search). However, according to the Scrum Guide it should be rather straightforward: you promote and support Scrum within the organisation, development team and its Product Owner.
“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.” — Scrum Guide
As time passed and new lessons were learned, I’m no longer a fan of this description, nor the job title in fact.
For most people who are new to Scrum and decide to implement the framework, whether you’re a fresh Scrum Master, team lead, manager, or proactive developer, following the Scrum Guide is a great way to get started.
You don’t truly understand why you’re doing things the way you do, and that’s perfectly fine. It’s a great introduction to agility and you’ll have some context within which you can start to work.
You might make some silly mistakes that make you facepalm in hindsight, or maybe this gentle description of your error is the understatement of the century. None of that matters much, as long as you’ve got the most important skill as a Scrum Master covered: learning your lessons.
Misinterpreting Scrum
An error of mine was the result of reading past the lines of the Scrum Guide and start filling it in yourself (looking around me and on the internet, I know I’m not alone).
I managed to change Scrum into a heavyweight abomination of a ‘framework’, focussing so much on attempting to become predictable that we even measured velocity per person per day at some point. In hindsight I’m not sure what we tried to achieve in the first place. Being 100% predictable doesn’t even mean you deliver more value to a customer.
Another great example of a mistake is the fool of a (wo)man who started to call the use of story points ‘Scrum Poker’. Don’t get me wrong, estimating isn’t a bad thing, but as a result many people now believe it’s a part of Scrum. An extra piece of ‘process’ has been added to the Scrum framework, which is quite the opposite of a lightweight, helpful set of guidelines.
Focus on the patterns behind scrum
After realising your own (and other people’s) mistakes, and being the pioneer of changing-things-for-the-better, you don’t stop there. You naturally start asking yourself why you do the things you do. Why should you stick to a certain timebox? When is it valuable to estimate and when not? When does Scrum function optimally?
“Focus on the patterns behind Scrum, recognise those, and dance around them like a caveman” — A creative Bynder developer
Slowly but surely it doesn’t matter anymore how you label your processes, what the books say about the maximum duration of your meetings, or what framework you work in. If anything, using common known labels for the way you work can hurt your intentions and your team.
Like the example of Scrum Poker, where Scrum is perceived as more than it actually is, many people also connect velocity, user stories, ‘refinement meetings’ and even a kanban board to Scrum. If, for example, someone has had bad experiences with dreaded, unproductive refinement sessions, they will inherently connect it to Scrum. Of course Scrum wasn’t the reason the meeting drained your energy, poor facilitation of meetings does that for you.
Diving a little deeper into the example, the act of refinement actually makes for a good case for what can happen when a team doesn’t understand the key patterns behind it. Before I quote the Scrum Guide, remember how explaining why is more important than how.
“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.” — Scrum guide
There’s a whole world behind why, when, and how you should use estimations and prioritisation wisely, so this explanation of what refinement is does itself short. But besides that, I think it misses the point by focussing on how it should be done. Let’s have a quick look at the key patterns:
1: All participants understand the intentions and problems of their end users.
2: How can you deliver the value as soon as possible while still adhering to all your quality benchmarks, also known as rightsizing.
There are more values to be gained by executing a great refinement, but these two are the essentials that just can’t be left out. Adding detail to Jira tickets and estimating them are just tools used to achieve these patterns. If your team finds another way to achieve the same level of understanding: perfect.
What matters is how a process impacts your specific team or organisation and how it helps deliver more value, faster, in a durable and healthy fashion.
The focus should be on laying the groundwork for a team upon which it can figure out themselves how to call their events, how long they should take, and how they should be facilitated.
There’s some irony in a team understanding more and more why Scrum events are so valuable, only to see them get less and less value from following the Scrum framework itself as a result. The team can get creative and completely design their own process. They can redesign scrum events, sprints, or maybe even drop the Scrum Master role.
The role of a Scrum Master becomes cloudy
The end goal should never be to use the Scrum framework, it is merely a tool to build successful products consistently in a complex environment. The role of a Scrum Master insists you promote and support this (pretty good) tool, but there’s no reason to limit yourself to it.
As you and your team progressively venture outside the boundaries of the Scrum framework striving for agility, BizDevOps, scalability, and whatever else is on your state of mind, the role of a Scrum Master becomes increasingly cloudy. You lead by example in finding ways to do better, no matter how.
Naturally, however, if you’ve grown so much using Scrum, you just might grow past (parts of) the Scrum framework too. When that happens, Scrum Mastery ends, and something else starts. But what? I’ve been asking myself this question a lot lately.
What do you do?
I don’t care so much about what a better job title would be, so I’ll just call it an Agile Leader for the lack of perfect terminology that pleases everyone (including myself).
So what do you do?
I have noticed almost any team can benefit greatly from someone who takes on the role of a servant leader. Someone who is constantly in search for improvement, proactively tackles incoming danger, protects developers’s interest while syncing with a product-person to optimise value delivery, and dives on top of impediments. A jack of all trades whom the team can trust to properly represent them, all the while having zero authority over it in order to maintain that level of trust. You’re a team optimiser, and an organisation optimiser to the rest of the company. You read and learn about whatever is needed to improve and take those learnings out into the wild to try it out until it fits.
Lastly, but most importantly: you realise no framework will work with a dysfunctional team. Before even considering using a framework like Scrum, it might actually be much more valuable to learn more about humans and their behaviour in groups first. What does it really take to build a team? What truly motivates people? What does effective decision making look like? None of what you’d like to introduce Scrum-wise will have much effect if the team is dysfunctional from the get go.
“Wait a minute, I’m doing all that already” — Every Scrum Master out there
I’m fully aware this isn’t a radical change. What’s important is that the limitation of being Scrum-only is out of the picture whilst keeping what’s so valuable about it: the patterns.
It’s fully dark outside by now, even though it’s not evening yet. The days are still getting longer again, but I can’t ignore moody effect of the cold and darkness on me, nor do I want to, come to think of it. I suppose it helped trigger writing this blog in the first place, and it’s a great foundation for some overly contemplative behaviour.
As the metro is speeding its way through the lit-up city of Rotterdam, I finish up writing these last couple of sentences. I’m definitely not the only one in the metro looking at his phone. I wonder if everyone is revisiting what they did today as much as I am, or if they are just mindlessly scrolling through their Instagram feed. Not that it matters. I’m happy I finally managed to put my thoughts on paper.
As a final giveaway I’d like to share some book-recommendations for those interested in building teams and human behaviour.
