Planning too soon?
The higher the utilization in the system, the lower the availability and responsiveness, and the earlier you feel an urge to start with work in order to plan and coordinate it.
»The higher the utilization in the system, the lower the availability and responsiveness, and the earlier you feel an urge to start with work in order to plan and coordinate it.
»the cost of code review while co-creating (pairing/mobbing) is zero.
»you have to take into account how long did it take you to make a change (processing time) not just how long it took to get a review (wait time).
»and 3 hours to get a review for the change, I’m either not going to rename the method or I’m going to rename it as part of some later change.
»in the design of methods and messages is that it hugely reduces coupling and enables faster current and future changes.
»have way higher chances of building an environment of trust, empathy, and psychological safety.
»There are different levels of feedback loops embedded in one another (e.g. compiler, tests, peer feedback, production, customers, etc.).
»we’re not going to know if our thinking is in fact a balancing act in the middle of the spectrum or actually at one end of it (without us even knowing it).
»(non-constraints) is that it makes things even worse in the part of the system that is the one that should be optimized (constraint) and consequentially the whole system.
»Besides other benefits, reducing batch size increases the responsiveness of the system.
»