Interruption, as the name suggests acts as a speed breaker to the velocity of an Agile team. Some of these interruptions are necessary and others are not. The key is, to identify the interruptions that are damaging to the flow of work and minimize them.
In an interesting discussion on the Extreme Programming group, Alistair Cockburn shared the dominant interruptions which disturb the flow of a team
(1) too many meetings (programmer has to stop work to go to yet- another-meeting, and
(2) too many simultaneous projects (programmer has to stop work on project A to switch to project B).
Both of those can be real time and energy suckers, and typically there is a way to adjust the projects, the meetings and the flow of the day to reduce them, allowing the programmer more contiguous programming time.
Alistair added that sometimes in a team, there has to be a person who has to take care of phone calls , meetings, chasing people, interfacing with clients etc. This leaves less than expected time for that person to be productive on the team. According to Alistair, the expected productivity of this person has to be limited to the time that he got to spend on the project.
Alistair has described this scenario in one of his project management patterns by the name “Sacrifice one person”. In his pattern, Alistair suggested that often a project might not be moving as fast as desired because there is an important interruption taking time from all the team members. Since the interruption is an important secondary task it cannot be dropped, however, it does divert teams attention from the primary task.
According to Alistair, the solution to the problem is to assign one person dedicatedly to take care of that interruption. Though, this one person would feel sacrificed, rest of the team can make progress by working on the primary task.
On similar lines Gojko Adzic, added his part of the story when he was working as an architect on a project but spent most of his time on working as a software lubricant. Being a lubricant included tasks like answering questions to new people, coordinating various threads, interfacing with clients and attending all sorts meetings. Gojko added, when he tried to be productive on the programming related tasks a lot of other team members had to act as lubricants and this was pulling the team velocity down. This is when he decided to take all the secondary work with him and let all other members on the team focus on primary tasks. According to Gojko
Although I still tried to cut code in order no to lose the touch with how things are progressing, we did not count on my involvement in terms of planning at all -- my time was simply written off. Looking back at that from a time distance of 4 months, I think that this was a good way to solve that problem as far as the project progress and team productivity is concerned.
Responding on the second dominant interruption raised by Alistair, members on the mailing group agreed that fractional allocation of people on projects does not work. Gojko summarized the mindset problem of having team members work on multiple projects.
The problem is that, once you get four or five fractional people, the stakeholders think that you have a team, where in fact all you have is effectively one full-time person, if not less.
Further in support of having people working on dedicated projects, Gojko suggested, that there is considerable amount of overhead of coordination and communication when there are team members working on multiple projects. He gave a very interesting example to prove his point
10 fractional people with 20% effort might theoretically produce the output of two full-timers, but coordinating 10 fractional does not take the same amount of effort as coordinating 2 people. It takes the same amount of effort, if not even more, than coordinating 10 full-time employees. The reason why I think that this takes more is that fractional's often skip standups and catchup meetings because of other obligations, and are not co-located all the time as 10 full-time employees would be. Two real people would require virtually no coordination and incur no communication overhead.
Members of the group were convinced that to mitigate the risk associated with the dominant interruptions, it would help to have a person sacrificed to take care of secondary tasks and avoid putting the same person on multiple projects at the same time.