How do you deal with constant interruptions coming from outside the team?

Question

As one of our teams was restructured completely (6 our of 8 new people in the last two months) and their knowledge base is now very weak, I notice constant daily interruptions from them. We share the office space and since most of the knowledge on their project is held by one of my team members, they always pop-over with questions.

We did a technical presentation for their team and planned one task battery-type, so we can offer some support during the sprint. We also suggested to them to build a knowledge database with the info they gather, but lately the questions keep on coming even after talking to them.

I can't just forbid people to talk, also since they like to be very helpful. How would you handle this?

Answer 1

First, notice that you are taking ownership of a problem that is not entirely yours. The PM PM in charge of the project should be asking this question. Also note that you are specially punished because you share office space with the team, while other former team members don't have this issue.

This is important to keep in mind because you must involve the PM2 in your solution and he should lead any kind of agreement that you decide together and any effort from your side you should split it with the rest of the team also if too big for your project to absorb it, and even if it is not because I am sure your senior is not the best developer to solve all the questions he is being addressed (the project must be big enough with 8 developers so that he doesn't master all the code). You may require then to escalate the issue to your management so that they support and track progress of your transfer initiatives.

Next point is to have an RCA, root cause analysis, of the questions so that you see the kind of doubts that still remain and even who the questions come from. You may discover that the training required is not only related to the project domain but to the technologies used, specially if as you say the new members are quite junior. Maybe the questions where addressed in the technical sessions and trainings that you had, then: Were they clear enough? Were they correct? Were they addressed?

Ask your senior developer to write down and classify the questions, I would even track the questions as issues or bugs. This will help you in your RCA effort and later on will help you to distribute the questions to different people to answer them even if they are not in the same office. Also, once you force people to write the questions the number will get reduced. The effect is the same as asking in public, most people don't dare but they don't mind asking later to the person privately. Also it can be a good way to introduce the Duck technique that has been suggested in the thread. Last but not least, it can be a base for your knowledge base or FAQ.

And if you need support for all this, just make visible the impact foreseen on your project, on your developer productivity and motivation. Don't wait for delays to be visible, because they will be and then nobody will listen that it was not your fault.

Answer 2

Duck

First, introduce the equivalent of a stuffed duck in the office. Questions should always be asked to it first. This one depends on the level of trust you have from that other team, and their own technical level. Make sure they don't take it as poking fun at them for not being able to work on their own.

Question ticket board

Then, introduce a question ticket board. I used this to manage interruptions from team members when I was doing Pomodoro and still had to be available to others.

Basically, that was simply having yet another post-its board, on which people with questions would write down one or two key words for them to remember their question, and then put the post-it on some reserved space next to my desk. Then, when I was available, I would take the top post-it, FIFO style, and went to answer it with the asker.

This has the following advantages:

• Transforming interruptions into managed time off the project. Not as good as being rid of them, but probably the best tradeoff.
• Answering only one (or n, depending on the actual amount) question at a time forces askers to cooperate and self-organize to decide which question should be asked first. This adds a bit to the cost for asking too many questions, while not making asking few questions costly at all.
• Making the quantity of questions visible for everyone, calling for responsibility from askers, especially if you are in the same room.

Documentation

Have askers document the given answers. It seems you already asked them to do so, but all the usefulness of a knowledge base depends on its implementation.

Make sure they don't simply write down “question: answer” in a file, no one will ever read it. Have them document or refactor the parts that gave them problems, boyscout-style (I'm assuming a programming project here, but hopefully you can find an equivalent in your domain if it is different).

Basically, have them understand that they should bend the material to their understanding, in order to foster a sense of possession and responsibility. This will also have the side effect of increasing the cost of questions to them, which seems to be something you might desire if it has already been some time since the transition started, and you noticed a rise in questions (based on “ lately the questions keep on coming even after talking to them”).

Answer 3

I think pair programming could really help you out. Pair your team members up for the day, and switch the pairs everyday. It will do two things to specifically address your needs:

