BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

The “Do Not Disturb” Team Member

by Vikas Hazrati on Mar 09, 2010 |

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?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Pomodoro Technique by Yves Hanoulle

I'm a bit on both sides.
I think the team should interrupt everyone when it is team related.
If too many interruptions happen a technique like the pomodoro technique (where people work uninterrupted for 25 minutes can help.
Advantage is you get 25 minutes of real work. When teammembers look at your timr, they know exactly in how much time they can disturb you.

In this particular case; being a scrummaster I would say he should be interrupted. In his role as scrummaster his main responsibility is the team anyway.

Wrong level of optimization by Bruce Rennie

Johanna Rothman hit the nail on the head. This guy is not on the team.

I care not one whit for individual productivity. I care only that the team is reaching its goals and its velocity is stable. If answering other peoples questions 8 hours a day does that, hey, cool.

It's the Scrum Masters JOB to be interrupted. That's what we're there for.

Try to listen to developers for a change by Peter Veentjer

It really depends on the developer how much isolation he/she needs. Some people work perfectly when there is a lot of noise and don't find it a problem when they are interrupted or need to switch context. Some people don't. It has nothing do with organization, process or something that can be changed, it is just a fact of life.

I really love it when people that don't design software try to impose there idea of 'good' on others.

Re: Wrong level of optimization by Peter Veentjer

I think Johanna Rothman sees it way to black and white. It doesn't mean that a developer needs to be isolated all the time, but some developers have a harder time focussing with noise than others. So give them room.

The first 2 days a week I work with 2 project teams in a single room (10 people in total) and the rest of the week most of the external developers work at their own office. These last days days I'm much more productive because there is less noise.

Who is the problem? by Jim Leonardo

Is it the "Do Not Disturb" team member or the "I can't help myself" team member?

Google is there for a reason...

Re: Try to listen to developers for a change by Bruce Rennie

I'm not sure what your comment about designing software has to do with the conversation, but anyway...

Your point on some developers needing isolation is valid, but THIS GUY IS THE TEAM SCRUM MASTER. "Isolated Scrum Master" is kind of an oxymoron.

And if you find yourself to be one of those developers that needs extended isolation to be productive, you may want to consider finding a job in a company that doesn't use agile.

Re: Who is the problem? by Bruce Rennie

I tried googling "Hey, we realized yesterday the design of this feature missed one important scenario and we never decided what it was supposed to do in this particular situation. Can we talk about it now?".

Didn't really help.

Re: Wrong level of optimization by Francisco Jose Peredo Noguez

Maybe, or maybe it is a reflection of the low level of competence of the team (maybe what should be done is top and see why all this people can not do their job by themselves). Also, it might be the case that the interrupted guy is being asked to develop at a speed that it is just not compatible with the level of interruptions he is being asked to deal with...

Re: Try to listen to developers for a change by Francisco Jose Peredo Noguez

Well, an interesting question here would be if they are letting him "be" a SCRUM MASTER. Maybe he is expected to code as fast as if he were not an SCRUM MASTER.... and he feels overwhelmed with the responsibility....

Re: Try to listen to developers for a change by Bruce Rennie

Anything is possible. The fact is the person described is the Scrum Master. That should be enough for the conversation.

Multiple Roles? by Hannes Fischer

I think this guy has to many roles. He ist senior engineer (the developer role), scrum master and partner (perhaps the team owner role from XP). Best results are reached if everybody only has one role in the project.

Re: Multiple Roles? by Vikas Hazrati

I think apart from the multiple roles that he was playing, which obviously could well be the root cause, there could be a personality issue too.

We had a developer on our team who was in the same category, he did not want to pair up, did not want to discuss too often, was happy working alone in isolation. Was he good? you bet he was. So we decided not to lose him. Instead, we encouraged him to take work on which he could work alone like some R&D stuff, spikes etc.

But inspite of all this, there was always a feeling that he is not a part of the team. The team members became increasingly reluctant to talk to him. They felt that the team problem was never his problem since he was doing well in his 'walled' world. Over a period of 3 sprints it became painfully obvious that he could not continue in the team despite being technically very sound. We had to take him off.

We had another such case and eventually it turned out the same way as well. So my conclusion is that the heroes too need to be good team players, else there are other places.

Re: Multiple Roles? by Markus W.

I agree to some opinions:
A scrum master exists to be the one interrupted instead of the team. And yes if he doesn't want to take that burden he should not be the scrum master.

We have some kind of the the same situation in our team at the moment:
a developer who is also the scrum master is frequently interrupted by other team members AND the product owner.

But I think, it's just a question of the frequency of interruptions.
* If interruptions occur every 15minutes then the daily scrum doesn't go well, because that's when you could make dates for meetings during the day.
* If it's really randomly and unavoidable but still often, we dediced in our retrospective that it is ok to send people away if you don't want to stop your work at the moment (e.g. debug session). I close my door from time to time which is usually open all the time, but every team member has to be aware of that

Re: Try to listen to developers for a change by Olaf Bergner

While I do agree that a Scrummaster's job is to serve the team at all times and thus inevitably entails being interrupted often, I would like to dispel the myth that some people are somewhat better at coping with being interrupted than others.

It is true that some people are somewhat less annoyed than others when being interrupted. These people might understandably claim that their productivity likewise doesn't decline too severely. This, however, isn't true, as studies have repeatedly shown. Everyone's productivity is severely affected by repeated interruptions, regardless of whether someone thinks otherwise or not. And no, it is not a matter of getting used to it. Being interrupted just kills productivity, period.

So it follows that each software development methodology - be it agile or not - should do its utmost to reduce the number of context switches as much as possible.

Regards,
Olaf

Re: Pomodoro Technique by Ilya Sterin

25 minutes? That's not even enough to get your head into the context of what you're currently doing?

WTF is wrong with all these analysts analyzing ways to turn programmers into some structured machines. It just doesn't work this way. Programming is as much art as it is science, if not more. You want a programmer to create a masterpiece, you hire the best passionate developers let them work the way they feel comfortable.

Re: Try to listen to developers for a change by Ilya Sterin

Ah, I didn't realize agile was this rigid, I thought the whole point of it is to be more adaptive. But either way, you guys can overhype this crap all you want, the bottom line is that nothing beats common sense. I work in an agile software shop, I telecommute and am isolated for probably 80-90% of my day. We are productive and get shit done. That's all the matters.

Also, because we're isolated and actually have some time to think and rationalize, I can argue we write better software.

Re: Pomodoro Technique by Yves Hanoulle

Please read about Pomodoro Technique before you critize it.

A lot of developers use this to have time to focus.

www.pomodorotechnique.com/

Re: Pomodoro Technique by Ilya Sterin

Choose a task to be accomplished
Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
Work on the task until the Pomodoro rings, then put a check on your sheet of paper
Take a short break (5 minutes is OK)

Are you serious? 25 minutes? This might be great for pointy haired bosses answering emails and returning phone calls, not for software engineers that have to analyze algorithms, complex architectures, etc...

www-cs-faculty.stanford.edu/~knuth/email.html

Re: Try to listen to developers for a change by Matt Brooks

It sounds like the person in question is having to take on roles that practically conflict with each other: being a Scrum Master, which should entails being a sink for regular interruptions, which in turn are not conducive to sustained coding. Trying to do a balancing act usually means your code suffers from lack of focus, and the team suffers from lack of a dedicated Scrum Master that can field issues and interruptions.

Methodology aside, I still find it a healthy practice if developers have a little bit of time (say 1 day) out of the week to focus on tasks independently with minimal or no interruption (aka "the cone of silence"). If it's "anti-Agile", so be it. Collaborative efforts are a good thing, but they necessarily generate interruptions, wanted or no. Developers still need some uninterrupted time and breathing space to work out problems independently every now and then. Prohibiting that is equally bad as having the "Do not disturb"/"Guy in a room" scenario where the developer doesn't want to talk to anyone, ever.

Re: Who is the problem? by Jim Leonardo

And if that's the question, that's fine. But, if the senior person is being asked constantly questions that are easily answered with a quick search, then there's a different problem.

Re: Pomodoro Technique by Yves Hanoulle

YES I am serious.
I learned the Pomodoro technique from developers.
Again a lot of developers are using this.

It is a concentrating technique and it works fine for developers.
One of the theories that was added after the practical use, was it makes sure people use both parts of their brain.
When developers stop implementing and have a 5 minute break from time to time, they actually are more productive.

Re: Wrong level of optimization by Yves Hanoulle

peter I agree you might be less more productive as a person.
We are talking about team productivity here.
That is related but different.
Yes most people need about 12 minutes to get into a zone.
yes there are studies from the 70ties that say that when you work in an open office you get interrupted every 7 minutes.
So now way you get "into the zone".
Yes but the productivity is based a lot on communication.

As funny/stupid as it sound a team with less productive people outperform very productive people with less communication.

And yes I know you need concentrating moments, that is why I propose to look at Pomodoro technique which offers both .

Re: Wrong level of optimization by Ilya Sterin

Ok, but there is more than just sweat shop programming there. You're right that a team of 100 programmers can crank out many more lines of code than 3 people. But not sure about most, I love programming. It's much more to me than cranking out lines of code to meet deadlines. It's about intellectual curiosity, mental challenges, etc... Great software companies realize this and they try to balance this need/desire with productivity in order to retain best engineers, because most of them can go pretty much anywhere else, even in a bad economy.

Re: Try to listen to developers for a change by Bruce Rennie

Yeah, I forgot that all of us are above average.

No one, especially no agile proponent, is saying that interruptions are a good thing. There's no practice that says: "Every 15 minutes get up and bug your neighbor". No, really.

The point of the article is that A TEAM (I know it's none of our teams, because we're all above average, after all) has a SCRUM MASTER that is being interrupted regularly. Now, if the team doesn't want that there are things it can do. However, hanging up a DO NOT DISTURB sign is NOT one of them. You either face the problem and resolve it or you accept it. Ignoring it is not an option.

I see this a lot with teams, agile or not. Introducing a new practice tends to "lower the water line", exposing problems. Good teams tackle the problem and make it go away. Other teams stop doing the practice. Sure, you stop feeling the pain, but...

Re: Pomodoro Technique by Vikas Hazrati

There has been a heavy discussion on the pomodoro technique on InfoQ. Some people see a lot of value in it and others hate it like anything.

Re: Try to listen to developers for a change by Vikas Hazrati

> However, hanging up a DO NOT DISTURB sign is NOT one of them. You either face the problem and resolve it or you accept it. Ignoring it is not an option.

True, and I guess that is the reason that it is being called as the "Coaching Challenge" These are the symptoms, what is the real issue?

Re: Wrong level of optimization by Vikas Hazrati

> it might be the case that the interrupted guy is being asked to develop at a speed that it is just not compatible with the level of interruptions he is being asked to deal with...

This is interesting!, we know the viewpoint of the team, what does the developer say? If the person or someone who can relate to the person is reading this. What is the issue that you face? How would you like to work rather than just have a "Do Not Disturb" board.

Re: Try to listen to developers for a change by Alexandre Poitras

Totally agreed. Why we must always think in term of 1 and 0. It's either all or nothing in software development. Why can't we accept that we just need balance between working individually and working as a group and that's this balance depends of the person, the task at hand, ...

I'm in the same case as this guy. I need some time alone to focus and get things done. I have trouble focusing when I get interrupted a lot. It doesn't mean I'm not a team player. I really enjoy helping fellow developers, debating, .... but I still need to be alone from time to time to be productive. It's just the way I am.

This is the problem I have with labeled methodologies. People start to think the method is an end in itself and forget to adapt to the context. It's happening to the "agile" world right now. I have seen it again and again. "Why do we need to have a planning?" "Because Scrum says so" "Yeah but it's doesn't make sense in my context." "It's because you don't understand fully agile yet. You shouldn't mess with it until you have truly understand it how it works. One day, you'll understand.". Sounds like religion to me. According to Agile evangelists Scrum is supposed to be pretty darn simple but yet for some reasons I'm supposed to need years of practice to understand and customize it. Doesn't make sense to me at all.

Re: Try to listen to developers for a change by Vikas Hazrati

Hi Alexandre, You bring 2 very interesting points

> It doesn't mean I'm not a team player. I really enjoy helping fellow developers, debating, .... but I still need to be alone from time to time to be productive. It's just the way I am.

Do you feel that the team respects your decision and stands by you or do you feel that they feel the same way as in this post? Is the team reluctant to talk to you once they have been turned away frequently? What kind of tasks do you usually get involved with? Ones where you are pairing with a team member or the ones which involves isolated research?

> "Because Scrum says so"

I think this is one of the adoption flaws but before you started believing that it would not work on your context did you try it out? and what was the result?

Re: Try to listen to developers for a change by Jim Leonardo

Alexandre...
I pretty much agree with you. I think your argument can be simplified to the idea that the following is a fallacy..

Scrum = Agile

its not even a case of

Agile = {Scrum, XP, ...}

I'm not criticizing either, just the inappropriate equation in people's mind...

I think we need to start sending this message clearly: Scrum is NOT Agile. It's not even a case of Scrum being a subset of Agile.

Agile is a set of values and principles and, to a much lesser extent, practices. Scrum is a project management approach that has successfully be adopted by teams that are Agile. It is not Agile in and of itself. Further adding to the case, Scrum predates Agile.

Agile = a philosophy.
Scrum = a process.

You can't call yourself Agile simply because you are using Scrum. You can't say a team isn't Agile because they aren't using Scrum.

Re: Try to listen to developers for a change by Bruce Rennie

Sorry, but this isn't a "labelled methodology" issue. This is a general process improvement issue.

Hanging out a "Do Not Disturb" sign is ignoring the issue. It will never be fixed that way. As such, it is the least satisfactory choice for dealing with the situation. You can be in a waterfall, agile, or cowboy development shop and it would make no difference.

The only agile connection here is that the person hanging the "Do Not Disturb" sign is filling one of the (very few) critical roles for Scrum. This merely escalates the problem from annoying to very serious. The problem is still there if you strip away Scrum.

Re: Try to listen to developers for a change by Alexandre Poitras

Unless people can't work without his help, I don't see any issue. If the guy is a bottleneck, of course it should be addressed but other than that I don't see why it is an issue to ask for a couple of hours of "almost" uninterrupted work. Looks more like a scrum issue to me than a real issue.

Re: Try to listen to developers for a change by Bruce Rennie

Your reply makes no sense. If the guy weren't a bottleneck, he wouldn't need to ask for quiet time, would he?

How is that a scrum issue? If they weren't doing scrum all of these interruptions would suddenly disappear? I don't get it.

To repeat: there's no rule in any agile methodology that I'm aware of that requires people to interrupt their co-workers. Let's be clear: Scrum takes no position on how little or much quiet time you have during the day. If you can get your work done in 15 minute chunks, hey, knock yourself out. If you get 8 hours uninterrupted, good on you.

What is NOT ok is to ignore an issue that is preventing one or more team members from progressing, especially if you've taken on the role of Scrum Master. This really isn't an onerous rule, frankly, and if constitutes "religion" for you then pretty much any methodology is going to fail to meet your standards and we're wasting our time discussing this issue.

Re: Try to listen to developers for a change by Alexandre Poitras

Your reply makes no sense. If the guy weren't a bottleneck, he wouldn't need to ask for quiet time, would he?


It doesn't mean he is a bottleneck, there could be other reasons :
- People just don't realize he needs focus. Maybe they can wait an hour or two if the issue is not that urgent.
- Too much noise.
- He can stop himself from jumping into conversations.
...


How is that a scrum issue? If they weren't doing scrum all of these interruptions would suddenly disappear? I don't get it.


I'm saying it is a scrum issue because I have witnessed too many Scrum evangelists telling a team that they should always work in a common room as a team, that it's not ok to work alone sometimes when you feel the need to. It's just my personal experience and I hope it's different in other places.

Re: Wrong level of optimization by Slava Imeshev

Maybe, or maybe it is a reflection of the low level of competence of the team.


It's quite possible. I have also observed a situation when there is one "go-to" dude who knows, can do and can fix everything. Surely this is the guy who once in a while cries for time to do his work. The only way to fix it as I see it is for the guy to stop doing what he is doing and start educating the team on "go-to" issues until the rest of the team can operate on its own.

As a side note, the situation where the team members "collaborate" a lot smells like a failure to disseminate or to absorb information. It is intuitive that after an initial spike in collaboration there is a plateau of relatively low information flow where everyone knows what he is doing. "If you are always talking, when are you working?" :-)

