In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice.
In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice.
And, what if you aren’t doing Scrum, or you’re transitioning to agile and you don’t yet have a self-organizing team? Maybe you have an agile project manager. Maybe you have a team facilitator. Not every team needs a titled manager-type, you know. (Even I don’t think that, and I come from project management.)
Maybe the team bumps up against an obstacle they can’t remove, even if they try. Why? Because the obstacles the team can’t remove tend to fall in these categories:
- Cross-functional problems across several teams or across the organization
- Problems up the hierarchy in the organization
- Problems that occur both places, as in over there in another department and higher up in the hierarchy
Oh boy. Someone who either used to be technical or used to be a first-line manager is supposed to talk to a VP of Support or Sales or the CIO or the CTO or “the Founder of the Company” and ask for help removing an impediment. Unless the entire organization is already agile, can you see that this is a problem or a potential problem?
Chances are good that during an organization’s transition to agile, the team’s facilitator (regardless of the title) will need help from a more senior manager to remove obstacles. Not for the team. For the rest of the organization.
Now, I would love it if the person who is supposed to remove obstacles was that designated facilitator (Scrum Master, agile project manager, whomever). And, that designated facilitator had the personal power to do it all by him or herself. But, I’m a realist. In my clients, that doesn’t happen without management support.
Is it a problem if a manager removes obstacles?
I don’t think so, as long as the manager supports the team, and doesn’t prevent the team from solving its own problems.
Here are examples I would expect the team to solve on its own:
- Not finishing stories inside an iteration because there is too much work in progress or each person take his or her own story. This is a problem the team can manage by reviewing the board, or by pairing or swarming. The team has many options for solving this problem.
- Too much work in progress. Again, the team can often manage this problem. The first step is to see it.
- Not getting to “done” on stories. The first steps are to make the stories smaller, to make sure you have acceptance criteria, to work with the product owner on making stories smaller, those kinds of things. Maybe the first step is to make sure you have integrated testers into your team. But that might require managers to help.
- Having trouble deciding what team norms are and the resulting issues from that.
Here are obstacles mid-level managers or more senior managers might help with:
- Creating cross-functional teams, not silo’d teams. I keep seeing “developer” teams and “tester” teams being told “Go Agile!” No, agile is a cross-functional team where you have all the roles you need on one team to accomplish the work. This misconception is often a management misconception.
- Which project is #1 (managing the project portfolio). If the team has a ton of interruptions or a demand for multitasking because management can’t decide which project is #1, I would expect some manager to take this obstacle on and resolve it. The pressures for multitasking or interruptions often arise from outside the team.
- How the organization rewards people. At some point, agile bumps up against the culture of individual rewards. Managers might be the ones who need to manage HR.
- When the product owner goes missing, or the team has no product owner. The team is now missing a key piece to their success and what makes agile work. Very few teams can demand a product owner, especially if they are new to agile.
This is a form of management as servant leadership, where the manager serves the team.
Do you see how certain problems are inside-the-team problems and the team can solve them? Other problems are not inside-the-team problems, and are part of the organization’s system. The organization needs to decide, “How committed to agile are we?” and address these issues.
| Reference: | Who Removes Your Obstacles? from our JCG partner Johanna Rothman at the Managing Product Development blog. |
