The “Do Not Disturb” Team Member

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.

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.

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.

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.

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

Google is there for a reason...

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.

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.

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...

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....

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

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.

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.

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

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

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.

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.

Please read about Pomodoro Technique before you critize it.

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

www.pomodorotechnique.com/

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

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.

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.

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.

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 .

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.

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...

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.

> 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?

> 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.

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?

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.

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.

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.

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

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.

> 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.

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

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