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.
When I was a middle manager at a past job, my team kept getting bombarded with meeting requests (it was a "fire drill all the time" kind of place).
I ended up making a 4 hour "team meeting" every Friday morning to give them focus time.
I mentioned to them that they could have done the same on their own if they wanted. My team lead pointed out that since our calendars were visible in the department, having me as the organized gave the meeting more "weight" and so line employees were less likely to push for time in that slot.
That's a good point, thanks for saying it. Speaking as one of such developers who had trouble with it for a long time, plenty of us might end up feeling shy or insecure about making proactive interventions to secure time for ourselves or our teams - all while our managers might be assuming we'll make such moves when needed. Sometimes all it takes is an explicit permission from a person in position of power - them saying to subordinates, "it's fine if you block off focus time for the team in the company calendar". And, per your example, it's even better when followed by assurances of support, such as being an organizer or confirmed invitee. For better or worse, a lot of inter-team dynamics ends up being about looks.
Half my day is blocked with “no meetings please unless urgent” and it works great - but I guess it’s part of the org culture that we respect each others time and don’t do a lot of unnecessary meetings in general anyway so idk if it would work that well somewhere else
That's an interesting experience and a valuable info.
But I wonder what would be the CEO's side of the story. I'm sure his behavior was bad, I'm not pretending the opposite. But maybe he also had reasons (misguided reasons, sure, but still reasons) to act as he did. Or maybe he did not have any reasons, it's also possible.
I've observed cases where indeed people were disturbing too much software developers.
But I've also observed cases where software developers were not enough aligned with the business side, despite them being 100% sure they were.
It's a tricky situation: being in the team means that you are not impartial, you don't have a remote view, you are only seeing one side of the story. I had situations where I've observed some non-dev team explaining their needs, then the software team went away, and then came back with something that was not what the non-dev team asked. Not only the non-dev team was indeed not satisfied, but I was agreeing to them: it was not what they explained, I was there, I understood what they said at the time. Worst, in the majority of the cases, the non-devs don't just say "no, it's incorrect", they try to find a compromise. Usually, it comes from the fact they have no idea what is possible or not, and just assume that if the devs did not do what they were expected, it means there are good reasons for that (either it is not possible, or that there were others things they did not know about, such as other requests from other part of the business). As someone with a lot of developing experience, I was able to see that the problem was that the devs just underestimated the need to fully understand the business side.
It's very tricky, because for a dev (or a dev-side person), it is very easy to just ignore that. If they ask for adjustment, it's "they don't know what they want". If they point at some requirements and underline that it does not mean what the devs thought it meant, it's "these requirements were badly written". And in the majority of the case, the business-side just makes do with the sub-optimal solution and the dev-side is considering that they successfully delivered. And similarly, I've also seen some devs being happy to be very productive, going very fast in developing something ... that the business did not need at all. When not adopted, it was again blamed on the business-side for not using the solution they've developed, rather than to wonder if what they have done was indeed productive or not.
The CEO in this example is an idiot, but it does not mean that magically the other side is able to be impartial when judging the situation.
The fact that one is bad at their job does not imply that someone else is good at their job. Why is it hard to accept that maybe being in a dev team doesn't mean you're good at your job?
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.
Peopleware is indeed still very relevant. Always felt Slack by DeMarco made important points around efficiency seeking damaging actual effectiveness, which I always found very convincing and chimed with my own experience.
Microsoft Teams is perhaps the worst communication software your company can have for Software Engineers. People usually don't use the half-baked threads capabilities because they're separate and not intuitive, so it's usually just endless chat messages, all at once. And so you get constant pinging all day. And then I need to mute my Teams chats, which is also risky because I could have gotten an important message.
A "quick question" from non-engineers (and even fresh engineers not yet used to the idea of focusing on work at work, or in general people who don't understand they're not the centre of the world) is usually carrying within it a request (or demand) to do something for the other person. A genuine "quick question" is one to which a quick "I don't know" or "not now!" is an acceptable answer. Those are easy to navigate - if you feel like considering it fully will break your focus, you can just decline answering it. If you can't, it means the question is really a disguised attempt to offload work onto you; engaging with it is giving permission to the other party to pull you in and try to keep you there.
Additionally, a break might be an opportunity for your mind to continue working on whatever it was you left off with, whereas an interruption explicitly redirects your attention to another topic.
When I’m deep in the weeds on a task, stepping away for a walk in the park, a workout, or to prepare a meal or some coffee, affords me the opportunity to clear the micro details of the task from my mind while retaining the macro at the tip of my attention. This state is very frequently where the best insights on the task emerge, whereas an interruption resets both micro and macro attention entirely to something else.
> I find taking mini breaks, whether visiting the restroom or being interrupted by my kids to be quite beneficial actually.
For me, it depends. When working at home with kids around, I actually dread the restroom break or making myself a cup of tea, because in those two minutes I'm out of the home office, it's virtually guaranteed they'll drag me into whatever is happening at home at the given moment, wiping my focus entirely.
Sometimes this does break me out of being fixated on doing the wrong thing, but more often than not, it just plain prevents me from doing any thing at all.
Dailies have the social contract of "you get to talk to the developers every morning, so shut-up the rest of the day", what on theory should be really great.
The only problem is that all the problem people never take the hint, and the well-behaved people tend to take it to an extreme. So on practice it both doesn't get rid of the interruptions, and delay everybody's work due to the latency you need for avoiding interruptions.
People have complained to my boss when I've said the standup was designed to be as short as possible, maybe 10 minutes max, because it was done standing up. It's not called the sitdown. But ours can run over an hour. It's agonizing sitting there for an hour waiting to hear my name among the 99% of noise entirely irrelevant to me.
> It's agonizing sitting there for an hour waiting to hear my name among the 99% of noise entirely irrelevant to me.
More than once I've been asked discretely by my PM if everything is OK with me, because half an hour down a team meeting whose contents is "99% of noise entirely irrelevant to me", I'm too exhausted trying to control my movements to keep my body from telegraphing the fact I'm bored out of my mind. Turns out, to an outside party, I start looking like I haven't slept the night, or am about to get a stroke, or something.
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.
> "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.
Ironically, if I were to give one-sentence summary of what the idea behind Agile is, it would be exactly that: "see what approaches work and change what doesn't work for the team". Running through that feedback loop rapidly is the whole point of Agile, and the one thing that actually distinguishes it from typical management methods at the time (as opposed to silly comparisons with "waterfall" boogeyman that never even existed).
Everything else is process - the thing that's supposed to be sculpted. Focusing on that is committing the sin explicitly called out in the Manifesto - putting process over people.
> 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.
Scrum is a bit too proscriptive to allow for that. One of the things that "works" is killing sprints, for instance, but scrum isn't scrum without a sprint.
The problem is that those are a really vague and metaphorical 4-5 lines so it's hard to argue against somebody projecting whatever the hell meaning they want on to it.
I'd argue that "agile" where I have done it and it worked well is at its core about tightening up OODA loops - with code (refactoring+tests+iterative improvements), with customer interaction (frequent interaction/experiment driven tests), with team organization (retros, adapting team processes).
Feedback loops are, however, not mentioned once in the philosophy and neither are any concrete examples of "agile" or "not agile".
Agile as a concept will stop being broken when people stop saying "to me, agile means X". Which will probably never happen - I suspect people will just stop talking about it one day and start using different terms for all the concrete steps that are sometimes filed under "agile" but which actually work.
That's a bit misleading. agilemanifesto.org also hosts a (still short, but way more concrete) Twelve Principles of Agile Software: https://agilemanifesto.org/principles.html
(Also worth noting that scrum and most of the best known agile methodologies predate the manifesto; the manifesto was formed from guiding principles of those methodologies, not the other way around: https://agilemanifesto.org/history.html)
It is the pseudoscience of Taylorism and 'Scientific management', not the manifesto, which is really just a repackaged form of modern organization theory.
How unsurprising, than, that every little town and village has their own folk religion built around those 4-5 sentences. No wonder this topic is a holy war.
There’s people that don’t have adhd that can handle notifications. That’s the thing with being impulsive - those disorders are mental illnesses (quite technically) and will limit your net worth. It’s like why do all developers need to be listening to the orchestra or radio while programming?
> It’s like why do all developers need to be listening to the orchestra or radio while programming?
On one hand: well, when you have to keep big mental models in your head you don't want to be interrupted. The big headphones serve to indicate you are in the middle of work.
On the other hand: have you ever been on a construction site? You'll hear some radio usually.
Yup, used this exact same model for some time. The problem is it does not block voice sound as well as other. But anything else? Silence. It is crazy how loud an AC can sound after you remove those.
Maybe those people who "can handle notifications" are just less much less productive as a baseline to start with? Hence they don't feel the impact as much.
I often find this with people who think they are good at "multitasking".
It's not at all a mental illness. That's ignorant.
Some of the most technically adept people I know are on the spectrum and they are incredibly valuable. We're talking Chief architects, lead/senior engineers, Network engineers, and the list goes on.
People like that probably have divergent neurochemistry compared to you.
Learn to leverage that asset and stop being a Karen.
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.
In defense of middle managers:
When I was a middle manager at a past job, my team kept getting bombarded with meeting requests (it was a "fire drill all the time" kind of place).
I ended up making a 4 hour "team meeting" every Friday morning to give them focus time.
I mentioned to them that they could have done the same on their own if they wanted. My team lead pointed out that since our calendars were visible in the department, having me as the organized gave the meeting more "weight" and so line employees were less likely to push for time in that slot.
That's a good point, thanks for saying it. Speaking as one of such developers who had trouble with it for a long time, plenty of us might end up feeling shy or insecure about making proactive interventions to secure time for ourselves or our teams - all while our managers might be assuming we'll make such moves when needed. Sometimes all it takes is an explicit permission from a person in position of power - them saying to subordinates, "it's fine if you block off focus time for the team in the company calendar". And, per your example, it's even better when followed by assurances of support, such as being an organizer or confirmed invitee. For better or worse, a lot of inter-team dynamics ends up being about looks.
Half my day is blocked with “no meetings please unless urgent” and it works great - but I guess it’s part of the org culture that we respect each others time and don’t do a lot of unnecessary meetings in general anyway so idk if it would work that well somewhere else
That's an interesting experience and a valuable info.
But I wonder what would be the CEO's side of the story. I'm sure his behavior was bad, I'm not pretending the opposite. But maybe he also had reasons (misguided reasons, sure, but still reasons) to act as he did. Or maybe he did not have any reasons, it's also possible.
I've observed cases where indeed people were disturbing too much software developers.
But I've also observed cases where software developers were not enough aligned with the business side, despite them being 100% sure they were.
It's a tricky situation: being in the team means that you are not impartial, you don't have a remote view, you are only seeing one side of the story. I had situations where I've observed some non-dev team explaining their needs, then the software team went away, and then came back with something that was not what the non-dev team asked. Not only the non-dev team was indeed not satisfied, but I was agreeing to them: it was not what they explained, I was there, I understood what they said at the time. Worst, in the majority of the cases, the non-devs don't just say "no, it's incorrect", they try to find a compromise. Usually, it comes from the fact they have no idea what is possible or not, and just assume that if the devs did not do what they were expected, it means there are good reasons for that (either it is not possible, or that there were others things they did not know about, such as other requests from other part of the business). As someone with a lot of developing experience, I was able to see that the problem was that the devs just underestimated the need to fully understand the business side.
It's very tricky, because for a dev (or a dev-side person), it is very easy to just ignore that. If they ask for adjustment, it's "they don't know what they want". If they point at some requirements and underline that it does not mean what the devs thought it meant, it's "these requirements were badly written". And in the majority of the case, the business-side just makes do with the sub-optimal solution and the dev-side is considering that they successfully delivered. And similarly, I've also seen some devs being happy to be very productive, going very fast in developing something ... that the business did not need at all. When not adopted, it was again blamed on the business-side for not using the solution they've developed, rather than to wonder if what they have done was indeed productive or not.
This isn't tricky at all. If the CEO were concerned that developers weren't doing their jobs correctly, that's a really easy Slack message.
Why is it hard to accept that maybe being a CEO doesn't mean you're good at your job?
The CEO in this example is an idiot, but it does not mean that magically the other side is able to be impartial when judging the situation.
The fact that one is bad at their job does not imply that someone else is good at their job. Why is it hard to accept that maybe being in a dev team doesn't mean you're good at your job?
It's a manifestation of insecurity and lack of trust in the team.
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
Peopleware is indeed still very relevant. Always felt Slack by DeMarco made important points around efficiency seeking damaging actual effectiveness, which I always found very convincing and chimed with my own experience.
Microsoft Teams is perhaps the worst communication software your company can have for Software Engineers. People usually don't use the half-baked threads capabilities because they're separate and not intuitive, so it's usually just endless chat messages, all at once. And so you get constant pinging all day. And then I need to mute my Teams chats, which is also risky because I could have gotten an important message.
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.
Choosing your break isn't an interruption. An unexpected, external tangent is.
One single "quick question" doesn't do a lot of harm...
If you have an average of 4/day or more, it will probably consume all of your working time. But one of them isn't a problem at all.
And there's the problem, because it's both not a problem in small numbers, and a DoS attack still in small numbers.
A quick question from a fellow engineer is almost always quick; unfortunately, that's not the case for most other situations.
A "quick question" from non-engineers (and even fresh engineers not yet used to the idea of focusing on work at work, or in general people who don't understand they're not the centre of the world) is usually carrying within it a request (or demand) to do something for the other person. A genuine "quick question" is one to which a quick "I don't know" or "not now!" is an acceptable answer. Those are easy to navigate - if you feel like considering it fully will break your focus, you can just decline answering it. If you can't, it means the question is really a disguised attempt to offload work onto you; engaging with it is giving permission to the other party to pull you in and try to keep you there.
Well, one question probably causes around 10-15 minutes of harm (not counting the time to actually answer the question).
So yeah - have 4 of these a day and you've wasted an hour. Have this every working day and you've already wasted half a day per week.
This seems like a failure of emotional self-control...
The study had only 20 people.
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.
Sure, and I agree with you, but what you described is just a break, not an interruption.
These breaks were taken at a "natural" time, when you felt one was needed. By definition, an interruption is a "break" when you don't want one.
Additionally, a break might be an opportunity for your mind to continue working on whatever it was you left off with, whereas an interruption explicitly redirects your attention to another topic.
When I’m deep in the weeds on a task, stepping away for a walk in the park, a workout, or to prepare a meal or some coffee, affords me the opportunity to clear the micro details of the task from my mind while retaining the macro at the tip of my attention. This state is very frequently where the best insights on the task emerge, whereas an interruption resets both micro and macro attention entirely to something else.
My son storming into my room unexpectedly is definitely an interruption.
> I find taking mini breaks, whether visiting the restroom or being interrupted by my kids to be quite beneficial actually.
For me, it depends. When working at home with kids around, I actually dread the restroom break or making myself a cup of tea, because in those two minutes I'm out of the home office, it's virtually guaranteed they'll drag me into whatever is happening at home at the given moment, wiping my focus entirely.
Sometimes this does break me out of being fixated on doing the wrong thing, but more often than not, it just plain prevents me from doing any thing at all.
Agile is number one interuption of all enginnering activity .
Dailies have the social contract of "you get to talk to the developers every morning, so shut-up the rest of the day", what on theory should be really great.
The only problem is that all the problem people never take the hint, and the well-behaved people tend to take it to an extreme. So on practice it both doesn't get rid of the interruptions, and delay everybody's work due to the latency you need for avoiding interruptions.
People have complained to my boss when I've said the standup was designed to be as short as possible, maybe 10 minutes max, because it was done standing up. It's not called the sitdown. But ours can run over an hour. It's agonizing sitting there for an hour waiting to hear my name among the 99% of noise entirely irrelevant to me.
> It's agonizing sitting there for an hour waiting to hear my name among the 99% of noise entirely irrelevant to me.
More than once I've been asked discretely by my PM if everything is OK with me, because half an hour down a team meeting whose contents is "99% of noise entirely irrelevant to me", I'm too exhausted trying to control my movements to keep my body from telegraphing the fact I'm bored out of my mind. Turns out, to an outside party, I start looking like I haven't slept the night, or am about to get a stroke, or something.
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.
> "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.
Ironically, if I were to give one-sentence summary of what the idea behind Agile is, it would be exactly that: "see what approaches work and change what doesn't work for the team". Running through that feedback loop rapidly is the whole point of Agile, and the one thing that actually distinguishes it from typical management methods at the time (as opposed to silly comparisons with "waterfall" boogeyman that never even existed).
Everything else is process - the thing that's supposed to be sculpted. Focusing on that is committing the sin explicitly called out in the Manifesto - putting process over people.
> 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.
Scrum is a bit too proscriptive to allow for that. One of the things that "works" is killing sprints, for instance, but scrum isn't scrum without a sprint.
> 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.
Agile seems to be used to refer both to a form of cult and a form of software development interchangeably and I think it's too late to fix that.
It’s worth pointing out that the “Agile” philosophy is literally 4-5 lines long:
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
> That is, while there is value in the items on the right, we value the items on the left more.
The thing I think everyone has grown to universally despise is the cargo cult of “Scrum” that got bolted onto that.
The problem is that those are a really vague and metaphorical 4-5 lines so it's hard to argue against somebody projecting whatever the hell meaning they want on to it.
I'd argue that "agile" where I have done it and it worked well is at its core about tightening up OODA loops - with code (refactoring+tests+iterative improvements), with customer interaction (frequent interaction/experiment driven tests), with team organization (retros, adapting team processes).
Feedback loops are, however, not mentioned once in the philosophy and neither are any concrete examples of "agile" or "not agile".
Agile as a concept will stop being broken when people stop saying "to me, agile means X". Which will probably never happen - I suspect people will just stop talking about it one day and start using different terms for all the concrete steps that are sometimes filed under "agile" but which actually work.
That's a bit misleading. agilemanifesto.org also hosts a (still short, but way more concrete) Twelve Principles of Agile Software: https://agilemanifesto.org/principles.html
(Also worth noting that scrum and most of the best known agile methodologies predate the manifesto; the manifesto was formed from guiding principles of those methodologies, not the other way around: https://agilemanifesto.org/history.html)
It's not Scrum. Scrum wasn't even the first. (I think it was XP.)
The problem is all the "Agile methodologies". Every single one.
(Also, notice that "Agile methodology" as an idea is already against the first principle there.)
Yes. As soon as you're conducting ritual ceremonies such as daily standups, you're no longer agile.
It is the pseudoscience of Taylorism and 'Scientific management', not the manifesto, which is really just a repackaged form of modern organization theory.
The DOD agile BS PDF covers most of it.
https://media.defense.gov/2018/oct/09/2002049591/-1/-1/0/dib...
Once the consultant forms start to monetize the GAO's agile assessment guide things should get better IMHO.
Unless that gets co-oped somehow, which is possible.
How GM screwed up on the NUMMI plant shows how it is a Taylorism problem if you want something outside of tech.
But even TOGAF and ITIL are adjusting because the feds will require it.
Taylor measured people loading pig iron into train cars, faked a lot of things and the BCG/McKinsey types packaged and solid it.
It has always been BS, is part of why the US manufacturing sector failed as well as why the USSR failed.
Pretty hard to kill but it needs to die.
How unsurprising, than, that every little town and village has their own folk religion built around those 4-5 sentences. No wonder this topic is a holy war.
[dead]
[dead]
There’s people that don’t have adhd that can handle notifications. That’s the thing with being impulsive - those disorders are mental illnesses (quite technically) and will limit your net worth. It’s like why do all developers need to be listening to the orchestra or radio while programming?
> It’s like why do all developers need to be listening to the orchestra or radio while programming?
On one hand: well, when you have to keep big mental models in your head you don't want to be interrupted. The big headphones serve to indicate you are in the middle of work.
On the other hand: have you ever been on a construction site? You'll hear some radio usually.
Yeah, wearing headphones doesn't necessarily mean they're actually listening to anything.
Agreed, these [1] work very well in open plan offices.
[1] https://www.amazon.com/dp/B00CPCHBCQ
Yup, used this exact same model for some time. The problem is it does not block voice sound as well as other. But anything else? Silence. It is crazy how loud an AC can sound after you remove those.
Maybe those people who "can handle notifications" are just less much less productive as a baseline to start with? Hence they don't feel the impact as much.
I often find this with people who think they are good at "multitasking".
I certainly handle distractions better with my ADHD medication, personally.
And do you also feel that your productivity is higher in general (without distractions) when taking medication?
Hard disagree.
It's not at all a mental illness. That's ignorant.
Some of the most technically adept people I know are on the spectrum and they are incredibly valuable. We're talking Chief architects, lead/senior engineers, Network engineers, and the list goes on.
People like that probably have divergent neurochemistry compared to you.
Learn to leverage that asset and stop being a Karen.
Feigned wisdom isn't.
To be excellent, you are by definition "not normal".
I believe handling interruptions is a skill that is learned. Isolating yourself prevents you from learning it.
You can turn notifications off.