Dragan Stepanović

“To achieve wealth optimize for minimizing losses over maximizing gains”

Try building quality in by shifting left on the collaboration. Instead of mobbing on the outage, mob during the development. Diversity of thoughts, needed skills and system understanding builds the quality in.

With every halving of the PR size, you get 2x more interruptions for each of the reviewers of a given PR. Multiply that by the number of PRs in flight (one person, one PR) and you get the total number of interruptions in the team.
E.g. if it’s mandatory for at least one person to review the PR and if you have 4 developers in a team, total number of interruptions in the team increases 8 times (4x2). Just for one halving of the PR!

The problem is the engineering culture lacking design, refactoring, and incremental development skills that produced it as an artifact.

The ways that we usually set up “cross-functional” teams doesn’t really help us with this, but it’s crucial for each member and role in a product development team to ask these questions on a regular basis:

• “How are our features doing in the production?”
• “Are they meeting users’ needs?”
• “How do we know that that’s the case?”
• “Are they solving the problem that they were supposed to solve?”
• “Is the work and effort we’re putting in delivering value or we’re just spinning our expensive wheels?”

Have you thought about how architecture and functional decomposition of a system influence documentation and a need for it? 🙂

It’s very true that in environments without psychological safety pairing/mobbing or any kind of close collaboration won’t work.

Mob/Pair-Commit-Revert

Actually, most often they hurt predictability because of a narrow focus on achieving the short term goal of meeting an estimate and piling up cruft, which then hurts predictability.

In order to shorten lead times and increase throughput of the system focus on managing (reducing) the queues, not the work.