Let’s talk about impediments. “A hindrance or obstruction in doing something”. From the Latin impedire, to shackle the feet of. A thing that slows you down or keeps you from moving forward. Simple as that.
And yet every day I go to stand-ups or Scrum of Scrums meetings and I hear people go around the room: “No impediments.” “No blockers.” Really? There’s nothing standing between you and your ideal flow state where you code, test, or write stories all day in your dream office on your dream machine with no interruptions and churn out only the best bug-free features with no tech debt and no escalated support calls? Are you guys hiring? I wanna come work there!
Often when people say they have no impediments they mean that they have no unusual impediments. Or they mean that they have none that they think anyone can do anything about. Other things that keep people from reporting impediments:
- They’re embarrassing: “We’re about to do some Angular and I don’t know anything about it.”
- They involve interpersonal dynamics: “There’s a person on the team who won’t explain their code to me.”
- They involve money. “This laptop is too slow.”
I have a true story about that last one. Read it and let me know if that changes your mind about handling impediments.
So … slow.
When I train Scrum Masters I always stress their role as impediment removers. Some take naturally to this part of the job, while others need some assertiveness training. I myself tend to naturally avoid conflict so I often have to remind myself to practice what I preach and not shy away from the hard problems.
Anyway, there once was a newly minted Scrum Master who was very gung-ho about the role and almost immediately let me know that his team’s top impediment was that their laptops were too slow. I agreed and pushed a request for faster laptops up the chain. And … not in the budget. Also, I was told, the machines aren’t too slow: the teams have designed an app that’s too complex and thus puts a strain on the machines when running locally. Which was true to an extent, but not that helpful in the short term. I tried to push it a bit but got a very firm answer again: this isn’t going to happen. Make do.
Reader, I’m embarrassed to say that I gave up at that point because, well, that’s just how things are around here. But my Scrum Master trainee didn’t. He started to collect data from the teams: mean time to open the application in the IDE, mean time to start debug mode, mean time to run all the unit tests, and so on. He made videos. He showed them to people. Eventually he found the company’s employee suggestions site and wrote a long and compelling case for better laptops, which included calculations of the cost of lost productivity versus the extra cost of a fast machine. He then started networking with developers on other product lines and in other offices and got them to all go vote for his suggestion, which then became the #1 hot item on the suggestions site.
This got him an audience in front of the executive team, which was delayed but eventually happened. Between this and some cajoling of a new development director, the first new and souped-up machine finally arrived. Benchmarks showed it did indeed cut task times by a huge amount and as machines aged out they were replaced with the new spec, which made its way to the IT department as the updated company “performance laptop” standard.
This entire process took close to a year if I remember correctly. The Scrum Master did not get a fat bonus or much official recognition for this, but I’m going to go out on a limb now and say that was one of the all-time legendary impediment removals. No mandate, no seniority in the company, just good old-fashioned stick-to-it-iveness.
Are You Fighting That Hard For Your Teams?
As a Scrum Master. impediment removal is one of the single best uses of your time once a team is up and running with the basics of Scrum. You are directly targeting waste and by doing so increasing your team’s velocity and most likely its morale. Also, if you’re not a technical member of the team, you’re gaining the team’s appreciation and respect and helping the organization see the value of the Scrum Master role (Hey, it’s OK to have a selfish motive thrown in there).
Don’t get me wrong – it’s not always easy to solve impediments. Many times even getting the team to recognize and raise them takes quite a bit of creativity and effort. But don’t let that stop you. You’re a Scrum Master – Master of Scrum! So use your Courage and Commitment – two of the five Scrum values – and dig into those impediments. What are you waiting for?