My last post was about interviewing Scrum Masters, and why elitism is not the way to go in my opinion. Whilst writing it, I was naturally reminiscing about some of the Scrum Master interviews I have done in the past.
Just to give you some context here: in the last year or so I’ve had phone calls with almost 50 Scrum Masters, and full interviews with almost 30 of those. Added together, that’s nearly 100 hours I was talking to Scrum Masters!
During the many years I’ve been talking with Scrum Masters, the topic of how we work was naturally discussed many times. Scrum, Kanban, Prince2, Scrumban, Lean, Agile…people like a label.
I see it from their point of view. It’s understandable that they would want to know what sort of environment they were considering working in. We use the label as a shorthand to describe all the practices usually considered part of that. The more places we have worked, the more pragmatic and loose that shorthand becomes.
Whilst mulling over these past interviews, I remembered one candidate very early on in the interview made a statement. It’s that which inspired this post.
The candidate and I had spoken about how, although we were hiring for a Scrum Master, we don’t do Scrum™. Yet, rather than ask a follow-up question about what we did and didn’t do and why, they responded with a flat-out statement.
“Ah, you do Scrum-But.”
I’m ashamed to say it irritated me.
The candidate was both technically right, and completely & totally wrong at the same time. I want to explain why. (I need to do it – its for some kind of personal closure or something!)
First, Let Me Talk A Bit About Monopoly.
Bit of a random topic switch I know, but please bear with me.
We like to start learning any new game we play with the rules. This is because rules help us to play the game in a way that we will be successful, even if we have never played the game before. However, it’s hard to find any family in the world who actually follows the EXACT rules of Monopoly once they’ve learned it.
Every family tweaks the rules slightly to make it more fun for them to play. It doesn’t make the game ‘better’, just more fun for them to play it.
I have even seen families, when playing with new people, do a quick check before starting. A quick comparison to see how the new players tweak the rules, and to explain how the hosts rules work. I have even witnessed brief (and amiable) discussions to decide whose version to play!
How are Monopoly Rules Relevant to Scrum Mastery?
I’m glad you asked 🙂
I think all the frameworks such as Scrum and Kanban etc. were expected, from the outset, to work in the same way as we all play Monopoly. They are called ‘frameworks’ to imply that changes can be made to suit the context they are in. They can be adapted to circumstances and context to make them more relevant, and so more useful.
For example, I particularly like Scrum for companies new to agile working. New agile adopters can easily feel they are afloat in a sea of uncertainty when they first begin to adopt agile practices. Especially if they are used to a more structured process. In this sort of context, the 4 Scrum ceremonies can feel like a life raft!
I also feel quite strongly that Scrum is incomplete on its own in a software environment, and should probably be coupled with XP practices too.
It’s definitely also worth noting here too that not all agile environments are software environments*
So, in my example here, I have taken Scrum for a particular reason; it was appropriate given the context of my mythical environment. I have then adapted it slightly by adding XP practices (this is so common it is almost not an adaptation at all.) Now I want to sit back and see how well it works.
The strength, in this example, is that the teams have a built-in safety net while they learn – the Scrum ceremonies. Less obvious, but even more important, is the fact that they are learning great habits. These habits will be useful in any framework they may later move towards.
You see, the strength of the Scrum framework is that it very deftly wraps huge amounts of psychology, behavioural and habit-forming practices into a set of 4 ceremonies. This is so elegantly efficient in early adoption scenarios, it can often take years before an agile environment needs to stretch beyond Scrum.
So if Scrum™ works great, why would they ever change?
Most environments will need to go beyond Scrum sooner or later as they grow and adapt. After all, things change. What used to work, slowly stops working so well, or a new process needs to be incorporated. It’s inevitable.
Perhaps they will find that sprint commitments don’t work for them, that their work is too emergent and fluid. In this case they may well find Kanban suits them much better. Or perhaps Scrum-ban is the thing for them at that time.
What they are hopefully learning is how to think. How to solve the problem they have right now.
“Let’s Not Do A Retrospective This Time”
Team A are dropping retrospectives because “we all know what happened last sprint, we don’t really need to use an hour talking about it”.
This is common in companies that a few months later say “yeah, we tried agile, but it didn’t work for us”.
Dropping the retrospective in this environment is fundamentally different to Team B’s experience.
Some of Team B have had a chat in the coffee room. They feel it seems to be an unnecessary delay to wait until a fortnightly retrospective in order to talk about their problem. In the last 2 days since the sprint began, they’ve experienced a sudden influx of interruptions from outside the team.
Instead, they want will bring it up at the end of standup tomorrow. They want to suggest a small, very cheap experiment they’ve just brainstormed over coffee to the rest of the team.
Whereas Team A have just skipped the retro because it seemed unnecessary, Team B have taken a step to replacing it. They have recognised that the retrospective provides a mechanism for the team’s continuous improvement. They want to build out the team habit of continuous small experiments to try and fix something or make it better in shorter cycles.
The Rules Are Only The Rules Until They Are Not
By understanding the benefits the Scrum ceremonies give you, it allows you to evolve & to fulfil those same benefits in other ways. Ones that might be more effective for you. Equally, they might not be more effective, which is why we trial new things before we commit to changing our process.
But we should change our processes. Sooner or later, everything changes. If your processes don’t adapt to be as successful as possible, then they are effectively fossilising.
At NewVoiceMedia one of our core values is “Raise Your Hand, Make It Right”. That is about us all owning the processes. If it could be done better, then by noticing it, you have both the responsibility & the authority to ‘make it right’. Feel free to draft in some help if you need it!
When you see something that could be done better, think about how that could be achieved. Now design a small way to test your theory. Did it work? Great! If not, think about what you learned from that experiment. Has it given you any other ideas? Now try that.
Now you are being agile. Feels good, doesn’t it? 🙂
*Please talk to me if you want to explore agilifying** a Marketing or Sales environment – I’m deeply interested in experimenting in those sorts of spaces.
**yes, I know it’s not a real word!