Flow in Software Teams

My former colleague Greg Gigon has written an interesting blog post where he talks about the pain that we cause ourselves by multi-tasking, a point which Kevin Fox also makes on the Theory of Constraints blog.

I think the overall point that he makes is very true:

We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

I've often found that when I try and switch between multiple different tasks I end up finishing none of them and it's certainly true that twitter, facebook and emails can be amazingly distracting.

Hopefully those types of distractions are less of an issue when working on a software development team, particularly if the team are pair programming.

Project influenced context switching

While I agree with Greg that it's good to try and make sure that we're only working on one task at a time, I think that to an extent there is always going to be some context switching involved if we have a group of people working together.

Greg touches on this briefly in his post:

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

To me it seems that focusing on the flow of an individual individual/pair is a bit of a local optimisation when we're talking about software teams.

For example if a pair are working on a piece of functionality orthogonal to what another pair are working on then should they interrupt that pair if they need to talk about something?

Interrupting them possible would break their 'flow' but it might give one or both pairs an insight into the problem which they wouldn't have otherwise had.

From my experience pairs interrupting each other often helps reduce the amount of time that we spend building the wrong thing.

An alternative way to still gain this knowledge without interrupting people straight away would be to delay the conversation until a later time but perhaps the best moment for gaining that knowledge has now gone?

Counter productive context switching

The only time when interrupting a pair does seem counter productive is if you're doing so to ask a question whose answer could easily be found out with a quick bit of Googling.

In that case I completely agree with Greg that we should first think about the impact our interruption will have on our colleagues.

Overall

The topic of flow/context switching is an interesting one but I think we need to be careful about having it as our main goal on software delivery teams.

I wrote about pair flow a while ago where I described some ways to achieve more 'flow' within a pair but my current line of thinking is that we'll still have some interruption between pairs and that's not necessarily a bad thing.

An approach to ponder…

Mike Wagg once suggested that pairs should work in 25 minute pomodoros and only be interruptible when they're on a break from one.

This seems like an interesting idea but communication would end up being much more structured/time boxed/weird?!

From http://www.markhneedham.com/blog/2010/09/05/flow-in-software-teams