Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The “Do Not Disturb” Team Member

The “Do Not Disturb” Team Member

Leia em Português

This item in japanese

Many developers like to work in isolation, for some time, if not always. XP recommends a room arrangement called “Caves and Commons”. Commons area is organized to maximise osmotic communication. Caves are meant to facilitate isolation for activities like personal email, phone calls or a quick spike. However, there could be a situation where team members or a particular team member wants to take this isolation a bit too far.

Jacob mentioned a situation on the Scrum Development Group, where during retrospective, a team member wished to make standards about using “Do Not Disturb” time slots on sprint days. According to the developer, he was being interrupted too often as a result of which his productivity was not optimal. He suggested having block out times of 2 hours each day. During this time he would not talk to the team. According to Jacob, the team found this to be anti Agile and detrimental to communication. The role that this team member is playing is that of a senior engineer and Scrum Master apart from being a partner in the company.

Alan Dayley suggested that the interruptions depend on the type. According to Alan,

Now, what if the interruptions were directly related to the work he is currently doing? Well, then the interruptions would be welcome! And what if two or more people, even the whole team were working on the same thing? Then interruptions would not be interruptions at all, they would be doing the work!

Kurt Haeusler supported the developer when he mentioned that some developers need isolated environment and there may not be anything wrong with that. He mentioned that there could be other reasons to the root cause including,

If he is getting interrupted really every 15 minutes, even when the rest of the team know it hampers his work, then it could smell like the people doing the work are not the same people who have the information to do the work.

Kurt also mentioned that the looking at the positives, it is very positive team culture that such a thing is being discussed in the retrospective.

Likewise, Elisabeth Shendrickson mentioned that this scenario could be a marvellous coaching challenge. Elisabeth suggested that there could be multiple root causes and the current manifestation could just be a symptom of everything-in-progress, nothing done or Hero Syndrome or lacking Agile engineering practices or insufficient visibility or collaboration or even higher like lack of whole team thinking, larger issues around organizational incentives etc. There is a need to dive deeper and do an analysis.

Roy Morien too, commented that more than “Do Not Disturb” this looks like a problem with the multiple roles that the developer is trying to play.

Johanna Rothman, however was of the strong opinion that this developer should not be on the team. According to Johanna,

Take that guy off the team. He's not on the team anyway. Let him do what he wants on the side, not on this project. Team velocity is about *team* not personal velocity. If the rest of the people need discussion, he needs to discuss with them, not work alone. I don't see how a person can be an adequate senior engineer, scrum master and partner in the company. He is making choices for himself.

Adam Sroka also had a similar view when he mentioned that,

Someone who does not like to be interrupted should not be a Scrummaster, period. The Scrummaster's role is to serve the team. They have to be available to the team during the whole day. That is their job. If something else is more important then they aren't really being a Scrummaster. So, let them be a senior whatever and find somebody who actually wants to serve the team to be the Scrummaster.

Siddharta Govindaraj, made an interesting observation when he suggested that such situations are ripe in organizations when you are moving from traditional way to Agile way of working. He mentioned,

*Ideally*, you want everyone collaborating all the time. But sometimes you need to balance things out as you transition to an environment that supports it. The funny thing about cone of silence is that it goes against a lot of basic agile principles. But it can be a useful thing in a particular context.

Siddharta mentioned that in their project, they used the cone of silence for one day in a week. That day everyone just worked alone whereas the other four days were collaborative. Eventually with time and maturity of the team they were able to remove the need for a cone of silence.

Thus not many members on the list were enthused with the “Do Not Disturb” concept. However, there were some who believed that there needs to be a fine balance between the collaboration and isolation. What works for your teams and what would you do in such a situation?

Rate this Article