“Help” can be many things: asking a colleague to review some code, asking a teammate to pair while resolving a bug, asking a manager to help remove a blocker, or asking a customer to clarify some requirements. Asking for help enables us to move faster and make fewer mistakes. Not only is it important for us to ask for help, it’s also important for us to respond to help requests too! ...
Builders shouldn’t be put in a position where they’re forced to cut corners, rush out sloppy work, or compromise their professional standards. The business does not get to demand low quality or ask others to risk their reputation or ethics for a deadline. If a task would force someone to do poor work, they must feel safe to raise the issue, explain the risks, and insist on a better alternate approach. ...
Builders need clarity on what to build and which things matter the most. So we need to make sure they have simple listed priorities, and clear requirements so the team can plan and do the work. We’re not aiming for perfection. That isn’t possible. Instead we describe and explain any uncertainty up front. While the team is working inside an iteration, priorities should stay reasonably stable so the builders can finish without constant interruptions. And outside the iteration, the priorities can change.
Customers do not have the right to insist on fixed scope on an immovable date. They do have the right to manage the schedule by changing scope. The most important right here is the right to know—timely visibility that a date is at risk so informed trade-offs can be made. Honoring this right enables change to become a competitive advantage, not a project’s undoing.
Because value is delivered in working, tested increments, customers may stop at any time and still retain a useful system that reflects the investment to date. This is only possible if: Every iteration ends with integrated, shippable software. Documentation, telemetry, and operational handoffs keep the system usable without the team.