I have a feeling that decision making in organizations in which everyone is so busy that they have no time to build relationships with other people in the company and talk about the topics that are not related to the task at hand will necessarily grind to a halt.
»Because the cost of code review when pair/mob programming is almost zero (reviewer available next to a developer typing the code), the more likely it is to both get the feedback and to get it in a timely manner (as you type the code).
»simply by encouraging people to collaborate more.
»you’ll do Continuous Integration with centralized (e.g. Subversion) than with a distributed versioning control system (e.g. Git).
»I just came to a realization that #mobprogramming is (also) an implementation of “stop the line” a.k.a. “andon cord” concept from Lean…
»a practice of minimizing inventory of unintegrated code.
»that most of the industry is aware that high utilization chokes the flow of a team, but at the same time often fail to recognize that pairing and mobbing provide that needed availability, enabling fast flow out of the box.
»An abundance of those is what builds the quality in.
Not a staged and expensive, khm Pull Requests khm, process.
Systems with high transaction cost will always revert back to big batches no matter how much we try to encourage individual actors to reduce the size of the batch.
Actors act rationally within a given set of constraints imposed by the system, so the intervention point must be at the system level, not on the individual level.
Building quality in and fast flow cannot happen without short feedback loops.
And prerequisites for short feedback loops are high flow efficiency and low inventory.