Islands in the Stream

When scaling Agile, most people still talk about a Scrum of Scrums. This is a meeting where the individual ScrumMasters discuss issues that have impact across teams. I’m not sure the Scrum of Scrums name is correct, because these meetings can’t wait for risks to become blockers to address them. By the time a blocker is caused by another team there’s usually no quick way to have the blocker resolved. ScrumMasters need to be addressing those risks before they become blockers.

In reality, Scrum of Scrums is a way to ensure ScrumMasters talk with each other. A Scum-type meeting shouldn’t be required for this as ScumMasters should be excellent at encouraging communication. However, it is a good idea to have a way to keep track of issues that pose cross-team risks.

At my current assignment, we’re using Agile for JIRA. One project ran a successful experiment of making sure that each team that is facing the risk creates a JIRA issue to track its responsibility for the Story. That is, if I have work that I have to complete at a certain point for Project B, Project B’s ScrumMaster creates a zero-effort Story in his/her backlog that can be linked to the corresponding Task or Story in my Backlog. In this way, the two ScrumMasters have a reminder to continue to communicate.

A key point to remember is that these tasks are constraints. Project B has placed a constraint on my team, often with a due-date that needs to be met for a specific reason. I need to treat this task as a constraint from another team. I either need to make this due-date or communicate issues to Project B’s ScrumMaster early and often. Since Scrum considers the backlog to be fluid, much like a stream of Stories, I consider these constraints “Islands in the Stream.”

Let me explain. In Scrum, the Product Owner can re-arrange priorities based on changing technical realities or changing business needs. This may move some items earlier or later in the Release Plan. But these constraints can’t move. In the case of work that our team owes another team, we can’t move the item later because that would impact the other team. If another team is constraining us, we can’t move constrained work earlier because the other team won’t be finished. In both cases, those Stories or Tasks are immovable. They’re the islands in the otherwise fluid Backlog stream.

All constraints can be viewed in this way. Sometimes you need to keep parts of your Backlog on schedule because your sales cycle has fixed dates and you have to be able to promise certain functionality by those dates. Sometimes new functionality can’t be built until you receive a new version of a third-party library.

What happens if you can’t meet a deadline that’s a constraint for another team? The same thing that would happen in any project with cross-team dependencies. You discuss the problem with that team’s ScrumMaster so you can work out a solution that works for both. This needs to be done as soon as possible, which is the purpose of linking the Stories or Tasks in JIRA.

For those not using JIRA or not using technology, there are other ways to mark the Stories or Tasks as impacting another team. If you’re using sticky notes, you can put a colored dot on the note. If you’re using other tools that don’t allow linking, put a special word in the title of the Story or Task such as CONSTRAINT:. Anything that will trigger the conversation will meet the need.

This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s