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?
My view, Scrum teams need to have all the support in the world to ensure they are left alone to deliver the Sprint goal.
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.
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).
When the disturbances are constant.
When the disturbances involve pulling developers off of work they are working on to address issues.
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.
An unplanned piece of work comes in. The PO has explained that it can’t wait and needs attention ASAP.
Tim stops working on Story 1, and picks up the Unplanned Work. Story 1 is then placed into the ‘Blocked’ box.
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”.
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.
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.
Here’s the 1st thing I did.
Some healthy antagonising 🙂
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:
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.
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.
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.