Serious Scrum
Published in

Serious Scrum

Is my Scrum team really self-organizing?

Some hard questions to ask yourself as a Scrum Master

Recently, on the Serious Scrum Slack channel, someone raised the following question:

“We always say: “The Scrum Team need[s] to be self-organizing”. But… how could you know or determine if a Scrum Team is really self-organizing?” (Edited)

Well, for starters, the Scrum Guide says this:

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

and

Development Teams have the following characteristics:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

No one! Not even you! Hands off!

Now there’s a bitter pill to swallow, but it always needs reminding. All these cool ideas you have about how the team should work? They can only ever be suggestions. This goes for this article, too. You shouldn’t use it as immutable truth, but experiment with what you take away from it.
That also means that your ideal team you imagine might not be the ideal team your team wants to be. If you desire nothing more than a room full of people talking passionately, but your team are the type who think first and talk later, then it’s your duty as a Scrum Master to recognize that and build on those strengths instead of pushing them to talk more often. They might just surprise you with a quiet catalogue of well-thought-out ideas, if you give them the time.

So, now you have acknowledged your role as a Scrum Master, and management at least says that they are going to let your team work in peace.

But there’s something wrong with the way your team works. Maybe it’s the 50 seconds of silence at the Daily Scrum. Maybe it’s the way they always look towards one person in particular. Maybe it’s that they’re always overworked, despite your velocity dwindling with every sprint. Maybe it’s that they can’t seem to complete the sprint goal without gentle pressure from a third party.
Whatever the case may be, you have this feeling that your team isn’t self-organizing, but when you ask, everyone claims that they have all the freedom in the world, and that they’re doing just fine. So how can you find out if that’s the case, and (dis-)prove your intuition?

Unfortunately, there is no “self-organizing” metric on your agile board. Actually, there can’t be. Self organization is a skill and a mindset, and those are almost impossible to put into hard numbers. But if there isn’t a measurable factor that tells you a team is self-organizing, how can you validate or quench that gut feeling?

I found that asking yourself a few hard questions about your team and yourself can tell you much about their maturity. There is no question that will give you an answer like “My team is X% agile”.
But there are good questions that at least give you a binary answer.
Are they, or are they not?

I mean questions like these:

1.Do you ever clearly see a problem or a negative outcome, but it doesn’t seem to bother anyone in the team?

If you clearly see something is going wrong, but no one in the team says something, you need to find out why. Your team might be very new and unaware. They might just be blind to this particular problem. They might see it and just don’t care. One way or another, in this particular instance, they are not self-organizing to solve it.

Now, disclaimer: If they don’t even know what’s wrong, why do you? Is this really an impediment, or are you just thinking you need to act to validate your role as a Scrum Master? Only if you’re 100% sure something needs to change, you need to coach the team on that particular topic. Offer them ways to do better.

If they ignore it, make the issue transparent.

If they don’t care, ask them why not, and work from there.

If they all skirt around the issue, too afraid to bring it up, you need to teach them to have more courage to do the right thing. Support them. Remind them of their ideals. Tell them what they can do. Demand that they prove themselves not to you, but to themselves. Push them into the shallow end of the pool and show them that in fact they can swim.

2.Does your team approach you with impediments they have, or do you need to find impediments by investigating problems that occur?

This one is easy, and a corollary to 1. At the beginning, self-organizing teams try to solve their problems by approaching the Scrum Master. This is good, because you know they trust you with their issues, and it also shows that they are aware they have issues. Ultimately, though, they want to go even further, and resolve most issues they can by themselves.

If they don’t even approach you with their problems, and you need to find out whats wrong by pulling it out of their noses, there’s a big impediment for you to tackle, somewhere. Good luck.

3. Is everyone involved in discussions, or are there people who monopolize time, presenting only their own ideas?

Here at Serious Scrum, the joke goes: “We all have a person in our team who talks too much, and It’s the Scrum Master, ayyy!”

But we’re talking about a different scenario. If often, you have one team member bringing forth their own ideas and the team just goes with it, chances are they aren’t self-organizing. They are either being self-organized or at worst not even a real team.

Good case: everyone in the team contributes to the discussion, and every voice has an equal impact.
Best case:the team brainstorms something, weighs out the pros and cons together, then forms a mutually beneficial consensus, all without your help as a Scrum Master.

4. Do you have a sense that the team WANTS to do better? Or are they ‘happy with where they are at’?

If I had one advice for any Scrum Master, it would be this: Look for signs your team wants to grow, and foster those.

I can definitely tell you this for a fact: The biggest sign somebody doesn’t want to change is apathy. You need to quash apathy where you find it.
Apathy can have many causes, none of them genetic. The team might not feel appreciated by their parent company. They might feel overwhelmed by their work. They might be inexperienced as devs, sitting in Plato’s Cave and thinking they have changed as far as they can.

But if apathy is a sign indicating resistance to change, what are the signs for a desire to change?
Well, they are really hard to find, and your signage may vary, but one thing is certain. You can find this desire in the strangest of places.
So embrace irregularities, and even consider ostensible impediments as a sign for this desire: A team member repeatedly asking questions about a subject no one in the team is familiar with. A team member repeatedly becoming frustrated about a particular topic. A team member turning the server into a sandwich grill by making an experimental change to your live environment. All those things seem like impediments at first, and they are! But they may also indicate that someone wants to change the way things work for the better, and might not know how.
This is where you have a chance to shine! Grasp that desire and work with them to find a way to have it drive positive results.
Obi-Wan, you are their only hope!

