Dealing with interruptions as a Scrum team member 2013/01/19Posted by Angelo van der Sijpt in Uncategorized.
Tags: culture, interruptions, scrum
For the last months, I have coached some engineering teams in a large software-intensive organization. Some are running fine, some need extra work. A topic that regularly pops up is “how do I handle all these interruptions during my day?”
I define an interruption as anything that makes you context-switch away from the work you’re doing for the team. So, questions from teammates are not interruptions. Neither is responding to email at the time of your choosing. Phone calls regarding different projects, or people showing up at your desk with unrelated questions are.
Scrum ask for a distraction-free environment, routing interruptions through the product owner. However, interruptions are a cultural phenomenon, not an organizational one. I will assume interruptions as a given of the current situation, channeling them in a productive manner, and slowly driving them out.
Company culture has its reasons for existence, and is hard to change. I believe there are three intertwined cultural components in interruptions,
- “it has always worked like this”,
- there is no pushback,
- costs are hidden.
“It has always worked like this”
What and why
People have lost trust that goals and deadlines will be met. Especially with deadlines far into the future, there is a track record of slippage and work not getting done at all.
Managers have learned that anything not marked as urgent has a tendency to be left alone, and not get done. People get results by declaring emergency. And you know what? It works.
How to handle
This is ingrained into the organization, and hard to counter. Make commitments, and consistently meet them (“I’ll get back to you next Friday”). Make promises, and keep them, and people will learn to accept you deferring work. We will get back to this. I promise.
There is no pushback
What and why
As engineers, we are inherently nice. When faced with the choice to either shine in front of someone present, of diligently work on for someone that isn’t, we choose the former.
But, apart from an opportunity to please, is this work really that important?
How to handle
This is about personal choice and reputation: build up a track record of being dependable, and your pushback will be more gladly accepted.
Most interruptions are not that urgent at all, but our desire to please gets the better of us. To handle this well, we need to make a well-reasoned decision on the importance of the work before us.
Personal productivity methods provide some help in this. For instance, my personal favorite Getting Things Done forces you to make a choice for interruption over two minutes: Do, Delegate, Defer, Drop.
‘Defer’ can be part of your system, but is more effective as a team. If you decide to deal with your interruption demons, and to not be as available for the team as you could be, you’re hurting the sprint result.
There are many ways to handle this. For instance,
- One of the teams has picked Tuesday as the ‘interruptions day’. For every interruption, they ask “can this wait until next Tuesday?”
- The notion of core hours is written up best in chapter 10 of the Scrum Field Guide. In short, these are the hours every member is supposed to be available for the team. Outside of these hours your free to work the way you want, and any interruptions can be dealt with then.
Making promises and keeping them it not external behavior, it is part of who you are. Be dependable to both your clients, and to yourself.
If you make a promise to yourself to get some work done, treat it just the same as making a promise to someone else. If you need to break it, renegotiate. You can’t be dependable without being authentic.
Costs are hidden
What and why
We all know context switches are expensive, but just how expensive? How can you explain to the angry manager at your desk “ah, yes, well, you know, you bothering me will take roughly 22.6 minutes of productivity away. From another project.” Remember, as engineers we’re way too polite for that.
How to handle
Transparency. Don’t hide incoming work in some support process, taking away control from your product owner. Make it visible that incoming work hurts by keeping it on the same sprint board as the regular work, and show this pushes out planned work. Start counting interruptions, and show the correlation between interruptions and velocity.
I see interruptions as a part of the process, but we can make them exceptional. There are many ways to handle this, but picking just a few,
- use short sprints, so this work can be planned in a regular fashion, or
- spend time increasing product quality, so we end up with fewer emergencies.
Well, what does that mean for you? What can you, as an engineer, do?
Always wonder “what is the most valuable thing I can do at this moment in time” by consciously making the Do/Delegate/Defer/Drop decision.
Build up a track record of dependability: make promises, and keep them. Real emergencies are rare.
With your new aura of dependability, use it to manage interruptions even further. Ask people’s input to be less disruptive: don’t call, email. Don’t visit your desk, create a well-written bug report. Use IRC if you must. This leaves you free to handle the interruptions regularly, but when you choose to.
Every interruption is a chance to shine. Shine only at your own terms.