First it will help get your team used to asking questions of someone other than the resident expert. There may be someone that knows almost as much as he does, but no one knows it (this is usually the case, teams seem to become fixated on a single individual as a 'guru' even when it isn't the case). Pair programming can get your team asking questions of each other, and it will answer questions they didn't know they had.

Second, it will level the knowledge playing field much quicker than training sessions alone. I really don't know of a better way for an experienced programmer to impart knowledge to less experienced ones than pair programming.

Even if you don't go this route, I think there is only one major thing to watch out for: your team members asking questions that they could have easily found the answer to with 30 seconds of googling. This is a bad habit for everyone to get into, and its also a difficult one to break without doing something invasive. Talk to the resident expert and see if he thinks this is happening, and if he is willing to help you. A few responses of, "didn't you google that?" from him will be worth more than a policy from you.

Edit

Somehow in all my wisdom I missed that it was the other team's members coming to your team to ask questions. In this case pair programming wouldn't fix that particular issue (although that doesn't make it any less awesome). You could however, suggest to the other PM that he/she try instituting it of his/her team.

Answer 4

With patience. Performance goes up and down. Motivation goes up and down. Teaming goes up and down. Op tempo goes up and down. The point is, everything is variable and in a very random way. Trying to control it is futile.

This is where planning and risk management come to play. This variability should have been part of your planning and risk assessments so your targets were set to accommodate some of the variability and your contigent reserves were adequate.

Answer 5

You have a couple of alternatives:

1. Improve the training. It doesn't seem like what you've done to bring the team up to speed has worked, which isn't necessarily surprising. Think back to your school days and how many concepts/ideas were really understood after one presentation. Step back and look at the questions they have. Is there a pattern that will let you figure out where the shortfalls are, what additional training/materials you could provide, etc?
2. Control the conversations. Have your key team member set aside blocks of time when s/he is NOT available for answering questions. This will increase productivity by concentrating interruptions into a fixed part of the day.
3. Carry on as-is. If you are still meeting the goals of your sprints and the schedule/budget/scope of the project aren't being impacted you may want to put this issue lower down on your priority list.
4. Order a stop to the questions. IMO this is the worst alternative. The only benefit is helping make your most experienced person more productive, but this will be more than offset by the likely loss of productivity of everyone else, added work around quality assurance, rework to address incorrect assumptions on the part of the less experienced team members, etc.

Answer 6

Some good answers so far. I think the solution is a combination of all of them. It all comes down to people management, dealing with human beings.

Since you said 'my team' I'm assuming that you have sort or leadership role. I also assume the other team has someone in this role as well. I suggest the two of you meet, along with the team member with the knowledge, and simply say "Here's the situation, and here's how it's impacting my project. How do we resolve it so that your team gets what it needs, with as little impact to mine as possible? And how do ensure that the information being transfered is done so that the questions only have to be asked once"

It will take the three of you to figure out what to do. The two team leads can discuss ideas or options that work within the project context (schedule, etc.), but the team member has to agree as well. He has to be comfortable with how things are going to be handled after all it's HIS time and concentration being impacted.

Answer 7

Indeed a lot of good answers here, so I'll summarize what I'll do based on other answers:

Summary:

Move the ownership of this issue away from the team. First, would be to get one appointed person from their team that will be responsible for the communication with the senior developer (this will be the speaking duck everybody will ask their questions to), so the classification and documentation of the Q&A becomes their responsibility.

Second, speak to the senior dev that will be managing the time for answering these final questions by setting aside some blocks of time during the week, so it can be included in the initial sprint planning.

Third, involve both PM in setting up and, since the other team is not using scrum, try a joint retrospective after 1 week to see how the situation can be improved and track the progress.

Answer 8

With a team that young, consider temporarily moving one of your senior people on the "good" team to the new team. This person can then help mentor the young team and deflect most of the support issues until they can become self-sustaining. Losing one developer full time is better than the whole team being distracted several times a day.