In async work, if you stop working on your thing to respond to another thing, you get interruption, longer lead time for your thing, and higher WIP. If you mute notifications you get longer wait times and high WIP for the other thing.
»you should do reviews way faster and you’ll get way smaller PRs to review.
»Funnily, concept of WIP limit is invisible and unknown to most of XP teams. They do it without even knowing or trying to do it.
»often tend to also experience lack of trust from stakeholders.
»in teams that are not able to sustainably deliver high-quality software. And XP and Continuous Delivery are preconditions for that.
»Trying to do more of Continuous Integration by trying to continuously integrate is a suboptimal intervention point in the system (can be a monitoring point, though).
»for minimizing (lead) time to recover from incidents and the way to achieve it, somehow we fail to realize either the need for minimizing the lead time to value for our customers or the way to achieve it.
»I tend to reason about the design of the code and system architecture by thinking about:
»you’re working on something else than the person trying to interrupt you.
»(some call this tech debt) piling up in the codebase because latency in the async code review process signals a high cost of review which in turn hinders continuous refactoring.
»