Re: Try to listen to developers for a change by Alexandre Poitras

Agreed but the problem is that the Agile manifesto states "People over Processes" and yet most agile processes are defined in term of tools and practices and according to the authors should the process should not be customized. This is kind of illogical.

This is why I much prefer the Lean movement over the Agile movement. It's seem much less process-oriented and has been used in many different fields.

Re: Try to listen to developers for a change by Alexandre Poitras


> "Because Scrum says so"

I think this is one of the adoption flaws but before you started believing that it would not work on your context did you try it out? and what was the result?


We did try it out in one case (workers spending some free time on a side line projects) and it didn't work at all. There were too many unknowns to work in fixed length sprints.

In the second case, we didn't even try because it was fairly obvious it would not work. I was on a team fixing production problems. We never knew what was going to be the emergency of the day so we went for a continuous flow a la Kanban instead.

Re: Try to listen to developers for a change by Vikas Hazrati

Bruce I agree with your point
> How is that a scrum issue? If they weren't doing scrum all of these interruptions would suddenly disappear? I don't get it.

but, I guess Alexandre does not mention "Because Scrum Says so" just for this part. I guess in general it sounds like his team wants to follow the process for the heck of it without analysing the situation they are in and hence he had an "allergy" towards the process part of it.

Re: Try to listen to developers for a change|What do the Agile Coaches say? by Vikas Hazrati

