XP teams are very rare environments where WIP is not skyrocketing
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.
»Teams that are afraid to change the code
often tend to also experience lack of trust from stakeholders.
»Psychological safety and trust go down the drain
in teams that are not able to sustainably deliver high-quality software. And XP and Continuous Delivery are preconditions for that.
»Doing Continuous Integration is a suboptimal intervention point in the system
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).
»While we realize the need
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.
»Just-in-time design and architecture
I tend to reason about the design of the code and system architecture by thinking about:
»You can get interrupted only if
you’re working on something else than the person trying to interrupt you.
»PRs lead to cruft
(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.
»Parallelization of work
can only make a team slower if people need to integrate often. And some teams don’t realize how often they actually need to integrate.
»You can forget about reducing WIP
through co-creation if a culture is not optimized for T-shapeness and nurtures learning.
Otherwise, you get entrenched siloing with unbalanced capacities that very often lead to blockers and pulling in more stuff.