Is context switching your constraint?

Many months ago, we discussed adopting proper agile (i.e. scrum) at True Clarity, the issue of context switching would always be raised as a barrier to adoption. How can a company who works for multiple clients possibly be efficient in their use of scrum, when you mix your backlog with stories from different clients and projects, have you not heard of context switching? Your projects are too small and your lead times too short.

The Literature

Of course the literature is clear, 20% of our time is lost every time we context switch (from Gerald Weinberg, Quality Software Management: Systems Thinking). How can that be wrong? It makes perfect common sense.

Our Results

We’ve been running 3 or 4 scrum shaped teams for the last 6 months, based on this advice we tried where possible to fit one project, one client to one team. Thankfully this wasn’t always possible, and when we measure the throughput of our teams (in terms of customer value delivered each sprint) the results were clear, teams with 2 or more projects were being more effective, in terms of both revenue generation and customer satisfaction.

Stories vs. Tasks

Now I’m not suggesting we think Mr. Weinberg was talking nonsense, far from it, when working at the task level, and looking at the individuals in the team, switching context was clearly bad. Stress levels rise, work in progress increases, quality goes down. So at the level of a story (typically a day or two of the whole team working on one feature) we found the research to be correct.

Theory of Constraints

Thanks to a recent visit to the Hay Barn by Bob Marshall, our eyes have been opened to the Theory of Constraints (The Goal by Dr. Eli Goldratt), and we now have a hypothesis about why we find teams with two or more customers more effective.

The constraint in the flow of work through True Clarity appears to be in the acceptance of work by our customers. This is understandable, customers are busy people, and we’re always keen to talk about new work and scoping up requirements to keep our developers busy and keep projects on schedule. However this is often at the expense of talking to them about the work we are doing. So work in progress builds up, feedback doesn’t come early enough and things slow down, it’s clearly a vicious circle.

So what was happening in the teams with 2 or more customers? These teams have more customers ready to review work, these customers get smaller amounts of work each time, but the volume is matched to their ability to provide feedback. The bottleneck has been cleared and the actual throughput of the team has increased despite the reduced efficiency due to context switching.

Conclusion

So while our hypothesis doesn’t invalidate Weinbergs 20%+ context switching overhead figure, it does make it clear unless your development team is the bottleneck then focusing on this area won’t help you improve the effectiveness of your scrum teams.

Of course if we can work more closely with our customers, and understand how we can better plan the acceptance of the work we produce, we can clear the bottleneck and all our teams will see improvements in effectiveness.

Perhaps then context switching will become our constraint, until then we’ll not worry about it.

Further Reading

http://en.wikipedia.org/wiki/Theory_of_Constraints
http://flowchainsensei.wordpress.com/2012/05/27/focus/
http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html

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