> The only agile connection here is that the person hanging the "Do Not Disturb" sign is filling one of the (very few) critical roles for Scrum. This merely escalates the problem from annoying to very serious. The problem is still there if you strip away Scrum.

Again, that is the reason why Elisabeth mentioned it as a Marvellous coaching challenge. We are yet to hear how the Agile Coaches would like to resolve this situation.

How about for small companies? by Balaji D Loganathan

Very interesting topic. I face this problem very often.
If you are a founder of start-up company acting as a SCRUM Master + Developer + Sales then would you be able to do justice to your SM part? Ideally No.

You cannot hire a SM separately because you simply can't afford at this moment. If the team is keeping you busy asking you questions after questions means, then obviously there is not enough information radiators available for them.
I made my team to get as much information as possible during the planning meeting. I do my non-SM tasks when I know that team won't need me for next 2 hours or so.

Wondering how others would handle this situation.
Regards
Balaji D Loganathan
Spritle Software

Re: Pomodoro Technique by Balaji D Loganathan

Hi Ilya,
Is the link www-cs-faculty.stanford.edu/%7Eknuth/email.html part of your reply or a signature?

BTW, I very much like pomodoro technique when i have problem focusing with several tasks in my hand. I never tried it with while i have do coding however.

Regards
Balaji D Loganathan
Spritle Software

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

41 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT