What is a “junior” scrum master anyway?

 

A discussion that pops up every now and then in various agile forums is whether there is something like a “junior” or “senior” scrum master, and if so, how do you tell if you are one? The junior/senior thing is often seen as a hierarchical approach, and possibly an agile anti pattern. One of the ideas with the silly title of scrum master was that it was supposed to be a break from traditional hierarchical titles. For a servant leader, is “seniority” even desirable? No matter your intentions, a “senior” title implies that you’re above the “junior” or vaguely defined “intermediate” people with the same role. 

My experience is that the junior/senior designation is usually applied by people with low agile maturity: recruiters who do not understand agile, managers who may lead agile teams but do not adapt an agile approach to leadership or management consultants with more diagnoses (PMP, SPC, CSM, DUMB, whatever) than agile understanding. These people are so accustomed to relating to others through their rank that they can’t grasp to the idea of a role without a hierarchy to determine people’s worth.

A starwars meme
Failing to become a scrum master, Anakin turns to the dark side!

So, is the habit of assigning degrees of seniority to scrum masters purely destructive? Perhaps not. While I do not believe in allowing command-and-control people to determine how good of a scrum master anyone is, I think different scrum masters have different levels of aptitude and experience in using the scrum master toolbox. Some of us have years of experience in successfully dealing with change-resistant (or outright hostile) team members, some do not. Some have successfully coached managers in adopting scrum, some have worked exclusively with the scrum team. None of these experiences and aptitudes necessarily predict performance for a given situation: a just-out-of-the-2-day-training scrum master can perform admirably in a friendly environment, but the 2 day training doesn’t exactly prepare you for dealing with people who have been burned on faux scrum, or who claim to want to change but secretly resist it. While I do not consider past experience a reliable way to predict future performance, I do believe that facing adversity will teach you something about yourself and how you deal with it, and having faced a challenging situation before has given you a better chance to learn how it will effect you. I’ve successfully worked with teams and in situations today, that I doubt I could have handled at the start of my career. There was no magic “experience” where I learned to cope with those situations; I didn’t cross over a mystical barrier at 5 years, where I became more senior than I had been before, and no-one gave me a magic pin when I became a “senior scrum master”. But having tested my limits a few times before (sometimes failing spectacularly) had taught me what I could and couldn’t handle, and knowing that has helped me in many difficult situations. I suppose I was a more “junior” scrum master 5 years ago, and have become a more “senior” scrum master now.

A yoda meme
With the scrum (and a light sabre), there is nothing you can’t handle!

Despite this, I have come to strongly disfavour the idea of using a junior/senior designation, as it invites all kinds of misunderstandings. In many organisations, it is a full time job to keep the role of scrum master from turning into the role of project manager with no formal mandate, and making sure that the PMO isn’t allowed to define what agile means. Allowing command-and-control managers (or even worse, traditional HR) to assign seniority to scrum masters is only going to make that worse. To keep with the theme of a “silly” title, and because I’m a huge nerd, I’ll just stick with calling less experienced scrum masters “scrum padawans”. Lets hope that doesn’t turn them to the dark side!

Explaining time boxing to your clients

Today I had the honor of speaking at Kravdagen (Requirements Day) 2017: my topic was “my agile coach is talking shit!”, and among the topics I covered was the habbit of some coaches to be unable to explain why the methods and tools they advocate will actually benefit the client. And also today, I saw an interesting question on LinkedIn. The question was “The agile manifesto says nothing about time boxes, so why do we take them for granted in agile?” Sometimes we get so accustomed to using a certain tool or practice that we forget why we use it, or even keep using it when it no longer makes sense to do so! Inspired by this, I decided to write a piece about how I explain the benefits of time boxing to my clients.

Balancing focus and change

“Responding to change over following a plan”, reads the agile manifesto. Yet even in agile, too frequent changes can become disruptive. If we are never allowed to focus on completing something, we will end up with a lot of work partly done, and no work ready to be delivered. Agile teams thrive on change, but the change has to be controllable.

By working in small time boxes, the agile team gets the chance to focus on completing a handful of features. Anything outside of what is covered in that time box is open to being changed, but for the duration of the time box, the team knows exactly what they should prioritize.

Summary: time boxes allows the team to focus on the #1 prio, while letting the customer change what is the #2 prio!

Making sure stakeholders know what they’re getting

If you are a stakeholder to a team adapting agile, a major source of worry is the feeling of not knowing what you will get from an agile team. While our inner cynics may be tempted to point out “You never know what you’re going to get from your waterfall projects either”, this perceived lack of security is a serious challenge that must be overcome if you are to win over your teams stakeholders.

By dividing up the delivery time line into small time boxes, the stakeholder gets a very real way to measure what they’re getting. Are they getting valuable deliveries after each time box? If they’re not seeing any value after 2-3 time boxes they have the right to feel worried. But if they’re gotten valuable deliveries the last 5 time boxes, they can probably feel fairly secure they will get one at the end of the current time box as well. Compared to the false security of getting a spreadsheet that shows everything being green for 3 months but still not having seen a working product, deliveries after each time box gives amazing predictability.

Summary: time boxing, and delivering after each time box, allows the stakeholders a higher degree of security than big-bang delivery!

Enforcing feature breakdown

Everyone who has ever worked with product development knows that big features are impossible to estimate. This doesn’t just go for time estimates; it is very hard to estimate risk and impact of a large packet of work. The best way to understand the complexity of the work you’re planning to do is to break it down to smaller pieces.

Because time boxes are quite short (most teams use 2-3 weeks), only smaller pieces of work can be planned for a time box. You cannot fit in massive work packages in a 2 week time box, which means that the only way to plan any work is to break your work packages down into chunks that fit into time boxes.

Summary: by time boxing, we help ensure that work is broken down into manageable pieces, which in turn helps us estimate complexity and analyze impact and risk of said work!

So, those are some of my thoughts on how to explain the benefit of time boxes to clients. If your clients ask you why they should time box their work, what do you tell them?