5. Does anyone ever approach you, on their own, with new ideas on how to make the team better?

If they are coming to you, they want you to organize their growth for them. That’s okay, especially in shu, but eventually you want them to bring these initiatives to each other, so that they can organize their growth on their own.
But if one dev is constantly approaching you alone, you might have an issue. Maybe they’re not courageous enough. Maybe they don’t feel respect towards the rest of the team. Maybe they are focused on other things than becoming better and feel as though organizing improvement opportunities is a hassle. Maybe they don’t want to open up to the rest of the team.
Any case, you can’t be a self-organizing team if you aren’t a team, can you?

10 bonus points if you get the reference in the last paragraph. ;)

6. How does the team react to pressure from the outside?

Do they huddle together or scatter into fragments? If the former, do they try to form a unified response to this pressure on their own? Even better, do they immediately try to work within their means to address the issue?

Tell me if you’ve heard this one before:
A manager walks up to a Scrum Team. “I need you to become agile faster. You have until the end of March.”
Panic. Chaos. Everybody is running around screaming, something’s on fire, and I’m pretty sure the Product Owner is off in a corner, sobbing to himself.

If your team ever reacted like that when the dragon emerged from the cave, that’s okay. That’s normal. But afterwards, does your team come together without being prompted, and do they try to work within their means to make things better?

Too often teams start to do several things, all equally bad.
They shut down and give up.
They start blaming each other.
They start blaming the circumstances.

While these are great indicators to team growth, none of these fun activities help reach your sprint goal. And none of these show any self-organization.

No, this is when push comes to shove.
This is where the tough get going.

In order to overcome a crisis like sudden deadlines popping up out of nowhere, or a shortage of funds, the team needs to embody all 5 Scrum Values. They need to communicate that whatever just happened is going to have an impact on the product, but they need to be brave, committed and focused enough to be determined to still deliver the best product they can.
And they need to immediately brainstorm, together, possible solutions of how to move forward in the face of disaster.
If they do all of these things on their own with minimal friction, I would love to meet them, because that’s a really great team you’ve grown.
If they come to you to help them, and you manage to get them out of this tough situation with everything intact and morale high, I would like to meet YOU.

You can do it!

7. If there was one person on the team who impeded your growth, would you trust your team to handle the situation on their own, or would they remain impassive until either you or management acted?

Okay, okay, this is an extreme and contentious example, and it deserves a disclaimer. I don’t propose you teach your team to bully out problematic team members, of course. I also don’t propose kicking people out of teams willy-nilly. But I do believe that after several months of friction, sometimes it’s better to assign a team member someplace else. Don’t get me wrong: if you have to resort to this, everyone has failed, in some way or another.
But take the following example: There is a team member who feels as though they are not getting enough attention, so they start seeking it actively. First by talking a lot in meetings. Then by simply doing things their way. Ultimately, they try to improve the work of others to prove their own worth, and might break something in the process.
Ideally I would want the team to do everything in their power to make this person feel welcome and understood.They need to be given chances and support.
But if that doesn’t work, they should form a team consensus to remove them.
This isn’t kindergarten, and this isn’t a high school lunch table. Your team should know how to help a person into the fold. They should know why and how to walk the hard path through a storming phase. They should try everything they know, then learn more and try again.
But they should also know when a situation isn’t salvageable. And they should act when they become certain.
They should self-organize.

8. Does the team change immediately after you showed them a new way to resolve their issues, or do you have a discussion about the benefits of what you proposed?

HA! Trick question! The desirable outcome should be the latter. You want your team to question what you are doing, as long as they question themselves, too.
If they are constantly asking themselves “Is this the best way we could do this?” and try to custom-fit solutions to their own team, then you are already light years ahead of most teams out there. Good job!
And if they don’t accept any answer but the one that challenges them to do things better, then you should be looking for a new job, because you are clearly done with your work ;)

There are other questions, of course. Millions of them. As many as there are Scrum teams, and then some.
But they all boil down to one thing:

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. -Scrum Guide 2017

The questions above are really just there to help see the forest for the trees.

This article as been written with generous help and editing courtesy of Maarten Dalmijn, Sjoerd Nijland and Scrum Rebel. Click their names, they write great articles!

If you’ve enjoyed yourself, give me a slap, I mean clap. This is my first article, and it would mean much to me ;)

Do you want to write for Serious Scrum or seriously discuss Scrum?

--

--

--

Content by and for Scrum Practitioners.

Recommended from Medium

What is the best practice of docker + ufw under Ubuntu

A little investigation on the Largest Contentful Paint metric

2020.05| Genaro Network (GNX) Monthly Technical Report — May

Unity3D Testing and Learning#1 (part 1)

How To Make A Digital Clock in Python

7 Ways to Earn Money From Coding and Programming

GoLang — Jumping in the code using goto

Don’t Fall for the “Autonomous Database” Distraction

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Max Heiliger

Max Heiliger

Scrum Master, Emancipator, Pressure Cooker. https://www.linkedin.com/in/max-heiliger-478b0614a/

More from Medium

In-Depth: How Coherence And Cohesion Are Critical To Scrum

Scrum Master as a Conflict Navigator

Trending retrospective activities

A line graph of retrospective meetings per month for the period April 2021 -mid April 2022. Two milestones marked on graph, for December 2021 and April 2022

It’s actually OK to be a Scrum Purist, and this is why!