Interruptions are productivity and creativity killers. Middle managers are of questionable utility but that layer of an organization would be much more effective if it focused ruthlessly on removing distractions.
I worked at a small company where a significant portion of my effort went toward shielding my team from the distractions created by a CEO who couldn’t seem to help meddling in every aspect of the business. I think it’s because he started out doing, or at least being involved with, many of the functions of the company and had a hard time letting go as we grew. Even after the organization grew to 50+ people he couldn’t keep himself out of the nitty gritty details, but the format of the distraction changed over time. Instead of walking up to people and interrupting them in person (a double whammy according to this study, including both an “important” person and the in-person aspect), he would send what we called “Slack attacks” throughout the day. These were paragraphs-long Slack messages without any semblance of organization, punctuation, or line breaks. Fortunately, many of these messages were sent during the very early hours of the morning so they could be dealt with first thing in the AM, but that wasn’t always the case.
In the first phase I literally moved my team location and reorganized the desk arrangement so it was harder for him to get in and bug everyone. I had to “guard” the area and try to stop him from physically entering the space, which was always a strange dance. I couldn’t control his Slack messaging behavior so I worked with people to understand that while yes “the CEO is asking you for urgent work in Slack” seems like a valid reason to switch gears, but instead let me work to figure out what actually needs to be done and we’ll catch up later about what to do.
It was a weird dynamic but there was no doubt the distractions were a drag on performance. Every time he went on vacation we saw a marked increase in productivity, and more creative solutions seemed to come up as well. I don’t wish this type of environment on anyone but in a way I’m glad to have gone through it and learned some lessons about interruptions and how to avoid them.
40 or so years later, the book Peopleware by DeMarco and Lister remains the best quantitative study on environmental impacts on developer productivity.
The world has changed significantly since it was written, so you have to translate their measurements to modern contexts, but it's easier to translate real data on human behavior than to guess based on guesses.
the OP is a journalistic summary of
Breaking the Flow: A Study of Interruptions During Software Engineering Activities
Yimeng Ma, Yu Huang, Kevin Leach
(2024) icsi Portugal
it's not properly quoted, but it's directly linked, prominently.
yes, I agree, peopleware is on the must have reading list, but this article certainly is not guesses on guesses
I find taking mini breaks, whether visiting the restroom or being interrupted by my kids to be quite beneficial actually.
It gives my mind a few seconds or a minute or two to do background processing and potentially come up with a better way of doing something.
Or to realize that I’m not working on the most important thing in the first place.
We're also a picky bunch. A short coffee break or a chat with someone I like doesn't hurt as much as a "quick question" from Joe in Sales does.
The study had only 20 people.
Agile is number one interuption of all enginnering activity .
I've found that agile works if velocity is static and used for estimates ONLY and is flat over time. Once velocity is measured as an output metric and there is an attempt to improve it, you've just left agile and are now in a morass.
In the end, very simple Kanban is the way to go if your org can handle it.
Not sure if this is supposed to be sarcasm, but only from the direction of "lock the developers in a room and look what surfaces after half a year".
Picking what to work on for [time] without external additions is a pretty good improvement over getting new assignments daily.
Or maybe you're just doing it wrong, I'm not here to defend anything codified in Agile, I'm just saying that elements of what most people call scrum has been the best I've seen in over 20 years. Maybe I just missed the days of locking yourself in your single office.
I suspect it's more about the way many people experience "scrum".
The basic building blocks can actually work great, it's often how they are executed and how many places go very much micromanagement wrapped in agile's skin while also instituting lots and lots of meetings - total opposite of what both Agile and XP advocated.
Some of the best agile/scrum I ever worked under came from "Scrum master" who explicitly stated that one of his jobs was to see what approaches work and change what doesn't work for the team.
> see what approaches work and change what doesn't work for the team.
unfortunately from my experience, "what works" can vary wildly from person to person. One person wants to be given a task and left alone to understand it and write some throwaway code as part of the understanding process. another person wants to bikeshed it to death first before letting you touch any code. so the first person has to hide the work on the prototype and pretend to come up with the insights for the first time during the bikeshedding session.
Which is why their job was to figure out a model for the team. This specific team.
Sometimes you can compromise, sometimes you can figure a proper allocation of resources, sometimes you can part amicably instead of murderously.
> of what most people call scrum has been the best I've seen in over 20 years
If you're phrasing it like that I've been doing agile since way before anyone invented the term.
But that's only 10% of cult agile, which is what is practiced generally.