It’s common for some new agile teams to blame the new approach for making things worse. What’s really happening is Scrum is showing them their existing problems more frequently.
When I first started at one product organisation they’d made the decision to use Scrum. They’d been using it for over a year across hundreds of teams but weren’t getting the pace of delivery they expected or needed.
The leaders from the private equity firm hired me in to fix the pace problem. The first thing I did was talk to the teams about what they thought the problems were.
“So you’re the agile product guy huh? Well, Scrum sucks we want to use something else.” Was how I was greeted by a large number of teams. Teams were saying that Scrum was causing them more problems than the ad-hoc way they’d worked before.
After some investigation, a common theme emerged. The teams were turning up every few weeks to the Retrospective and having a conversation that went like this:-
Scrum Master: “What didn’t go so well?” Developer 1: “The build server has been down more than up again this week.” Developer 2: “We’ve sent the logs to the Magnus again but he’s not come back to us.” Scrum Master: “Magnus is pretty busy right now, not surprising he’s not responsive.” Developer 3: “Talking about on-going problems we’ve still not got enough space for the team. When’s that going to be sorted?” Scrum Master: “I’ve asked facilities but they’re in the middle of looking at the whole office and so we’re caught up in that.” Developer 4: “This has been going on for weeks. We can’t ship code if our build servers falling over and we’ve no space!” Developer 1: “This meeting is a waste of time. All we do is get together to discuss all the things that still aren’t fixed! We should drop Scrum and go back to the way we used to work. At least we didn’t have all this wasted time in meetings.”
At the end of every sprint the team was facing into everything that hadn’t been fixed from previous sprints plus any new impediments that had come up in the current Sprint. All they could see was an ever growing list of impediments.
The Agile Mirror
Unlikely waterfall or their previous process, Scrum was making them look in the mirror frequently, and things didn’t look pretty. Scrum was working perfectly. They just couldn’t see it. Scrum’s process feedback loop was showing them all their impediments. The real problem was no one was fixing the impediments.
Typically in small organisations, once the teams realise this they go fix the impediments and things get better. This wasn’t a small organisation. Many of impediments were systemic issues such as the Change Approval Board only meeting every two weeks.
This is where we re-engaged the managers. Up until this point the organisation had fired most of the managers. Those that remained had little idea what their role was. We explained to managers that one of their key roles was to help by removing systemic impediments.
As soon as the teams and the managers started to remove the impediments Scrum was highlighting the organisation began to unjam. Products began shipping faster.
Avoid Rotten Impediments
So the length of a teams impediment list, the sell by date of the items and the last time the list was refined are useful health metrics.
A rotten impediment list can be a sign that:-
- The team hasn’t taken responsibility for addressing their own issues
- The managers are not addressing the system impediments
The great thing about Scrum is the Retrospective exists specifically for teams to address this issue.
Managers, you should be helping the team to remove the impediments the teams can’t.
Use Scrum as the answer rather seeing it as the problem.