Comment Companies need to recognise this as a problem (Score 2) 224
I used to work in a test tools team and we'd get a lot of visitors wanting help interpreting test results and preferably fix their bugs for them. It was manageable until we got close to release. By that point our scrum master moved to the desk closest to the door and would intercept everyone coming into the room. He'd have them describe their issue to him and then he'd make the call whether to disturb anyone in the team. Still, there was almost constant talking in the room so headphones were a must.
I've found that one thing that causes a lot of unnecessary interruptions is a lack of documentation. One company I worked for kept almost no documentation since "this is a fun workplace and writing documentation is boring". I had to track down multiple people just to figure out how to set up a working build environment. Another problem is knowing who to ask. Spending some time to create a knowledge matrix and assigning a go-to person for each area helps limit the amount of people that get disturbed and also spread the load.
Code reviews are another thing that can cause a lot of interruptions. I don't have much experience with code ownership and automatically assigning reviewers so I can't say how well that works in practice.
I've found that one thing that causes a lot of unnecessary interruptions is a lack of documentation. One company I worked for kept almost no documentation since "this is a fun workplace and writing documentation is boring". I had to track down multiple people just to figure out how to set up a working build environment. Another problem is knowing who to ask. Spending some time to create a knowledge matrix and assigning a go-to person for each area helps limit the amount of people that get disturbed and also spread the load.
Code reviews are another thing that can cause a lot of interruptions. I don't have much experience with code ownership and automatically assigning reviewers so I can't say how well that works in practice.
