A Daily Scrum in the Cave
Your team can’t change what they can’t see
Plato’s Allegory of the Cave has influenced culture ever since its inception in 380 BC. From early philosophy to The Matrix, the idea that there is a world beyond our own, one just beyond the reach of our senses, has both fascinated and terrified people.
If you’re not familiar with the allegory, the basic premise is this:
People are chained to a cave wall, deep underground. Their bonds restrict them so that they can only stare at a wall, and all they see are shadows, thrown by a torch out of their field of view.
Over time, the people assign meaning to the shadows, and argue about who knows the most about the shadows, and what they mean. But at some point, they get out of their chains, turn around, and realize that what they have seen was nothing but facsimiles created by the torch.
So they do what every reasonable person would do:
They start venerating the torch.
The torch has been the source of their truth, so it must be truth itself, right?
Well, eventually, they notice a draft and find an opening in a wall. They climb upwards in a long, arduous journey, until they reach the outside world. There, they are confronted with another realization: Things such as color and living animals exist. And they are able to see all those things because of the sun, which they call “the grand torch in the sky”.
The allegory ends with the men returning to the cave to teach those they have left behind about all they have seen, and to invite them to come up to witness it for themselves. …I have worked as a Scrum Master long enough to know that they probably got their request denied by Cave Management ;)
I won’t go too deep into the philosophical arguments here. Smarter people than me have thought about it far more than I have. But if you ever found yourself wondering why your team just isn’t into Scrum, or XP, or Automated Testing as much as you are, the answer is probably:
They are sitting in a cave, mistaking shadows for truth.
Well Max,” you say. “That is all fine and good, and you are very smart, but what can we do about that cave thing?”
Thank you. I am very smart. Smart enough to get a Master’s degree in English, instead of one that actually matters.
But let’s talk about your whole cave situation instead.
Maybe your team is very inexperienced and doesn’t know best practices. Maybe your team is unaware of their own social shortcomings.
Maybe your team isn’t motivated, and works just as little as it has to.
Maybe your team is literally chained down in a basement, and has only seen nature on the Windows XP desktop background for the last 25 years.
In the latter case, you should probably switch Operating Systems. Windows XP is no longer supported by Microsoft.
It’s a security risk.
You should also either call the cops or organize a social outing for your team. Maybe go play lasertag though, they don’t seem to be very good at escape rooms.
Jokes aside, all these scenarios boil down to one thing.
People need to change, but they don’t feel the need to because they don’t know the benefits of change.
If you find yourself in this position, there are a few steps you should take.
1.Make sure you have actually stepped out of the cave yourself.
You can’t lead anyone if you don’t know exactly what you’re going towards. Worse, don’t lead your team to worship a torch because you think it’s the sun.
Do your homework. Check out other Scrum Teams. Don’t stop before you can get no further. Get all the pros and cons of the approach you want to try, and know how to present your idea in a way that communicates those pros and cons clearly.
Ask yourself if what you’re doing is of actual benefit, or if you’re just doing it for the sake of doing something. I often just throw stuff against the wall and see what sticks when I feel powerless, but that’s a terrible habit that drains the focus out of teams. Instead, make sure that what you’re proposing doesn’t just lead into another dead end, and be aware of the risks.
2. Make sure that your team is actually willing and able to leave the cave.
Imagine you’re coming down from the real world, all excited about nature and the sun and stuff.
You tell your fellow cave dwellers about all those cool things you have seen.
… And they go: “Wow, thanks, but we’re still friggin chained to a wall, Steve.”
Don’t be Steve.
What I mean is: Before you present your idea to your team, make sure that they are ready for it. Is now really the right time? Do they have more pressing issues? Can this wait? If so, just have patience.
Are there impediments that prevent your suggestions from becoming real? If so, get those out of the way as much as you can before you pitch your ideas to the team. Go get that new server green-lit, and secure funding for that seminar you want to take together. Start an Agile transformation, break up structural silos, review incentive structures, redesign the way your org finances its endeavors. Whatever it takes.
However, if for whatever reason your team is absolutely not into it, make sure you’re not just pumping time and energy into a structure that vehemently resists change.
3. Foster the desire for change.
Let me be absolutely clear here, because this is the crux of this article.
There can be no adaptation if your team does not even know what to adapt towards, or worse, does not feel the need to inspect.
In the beginning, especially in the shu phases of your scrum adoption, that means that it is often the Scrum Master’s job to make impediments that hamper change transparent.
Some change is easier to foster than others, but the basic strategy stays the same. You find out where something doesn’t work, make the cost of it visible, then ruthlessly dream a better reality that your team can buy into.
If your team isn’t practicing high-end engineering techniques such as TDD and Continuous Integration, it’s your job to show how it slows them down and wrecks their nerves with constant problems. Tell them about the world outside the cave. Tell them how their reality COULD look, if they adapted these new practices.
Then ask them if they would like that. If they say yes, work with them to make that vision a reality.
If your boss/manager insists on hiring cheap, inexperienced devs straight out of college but refuses to hire more expensive senior developers to teach them anything, make visible the cost of this lack of investment, then explore the benefits of another approach together with management.
Coincidentally, this is why having clear Sprint and/or team goals and a vivid product vision are so important in Scrum. They give people something greater to aspire to. As a Scrum Master, fostering that sense of accomplishment, focus and determination is one of your most crucial duties.
It is also one of the most efficient ways to foster change.
Your team is being kept in chains by their lack of awareness about what they can achieve.
It’s your duty to free them of those chains. Be their fan. Root for them. But don’t allow them to be anything but the best version of themselves.
If you manage to get this right, and your team is highly motivated, they will self organize and eventually ask the right questions themselves. So your ultimate goal is to get them to a point where they look up, see the sun and go “So what’s beyond that?”
And you: Inspect what you know. Remember, there’s always a bigger cave.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. You can clap up to 50 times if you really valued this episode. I am also very keen to learn what you think about this topic.
