Taking on another project, or workstream, or idea, or investigation in a team is pretty much entirely downside.

- more context switching, which means people get cranky faster

- lower bus factor for any piece of work, until its 1 dev per thing and that things stops of the dev isn't there

- lower people count on work means everything takes how long 1 person can do it (2 people is twice as fast for parallizable work)

- slower dependency resolution until something as basic as getting a PR reviewed is a big deal

- fewer people seeing the problem means less experience brought to bear, which reduces speed gains from having seen this stuff before

And more besides. For every project the goal should be maximum parallelism.

There ends up being no shared vision of how it all works. Disparate pieces are developed and some poor sap ends up gluing them together in a painful manner, 2-3 months later. QA finds some edge cases, driving last minute fixes and delaying release.

Ultimately more difficult bugs escaped QA and go on to result in customer escalations.

Eventually, the feature gets cleaned up a year or two later, after another month or two of development effort.

Customers just see a broken feature for 2-3 years and give up on it.

So. Much. Waste.

It’s not about having a Chief Navel-Gazer Architect. Development on a shared code base is just not as parallelizable as one would desire.

One has to thoroughly understand exactly what they are doing and know all the relevant considerations. It isn’t practical for a group to all be capable of such for every feature. And nobody is going to take the time to write a detailed internal API spec that would even allow such to be possible…

What year is it?! Does anyone still blame QA?! If so, please consult the calendar and enter the 21st century!

Is this slop, or poor english skills? Is there any peer review barrier to being published here? Because this kind of looks like a low-effort 4-page survey of other people's data with no original empirical evidence. In other words, probably should've been a blog.

Don't get me wrong, the subject and abstract is a topic I relate with so I'll probably still read it. But curious if this is normal. I just want to know how much salt I need to use.

Organizations can't even track and improve on sprint performance. They aren't gonna track and improve inefficiencies either, because they have no motivation to improve. Even if they're losing money and customers due to their product sucking, they still won't see those inefficiencies as the cause of their problems. They'll instead imagine that what they really need is to push more sales/increase initial subscriptions, or add a killer new feature they have no time to implement, or pivot to a different business model. But their lack of rigor is only partly due to executive stupidity; the other part is mediocrity. If you have lazy, ignorant devs, you're gonna have lazy, ignorant process, leading to all the waste.