Blockers and Priority

One particularly large client I recently dealt with was struggling to get their teams to meet their delivery commitments. It appeared that in every sprint they lost significant time to blockers, in some cases causing them to miss a commitment by as much as 50%.

This was a large project spanning multiple teams, of the order of about 800 people in total across development, test, product owners etc., with an estimated duration of more than two years. The impact of a consistent 50% delivery rate would literally break the budget, the customer, my client and probably the project.

A little analysis identified the problem to be rooted in the silos into which the teams were organised. In this instance, the silos were pretty rigid with poor communications between the teams. That lack of communication fostered an environment where blockers could emerge and live for extended periods of time.

Blocker Guidelines

When helping organisations to transition between processes, you often have to go to their side of the fence first and bring them with you. That was the case here, where their traditional models were very explicitly defined, to the point where everybody had an expectation that every process was documented precisely. To meet that expectation, I ended up developing some quick guidelines for managing potential blockers that looked something like this:

Defining a blocker

A blocker is any impediment that exists because of a team other than your own; it’s assumed that this impediment is stopping work in the current sprint. Blockers must be highlighted to your Scrum Master at the earliest possible opportunity. The initial purpose of the escalation is to notify provide visibility on the issue, not to get the Scrum Master to immediately deal with the issue.

Managing blockers

Blockers are your problem, as such you must make every effort to clear the blocker yourself before you delegate the problem to your Scum Master or beyond. It’s reasonable to escalate, and as a result delegate responsibility to your Scrum Master after 2 working days. This period may be shorter depending on the length of your development sprints.

Irrespective of who is dealing with the blocker, the issue must be raised with the team that you are depending on. The blocker exists because they didn’t deliver on some piece of functionality. In response to raising the blocker, you should expect an update within 2 working days.

Responding to a blocker

When a team is informed that it is blocking another team, it is responsible for accurately communicating how it is going to deal with the blocker. The team must be clear on when it intends to deal with the issue so that the full impact can be established. Communication and the appropriate establishment of expectations is crucial to achieving the necessary clarity.

If a blocker gets raised to your team, you should respond to that blocker in under 2 days. Your response should fall into one of the following categories:

• A complete rejection of the blocker at which time, unless the team raising the blocker agree with the rejection, it must be escalated to the product owner for resolution
• Acceptance of the blocker; you must supply an ETA for it to be resolved
• Acceptance of the blocker but with no ETA, then as before this is no longer a blocker for your team, which must follow the same steps as previously detailed

Removing the blocker

The blocker in question can only be refuted if both teams agree, otherwise it needs to be escalated to the product owner for resolution. The resolution can then be prioritised and handled in the normal manner.

If on the other hand the blocking team accept the blocker as their responsibility, they may also furnish an ETA. That ETA may be within the current sprint, at which point the team can organise themselves to deal with its delivery. On the other hand, if the ETA is outside of the current sprint, or there is no ETA, then the blocked team must react and notify in the following way:

• Immediately drop the blocked feature from the sprint
• Notify any dependent teams that the feature has been dropped, with a rationale
• Notify the product owner immediately that the feature is off the list
• Notify the release manager that the feature will miss the next release if that is now a reality

If the item that is blocking you has not been prioritised by the other team, then it is no longer a blocker – it is a feature with a different priority. If a feature has a change in priority then it is crucial that the appropriate stakeholders – other teams, product owners and release managers – are notified as soon as possible.

If, as a result of this communication, the re-prioritisation is challenged, then it is up to the product owner to agree an appropriate priority and to manage the process of communication.

Desired Outcomes

Ostensibly this process dictates how teams manage the inter team dependencies when they turn into blockers. Underpinning this process is a set of guidelines that push the teams towards communicating directly with each other which in turn helps to eliminate some of the silo mentality. Using that as leverage, the problem can be pushed up the delivery chain to the planning and pre-planning stages where many of these dependencies should be identified and managed.

The process worked well in this project. The teams, having adopted this process, quickly started to adjust their process modifying their architecture and planning approach allowing inter-team dependencies to be identified and technical mechanisms agreed before these stories were proposed for sprint planning.