ScrumMaster Tales – Stuck Waiting for Other Teams

John (ScrumMaster) and the team are humming along nicely building great new features for the SmallestOnlineBookStore. With the huge success of the first big release nine months ago, venture capital money has come flowing into the company. Significant investments have been made in Operations, Security, and Networking in addition to creating several new Development Teams. Unfortunately, all these new people are making it more difficult for the team to get the software they built deployed.

The new groups are often imposing their own reviews and processes on the software before it’s deployed. Some changes are going to increase the load on the network and require review by the network team. Other changes affect the payment gateway, backend administration, and the services team who have a lead time of three weeks. All of these reviews, while increasing safety, have greatly slowed the delivery of new features.

The Development Team is getting frustrated because they feel their work is slowed artificially by the teams downstream of them (i.e. Networking and Security). The customers are getting annoyed because the previously great flow of features has slowed down to a crawl.

In addition, the team has created a Work in Progress (aka WIP) of one story per developer. This is both exacerbating and revealing the problem. It’s exacerbating because the team doesn’t have background to work on whenever their main task is stuck. It also reveals that the real problem isn’t at the team level where the work is getting to “almost” done.

John creates a short list of options for the team: Increase individual WIP limits to 2; Change the Definition of Done so that Security and Network reviews aren’t part of Done; Add a column to their Scrum Task Wall to account for both other groups and start working with the other departments to clear work more quickly.

Analysis

Before we explore options in a situation like this I prefer to gather data. The best way in this case would be to create a Kanban wall that tracks the progress of a Story from initial idea to the moment it’s deployed and is delighting customers. This, combined with a Cumulative Flow Diagram, will help the source of the Team’s stress.

John, being aware this might be an issue, has been tracking the data for just over a month:

ScrumMaster_Tales_-_Stuck_Waiting_for_Other_Teams_data_table

From the data we can produce a Cumulative Flow Diagram that looks like this:

Cumulative Flow Diagram

So what does this chart show? The team isn’t the bottleneck in this case. A simple test I use to tell is this:

“If we had a magical way to double the rate at which you deliver stories/features, would that make any real change in the rate at which customers get the features?”

At the development team level – Code, Code Review, Testing – clearly that isn’t the case, the bottleneck is in “Done in Development”, which is really just a buffer, and Network/Security review. Rather than make changes at the team level, we need to see what we can do to optimize the downstream work.

Based on this data, let’s re-examine the team’s options:

  • Increase Individual WIP Limit from 1 to 2 – This really just masks the problem giving something else for someone to work on when their original item is stuck in Network or Security. As we’ve already seen the limit isn’t at the team level, so optimizing there won’t help.
  • Change the Definition of Done so that a Story is considered Done when it’s handed off to an outside team. – This doesn’t really help the customer since the item still isn’t deployed, it just makes each individual developer feel better. However, in creating an additional column for the downstream groups, we have effectively created a Definition of Done for each column. Kanban calls these “policies”. So we have changed “Done” but only in the name of making our problems more apparent.
  • Add a column to the Scrum Task WallWe didn’t quite do that, instead we created a Kanban wall that acknowledges some of the work is beyond our team’s span of control.

So let’s add a new option:

  • Start working with the other departments to clear work more quicklyIn a Kanban oriented world, teams swarm downstream blockages. This would definitely be a good idea in our case.

 

Were I coaching John, I would get him to setup the Kanban tracking wall with the other teams and departments so that the entire company gets a view of where the work stands. I would invite people from each group to come update the wall every couple of days. By getting their involvement in set up and tracking, people from the other teams (i.e. Security and Networking) will appreciate that the data reflects their world and they will be more open to acting on the data. In addition, John (and his team) will gain greater insight into what is affecting Networks and Security – perhaps the company was suffering from a Denial of Service attack at the end of June and for a few days both teams were pulled from reviewing to handle the operational problem.

The team might also discover that they’re found to frequently be violating security practices. In this case, mentoring from Security might increase the team’s level of skill in this area, and reduce time spent in the review phase. Very often in cases like this, cross-training the team (see: The Team Gets Bottlenecked) to help reduce the downstream bottleneck will help, however we won’t know until we’ve gathered data and worked with the other teams to find out what the real problem is.

As an aside, I don’t recommend individual WIP limits when working as part of a Scrum Team – instead focus on the WIP for the entire team. It’s a small change, but it makes it clear that the productivity of the team is more important than that of any one individual.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
145 City Rd
London
EC1V 1AZ
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.