If I’m involved in a task and it’s not completed yet, then people may want to talk to me about it or ask questions.
Eventually, the work is done, and people tend not to need my attention on that topic.
The more work I have in progress and incomplete, the more reasons people have to talk to me.
When I’m trying to work on one task, then all those conversations about other work will be felt as interruptions.
This is true of uncompleted items I’m working on currently, the items in flight (not yet released), and to a lesser degree also the items I have finished in the past and the items that I am being selected to work on in the future.
Every work item that has my name attached to it is an invitation to interruption.
This forms an interesting “law” or “rule” of work:
The likelihood of interruption is proportionate to amount of work in progress.
When we suffer greatly from interruptions, it is because there are too many reasons to be interrupted.
If we did only one thing at a time and worked each to completion then there’d be very few reasons to interrupt the current work.
Even if I finished one thing at a time, though, my colleagues may be doing work on code that I touched last. They may need to know things from me in order to understand and extend the work I’d already done.
They may need to know how the work they’re going to do will interact with the work I’ve already done – whether it may introduce a software defect.
The reason that they need to talk to me is that I did that work alone. I am the sole expert on the way that functionality was implemented.
This suggests that the “amount of work in progress” includes not only my work but also the work of my colleagues.
The more we collectively have going on, the more likely we’ll need to talk to each other about past work.
When we’re all loaded up with in-flight work that has dependencies and interactions, like features in the same code base, then interruptions are natural and unavoidable.
In other words, the way we are working (individual tasks, much in flight at one time) causes interruptions.
Interruptions aren’t the problem, they’re just symptoms of us working in a way that creates so much busyness and activity that it limits opportunities for focus and accomplishment.
If we all knew the code changes, then we wouldn’t have a sole expert that we have to talk to about our new changes or about any defect we’ve found. We would be able to work without interruption – again, there is only work-talk, and no interruption of one task to talk about another.
If you’re dealing with interruptions, it’s because of the law of interruptions: that the likelihood of interruption is proportional to the amount of work in progress at any given time.
Ensembles work on one thing at a time and share the knowledge gained by doing the work.
This describes one more knock-on effect of ensemble programming: if everyone is working on the same thing, then there is only work talk and little to no interruption.
