Being blocked (a phrase used in project management, especially software development in agile teams) typically means there’s something external, outside your control, that is preventing you from making progress in a particular task or project. When this is the case, it can be frustrating, but some blockers are almost impossible to get around.
Think about bringing a new person on the team and bringing them up to speed with the codebase (which will inevitably take some time), or contacting a third party who has long reply times.
There’s all different types of blockers. Some blockers can’t be solved for. However, some can be. Think about technical blockers, which typically happen when developing or planning a solution in software, and you’re having trouble progressing. Unlike dealing with an external entity that is largely out of our control, we’re really only dealing with ourselves here.
Don’t get me wrong, not all blockers are like this. Regarding technical blockers, you might be faced with technical debt or architectural problems that really do need your attention and take time away from deadlines because that’s ultimately what’s best for the project. There’s a fine balance between quality and producing what you require as fast as possible.
Let’s break this all down. What does being blocked actually look like, and what are some actionable tips for ensuring good flow in a project?
What does being blocked or impeded look like?
A quick note, what I’m mentioning isn’t necessarily industry standard or anything, but a practical approach to the way I, personally, see blockers. Some can potentially be solved quickly, some probably can’t. Ultimately, to stay productive, we want to try to identify when we’re blocked but also what type of block we’re experiencing.
A lot of my experiences are project management in the eyes of a software engineer, but I’m hoping they apply broadly to other roles.
External blockers
I see external blockers as true blockers. At the end of the day, if you’re relying on a third party to complete something, and it’s a must-have, there’s probably not much you can do in a practical sense.
A good example of this is a SaaS (software-as-a-service) provider that you’ve made an agreement with, but doesn’t offer exactly what you need.
With some blockers that last a few hours or days, or when you have obligations, it’s not really sensible to entirely change around your approach just to get around one thing.
External blockers give you a good opportunity to pick up new work though to keep up the general flow of the project, ideally work with a turn-around rate that is within the timeframe you’re roughly expecting to be unblocked in.
In a complete worst-case scenario, you can try a few other pragmatic actions:
- reducing the scope of the project to avoid particular requirements leading to the blocker
- increasing the scope/time-frame of the project, and looking into developing your own solutions to avoid an external entity
Internal blockers
Internal blockers occur internally within an organisation or team. Common internal blockers include:
- new people coming on the team
- dependencies, such as approval from teams that take longer than planned
- communication break-downs or misunderstandings
- technical problems, like needing to address a severe problem in a different area of the project, taking time away from what you’re working on
A lot of these blockers boil down to the need for more planning. Playing devil’s advocate, there’s also a downside to over-planning if you have a strict deadline. If you’re trying to get something done in 3 months, you typically don’t want to spend 2 months planning.
It also comes down to resource and priority management within your team; making sure you’re not spending too much time doing things that don’t bring value to the final results of the project.
Personal blockers
This is where you can often put power in your hands and take action towards blockers.
There’s the argument that a personal blocker isn’t really worth noting down as a blocker, but the truth is, we’re all human, and occasionally, we unintentionally go down a rabbit hole, get stuck, or have many priorities.
Some examples that come to my mind for personal blockers include:
- up-skilling yourself for a task, like navigating around a new service or diving into areas that you’re not super knowledgable in
- getting stuck on a certain problem to solve some requirement for the project
- focusing attention in areas which aren’t directly contributing to the end goals for the overall project
- time-management and task-management
It’s true that even some personal blockers take longer than we might expect to get around. But often, I find with personal blockers, there are a few key things I ask myself:
Is there a different, sensible approach to get to the same solution?
Sometimes, we need to settle with a solution for the sake of time that works now, but we might want to change down the line. This can lead to technical debt – and though you don’t want too much, a little isn’t bad. Don’t overshoot for perfection, especially with a strict deadline.Is there a quicker way to do this?
Instead of doing something manually, could I automate it? If it’s practical, could I get the help from somebody else to solve this faster (through pairing or reviews, for example)?What resources are available to me to get around this blocker?
Such as asking team members for help, getting in touch with a support person, looking online for documentation to get clarification, etc.
Actionable tips to unblock you and your team to keep moving forward
Identify if you’re blocking yourself
Often, the first thing I’ll do if I’m blocked is try to see if I’m actually blocking myself, as mentioned earlier. If you are, set out to follow a series of logical steps to find a way to unblock yourself.
Ensure you’re not spending too much time in a certain area, and keep track of your personal flow to find room for improvements. Remember – it’s always okay to ask for help!
Allocate strict time/effort resources, like a budget
You want to avoid spending too much time in the wrong areas. Use tools like time boxing to ensure you’re allocating a specific amount of time to certain tasks, or a system like story points to know ahead of time the amount of effort, risk, or complexity involved with a certain task.
As a last resort: work through a different problem
There are a few benefits to picking up new work to get around a blocker in existing work. There’s some research around the fact that taking a break can help you find the solution to problems quicker, and I’ve personally found this to be true when working through a different problem. Usually, I’ll be able to come back to the original work that was blocked and see with “clearer eyes” 👁
The main thing to watch out for is team bandwidth, which tracks how much time team members actually have to complete tasks given other priorities they’re already working through. In other words – you want to avoid overloading anyone.