01 layer
governance
the limits it cannot cross without a human
03 playbooks
1
teams on autopilot
In a high-performing team nothing is someone else's problem. Developers own the quality and stability of what they build rather than handing it to a stage called QA. People optimize for what the organization is trying to do, not for what makes their own team's numbers look best.
That shows up as four habits.
Riskiest thing first. Take on the part most likely to be wrong at the start, while there is still budget and calendar left to change direction. A risk deferred to the last sprint is a risk you will absorb rather than manage.
Alignment on why. The team is solving a problem, not delivering a feature because it appeared on a list. Everyone can say why this item is being worked on now instead of one of the others.
Small batches, continuously deployed. Work in small batches and get each one to production. Beyond the cycle-time argument, it is what lets people see the result of what they built, which is most of where motivation comes from.
Accountability after a failure. When something breaks, the team changes the process so that class of failure cannot recur, rather than resolving to be more careful. Ask why it happened, then ask what would have caught it.