If you’re a scrum master or agile coach or delivery lead or [your agile professional title here], then one key part of your job is removing obstacles. This is a topic that doesn’t get much play in professional discourse and for obvious reasons -- it’s hard to classify.
Obstacles come in an infinite number of forms. We could start a classification list, but it’s very possible that the next obstacle you encounter won’t fit into any of them. We could make the case that there are two broad categories -- people and systems -- but even that can get fuzzy. Very often, systems based obstacles end up being people based in the end.
So rather than dwell further on classification, let’s explore the act of removing them. If you are a leader being asked to remove an obstacle for another person or group, it is undoubtedly because they couldn’t remove it themselves. Depending on your position in the organization, you will face different challenges. Let’s start at the top.
As a senior leader, when obstacles bubble up to you (as mentioned in this article), your first obligation to supporting your organization’s agile journey is whether you are the right person to remove the obstacle. Notice I didn’t say “IF” you can remove it -- rather, whether you “SHOULD” be the one to do it. Making this determination will require some judgment on your part.
For example, let’s say that you are the executive vice president of engineering and someone from a team comes to you and says that they need another engineer on the team to meet the organization’s expectations. At your level, you COULD absolutely move the request forward. In doing so, you would likely damage any trust that you built with the resource manager (or director) between you and the team.
The better option might be to inquire as to why the team member has chosen to come to you. This is a great opportunity to gain feedback about potential dysfunction within your organization. There may be “reasons” why this individual chose to come to you and uncovering them will inform actions for which you are responsible. So, rather than remove the obstacle, you gain an opportunity to fix a systemic problem.
Let’s assume that the person who came to the EVP of engineering was a team’s agile delivery lead (ADL). As the ADL of the team, your job is to remove obstacles, but that doesn’t mean you can always do it alone. However, before seeking help, don’t be too quick to let your team off the hook. Needing more resources is often the easy way out of needing to do more in less time. There are lots of ways to address this issue and adding resources should be the last thing you do. In fact, if I were a good resource manager, I’d want to know what the team has tried to improve on their efficiency before even considering a request to add people to the team.
Removing obstacles like this one often means making short term trade-offs for long term benefit. Sometimes, leaders want to be able to have their cake and eat it too. As an agile professional, your job is to convince them otherwise. The art of influence is another whole topic that I have discussed and will do so again. In my own experience, deadlines are rarely externally imposed. They are manufactured to create a sense of urgency. There’s nothing inherently wrong with this practice, but it’s important to recognize the difference between a hard deadline and a preferred one. To be sure, it is quite likely that other teams will be coordinating around a manufactured deadline and changing it could be an inconvenience (maybe even a major one). That’s always a consideration. However, one of the basic tenets of agile practice is that you can’t fix scope and timeframe. Removing obstacles can change scope -- sometimes dramatically. Some leaders will need to be reminded of this.
Some obstacles center on individual behavior. In these cases, having built a high level of trust makes the necessary feedback possible. This is why building trust is so important. Today, you might get by without it, but when the moment comes that you need it, if it’s not there, you are…screwed! Trust takes time to build, so if you don’t have it, start NOW. Make sure it’s there when you need it.
There’s no way to adequately cover removing obstacles in a short piece and I don’t want to run afoul of your TLDR sensors. So, I will stop here. As always, I’d be happy to chat more about this or any other agile practice topic with you free of change, obligation, or pressure. Just book some time with me here.
Comments