I'm pretty certain that the one factor above all others that makes software delivery slow down is doing too many things at once. You should aim to be working on one project at a time in your team.

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.

For us, review latency was obviously a problem so we eliminated it (for most tickets, anyway) by making the handover synchronous. Get on a call with the reviewer when it goes into the review column. The win from eliminating review latency massively outweighs the context switch cost for the reviewer. All the more so when the patch is small enough to actually read through on the call, so if there is anything immediate to address you can ping-pong it without anything waiting.

"Stop blaming QA.."

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

In my experience, things head south when managers see “feature X requires 4 person-months effort” and then assign 4 people to work on it, with 2-3 being junior, and the remaining multiplexed with other tasks. They think this will allow them to meet their goal of being feature complete in a month.

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…

> "When coupling getting higher, considerable amount of time is wasted in heavy coordination, alignment, and shared strategy. The other side of the same coin, considerable amount of time is lost when one component breaks for everyone"

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.

Great read. Learned the hard way that we need QA roles.

Great paper. QA's role in software is underrated.

> Organizations needs to prioritize measuring for these inefficiencies that lowers the quality bar, churn software engineers, and slow down delivery process. Once measured, organizations should add mechanism, both technical and procedural to limit the waste

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.

[flagged]

It's hard to believe something when I saw the opposite work in practice. Removing QA makes developers care about production. You can say now they are wasting part of their time doing what QA did but to me it's not wasted time. Incidents went down both times I saw it happen, and stayed down.