If you are familiar with the Scrum Master role, you may also be familiar with this part of the service to the development team.
“Removing impediments to the Development Team’s progress;”https://scrumguides.org/scrum-guide.html#team-sm
It’s an extremely important part of the role, but one that, to be honest, any mature Scrum Team can do by themselves. Going back to yesterday’s post Transparency Beacon. If your team knows exactly who to talk to about the majority of the problems they have, then there is no need for you to intervene.
The Minority of problems
What about the minority of the problems they have?
Usually, on engineering teams, the majority of their impediments are “engineering impediments”. That’s just part of day to day work. But about the other impediments?
I would argue that the minority of the team’s impediments will be organizational. Engineers will not feel them as often as the others, but they will be there, lurking and impacting day to day activities in the background.
These kinds of problems can have major impacts in the long run, but not that visible in the short run. Small things with a big impact.
When the minor becomes the major
In November, we had a couple of days together with all the Scrum Masters in our company. We call it Agile Days (awesome day BTW). Here, we all had a chance to chat with our colleagues from all over Europe (Slovakia, Poland, the UK and us from the Netherlands). A big diversity of cultures, people and ideas.
During these talks, one of the challenges that was proposed to us by our VP of Software Engineering was:
“What can you do as a group to help the teams deliver faster?”
It as an awesome challenge, and the reason why most of us do what we do.
After a couple of minutes of brainstorming, we started to realize that whatever we did, at a team level, would have little to no impact. We could try and fix a couple of problems with the teams to help them deliver faster, but by our estimation, only 10%-20% of the overall lead time was on the engineering teams.
We quickly realized that some minor organizational problems we had at the team level were major organizational problems in the overall scheme.
Stepping way out of the Forest
There is a metaphor that I love about Scrum.
Imagine our team is a team of lumberjacks. Their job is to cut trees. Simple as that. The Scrum Master cannot be inside the Forest cutting the trees. He/She needs to be able to see any lumberjack in case they need assistance or help. This way you can remove any impediments that the team may have on their daily work. The Product Owner should be a bit further. He/She needs to see the whole forest so that he can plan where to cut next. If we need to move to another part of the Forest and let that one grow. Organize pickups of material, etc.
You get the point. Your team can be a mean, lean, oiled out machine. But what if 80% of the time it takes for your lumber to get to the customer is outside of your operation? In that case, it’s time to step out of the Forest and remove those Barriers.
If you have been in this industry for a while you know that in the majority of the companies, the majority of the issues lay outside of the engineering teams. These take all flavors, from bureaucracy to outdated tools and even mindsets/ways of working.
This is where we are most needed and where we can make the biggest impact. Removing these barriers and becoming more agile.