How company culture can impact Scrum adoption
3 entities, 3 different cultures — survival of the fittest, the helicopter parent, empiricism
3 entities, 3 different cultures — survival of the fittest, the helicopter parent, empiricism
I know a company that has three entities with Scrum Teams. The interesting thing is that there is a certain pattern in how Scrum was adopted at these entities. Surely teams per entity also differ, but still the pattern is there.
Entity 1: adopted Scrum, but “Product” calls the shots
Entity 1 adopted Scrum, but there’s one catch: “product” determines what goes in the Sprint Backlog. This is often the Product Owner, but sometimes his or her manager is the one that blocks experiments, improvements from the Retrospectives and technical improvements on the code.
The Development Teams can state their capacity for the Sprints, but still some PO’s like to add a bit more, which then often happens. And then the Sprint Backlog is considered to be “signed with blood”. The Development Teams will work overtime and cut corners to “make the Sprint”. They are happy when they burn all the points that they planned to deliver. That is their main driver.
Scrum events are not always conducted. They are seen as nuisance. Especially the Sprint Retrospective is a copy of the previous retros. This is quite logical, because if nothing improves you will stumble into the same issues again and again. But also the Sprint Review is sometimes skipped, especially when the Sprint is in “danger”. The extra time is used to burn the last points.
It’s delivery, delivery, delivery.
The Development Team doesn’t own the Sprint Backlog and the Product Owner often doesn’t own the Product Backlog.
This is how the Scrum Teams feel:
Constantly under pressure to deliver.
Caught in a time-loop. Every Sprint is basically a copy of the previous Sprint.
The teams feel they have nothing to say about the planning of their own work.
The teams are unhappy to deliver crappy solutions when they have to cut corners (again), knowing that they will have to revisit the solution later.
Entity 2: adopted Scrum, manager protects the team for mistakes
Think of parent that forbids kid to run or climb a tree because they could fall. Entity 2 has this type of a manager. The manager is a helicopter parent. This is an entity where no-one does anything out of the ordinary without consent of the manager.
The teams at entity 2 are allowed to determine what goes on the backlog. There are no issues when the Sprint is not made. It seems like a safe environment.
But experiments are considered to be dangerous. What if you’d fail? It will bring needless emotions and disappointment. It’s best to simply be cautious with experiments.
Maybe the environment is a bit too safe? Now teams take baby steps or experiment without consulting the manager which feels like cheating. On second thought, maybe this isn’t a safe environment at all! People don’t have the courage to be open.
So the teams at this entity:
adopted empiricism — transparency, inspection, adaptation, but up to a certain safey-net point.
ensured that the Scrum Team is self-organising, but up to a certain safety-net point.
adhered to the clear roles and responsibilities of the Product Owner, Development Team and Scrum Master.
are very predictable.
are reluctant to try new sings, always play safe. This is why they only take baby-steps on improvement.
many of them feel like they are constrained.
have a shaky relationship with Scrum Values: courage, openness, commitment, respect, focus. I already tackled courage and openness, but there’s more. Does the manager respect the team members? Do they in return give respect back?
Entity 3: embraced empiricism
Entity 3 embraced Scrum. They felt they understood why Scrum has the roles, the artifacts and the events. And they believed in it.
This meant that they:
adopted empiricism — transparency, inspection, adaptation
ensured that the Scrum Team was self-organising
adhered to the clear roles and responsibilities of the Product Owner, Development Team and Scrum Master
welcomed experimentation and always looked for ways to improve
followed the Scrum Values: courage, openness, commitment, respect, focus.
This wasn’t always easy. There were quite some stakeholders that did initially not understand what Scrum entailed. They:
tried to bypass the Product Owners to influence the Development Team to pick up work that wasn’t initially planned
put pressure on the Scrum Teams to work on delivery, not on improvements.
put pressure on the Scrum Teams to constantly deliver more than previous Sprints.
tried to force the Development Teams to work in a certain way.
These stakeholders did initially cause quite some unrest within the teams, but in the end did not cause disruptions. This was because the Scrum Teams kept reminding the stakeholders what Scrum is about. This didn’t only come from the Scrum Masters, but also from the Product Owners and the Development Teams.
Now, a year later, the Scrum Teams at this entity established at lot:
The Development Team feels they are respected. The stakeholders accept their decisions.
The stakeholders see that the teams deliver. They can count on the teams.
The Scrum Teams are motivated as they are in control of their own experiments and learning journey.
Bottom Line
Three entities of one organisation all started to use Scrum at the same moment. They also got similar training and coaching. The culture at the entities did have a major impact and as a result you can observe different directions to implement Scrum. Two entities are still dealing heavily with Scrum anti-patterns. One entity is doing quite well.
If you adopt Scrum you should adopt it completely. There’s a reason for the roles, events and artifacts. You can’t simply skip or change things and then expect to still have an effective Scrum adoption.
I can certainly imagine that you’d wish to tailor Scrum to your needs. But be aware that the results might not be what you expect. Most of the time you lose something valuable that you would have with a full Scrum adoption.
Meanwhile the Scrum Master and others from the third entity are showing the other entities how they work and how it benefits them. They wish to inspire the others. But just because entity 3 did it right for them thus doesn’t mean they are automatically the right coaches for the other entities. Also: the other entities will not change their ways until they acknowledge that they have issues. Especially “product” at entity 1 and the manager at entity 2 think everything goes well. It will take some time but I am convinced they will have to acknowledge they erred so that they have to change at some point. But it will not go overnight. Changing culture is a lengthy process.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
My twitter profile is https://twitter.com/WJAgeling
Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!
We run a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts.