Estimates don't help with predictability
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.
»Manage the queues, not the work
In order to shorten lead times and increase throughput of the system focus on managing (reducing) the queues, not the work.
»Organizations that end up executing themselves
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
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).
»Collaborative culture will not happen
simply by encouraging people to collaborate more.
»It is more likely
that you’ll do Continuous Integration with centralized (e.g. Subversion) than with a distributed versioning control system (e.g. Git).
»Mob programming = andon cord
I just came to a realization that #mobprogramming is (also) an implementation of “stop the line” a.k.a. “andon cord” concept from Lean…
»Continuous Integration is
a practice of minimizing inventory of unintegrated code.
»It's interesting to see
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.
»Do you know that code reviews with Pair/Mob Programming are virtually free?
An abundance of those is what builds the quality in.
Not a staged and expensive, khm Pull Requests khm, process.