A recent project delay at work put me in mind of this recurring issue I’ve seen with a lot of agile teams. That is, reluctance to call something a blocker. Karthik and I are working on a new revision of our LinkedIn Learning courser “DevOps Foundations: Lean and Agile” so I decided to dig into this a bit.
I think many engineers believe a blocker is “something that prevents me from doing any work whatsoever on this entire project.” This in my experience leads to a lot of project delays and unaddressed issues because something was not identified and communicated widely enough to be swiftly resolved.
This is unfortunately encouraged by some Agile wonks who start hairsplitting with terms. “Well, there’s a blocker and then there’s an impediment,” they say. As I google this, it turns out you can differentiate between “delays, impediments, blockers, and roadblocks. Oh, and dependencies.” And boards, reports, etc. have to do/in progress/done and blockers, not 10 other categories.
Here’s the deal. Most teams out there are not formally trained on PM or agile and have essentially figured out what they know via osmosis. And there’s one term they even vaguely understand, which is “blocker”. (I have never seen a team distinguish formally between blockers and impediments in decades of doing this.).
While I love wordplay as much as the next person, I don’t think this attempt to categorize bad things on the infinite spectrum of bad things is practical, and best belongs as an organic explanation of the impact. Does it prevent you from proceeding on that piece of work? On any work? You can proceed on it but it can’t become done until the thing is resolved? Or it doesn’t technically stop work but it does put the project a week behind? Sure, say it. It’s important to know the impact but it does not change the nature of the existence of an issue and the need to swarm on or escalate it.
The practical definition of a blocker from a team member level is “anything not entirely in my control that is stopping or delaying work now or in the very near future.”
The practical definition of a blocker from a management point of view is “anything that is getting in the way of the team that I need to know about or do something about.”
We have to go back to the entire reason to have a term like “blocker”, which is to allow the team, or failing that their management escalation, to resolve issues that prevent the continued timely flow of work. Period, end of story, if process definition hairsplitting isn’t serving that core goal then do what does.
Definition people love to say something’s not “technically a blocker – yet.” “Well not having a cloud accout to use as the required test fixture isn’t technically a blocker because I won’t need it for another two days, even though there’s been no obvious headway on the request we made to IT for it.” Can anyone seriously contend that’s not a blocker? It’s a problem that is clearly visible on the road ahead, you don’t have to run into it first like my cheap Roomba does in order to escalate it, and doing so is antithetical to the overall agile goal of ensuring smooth and continuous flow. I don’t tolerate “technically true” when it becomes “wilfully dumb.”
Underlying this seems to be some unstated assumption that blockers are “bad” and you are bad for having one or reporting one. And I get it, there’s plenty of bad scrum masters/managers/etc. out there that operate unthinkingly on some Neanderthal level and react as “person say thing I don’t like, person is bad.” (Or the modern tech bro Neanderthal who has some variation of this like “well I need to discourage people from reporting blockers to make them use their masculine energy to pull themselves up by their bootstraps blah blah.”) Sure, toxic people can drive any process off track, that shouldn’t be the default however.
I believe in a healthy Agile environment team members should be encouraged to bring up anything threatening to slow or stop work. It can be a small thing, but it creates an opening for help from the team. Even “I haven’t used this tool before and it’s taking a little longer and I am not sure I’ll get this task done by sprint end” – that’s an opportunity for someone to hop on for a half hour to pair with you or train you.
If you’re off schedule there’s some blocker around, whether it can be handled in the team or needs escalation. You don’t have to escalate everything, though even if the team handled it, schedule or other impacts need to be communicated. For escalations, make it clear it’s an escalation and who to, don’t just assume everyone who gets a status report will seize on all the blocker lines as to dos. “Blocker: No headway on Azure text fixture, it’s needed to complete our work this sprint and will delay us if it’s not in place in 2 days – @ernest we need your help with this one” is perfect.
As someone providing oversight for a lot of sprint teams working on consulting engagements often with client-prescribed milestone deliverables, I keep getting into situations where a sprint full of reporting “no blockers” suddenly turns into “well but of course we won’t have any of the deliverables at sprint end tomorrow.” That makes everyone unhappy, especially me if it’s something I could have urged the client or an external team to provide for the team more promptly. Give people the opportunity to intervene to keep you on track!
I’m going to start adding “definition of blocker” right after “definition of done” in kickoff discussions because of how chronic this issue is – I venture to say I’ve seen it everywhere, it’s just more tolerated in environments where schedules aren’t taken too seriously.
Let me know how you handle this issue, if you encourage a wide definition of blocker, and your experiences on this!
the agile admin 