Bin your sins or stay blocked – illustrating annoying context changes on your Scrum Board to promote change!

Recently I was working with a team that were dealing with a number of disturbances.

When I say disturbances I’m talking, the sprint kicks off & Unplanned Work comes in.

Is that unique, is that unacceptable?

No.

My view, Scrum teams need to have all the support in the world to ensure they are left alone to deliver the Sprint goal.

BUT.

Scrum teams also have to provide some level of a support function when it is needed for multiple reasons.

1st & 2nd line can’t resolve an issue impacting a client in production.

Something just exploded in Production and no ones noticed yet, but it needs gravitas from a Scrum team to help support nail the issue.

The sales team need to confirm business logic on how something works for a pushy client & the only guy that knows is Bob in the Scrum team cause he’s been in the same company for 10 years.

And so.

I ain’t saying we should have a stream of Unplanned Work.

I am saying I understand the nature of delivering a project (the sprint work) & helping the business keep it’s wheels on (the support work).

Now.

When the disturbances are constant.

When the disturbances involve pulling developers off of work they are working on to address issues.

That’s expensive.

Expensive because it involves context changing.

I would like to show you a mini case study of a team who were made to do this allot & what we did about bringing this problem of context changing to the attention of the Product Owner.

I’ve simplified this board to give you the focus on one developer’s pain….

Tim is working on Story 1. There are 2 stories, Story 2 & Story 3 which are blocked.

Image

An unplanned piece of work comes in. The PO has explained that it can’t wait and needs attention ASAP.

Image

Tim stops working on Story 1, and picks up the Unplanned Work. Story 1 is then placed into the ‘Blocked’ box.

Image

Tim is working on the Unplanned Work when suddenly the Product Owner comes over and explains that it’s “vital that this ‘request from the business is handled ASAP -since a customer needs to know the answer to a question which only Tim would know”.

Image

Now the 1st Unplanned piece of work goes into the Blocked box & Tim begins working on the new Unplanned Work item.

Now take a good look at the Blocked box.

Image

Does that look right to you?

Does it seem right that we have stories & Unplanned Work placed into the Blocked box?

It didn’t sit well with me.

The fact that we were not illustrating that there was a problem.

A problem in the high disturbances we were receiving.

So….

Here’s the 1st thing I did.

Some healthy antagonising 🙂

Image

Sad smileys anyone?

“Why do we have sad smileys on those cards” asked Tim in the Stand up.

So we had a discussion, with me asking the below question to the team:

Image

We were hiding dysfunction through misusing the Blocked box.

Think about it.

When something is blocked its an external dependency & we accept that the artefact belongs in the Blocked box.

But when someone is pulled off an existing piece of work to do ’emergency’ stuff a la Unplanned Work – that item is not Blocked.

If I am working on something, and I am pulled off of that something and made to switch context, then that item belongs in one place and one place only.

Meet the SINBIN.

Image

This is a quick, easy modification to your board which shows how many times the team have been disturbed/pulled off whilst in the middle of something to handle an Unplanned Work item.

Here’s how our Unplanned Work items look now.

Image.

Now we have clear distinctions between work which is truly Blocked & work which has been Sin binned.

When that SINBIN box begins to mount, nudge your Product Owner…

“Looks like we’re pulling off the guys to deal with Unplanned Work, all that context changing isn’t healthy…. it’ll most likely effect our Sprint goal”.

This is how we need to handle Unplanned Work which forces developers to be pulled off existing work.

Every context change impacts the effectiveness of getting a card through to done.

We need to show on our boards, the frequency of these types of requests to drive home the point that context changing slows us down.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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