Handling Interruptions on an Agile Project

Posted by Vikas Hazrati on May 30, 2008 10:50 AM

Community

Agile

Topics

Agile in the Enterprise ,

Agile Techniques

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.

1. Back to top

   We call him Ronin

   May 30, 2008 12:09 PM by Denis Bregeon

   We applied a similar pattern. We named the role 'Ronin'. See a description of this here: http://digitalbrikes.com/onebrikeatatime/2008/04/10/the-ronin-%e6%b5%aa%e4%ba%ba/

   Reply

2. Back to top

   Re: We call him Ronin

   May 30, 2008 1:20 PM by Vikas Hazrati

   Denis, Ronin sounds like a good name too :) Did the pattern help you improve productivity? Another important question - Did the "Ronin" feel demotivated because he was working on non-primary tasks? ... or did you have something like Ronin Rotation?

   Reply

3. Back to top

   Re: We call him Ronin

   May 30, 2008 2:20 PM by Denis Bregeon

   It definitely helped. The Ronin can also handle short lived tasks (such as bug fixes) and release engineering tasks so he is contributing greatly to the team. Yes we have a rotation. The 'tour of duty' is typically one to two iterations (2 weeks to a month). The Ronin also has some freedom to pursue work or research on prospective technology. In this way we sometimes have people actually happily volunteer ! What we noticed however is that being Ronin and have regular work to do is demotivating and frustrating.

   Reply

4. Back to top

   Re: We call him Ronin

   Jun 3, 2008 4:10 AM by Daniel Ziegler

   We call this person "Joker". And I agree with Denis: It definitely increases productivity for the rest of the team. We try and change the team member who got the role of the Joker every sprint. This way we have a certain degree of variation for the team members.

   Reply

• Older >