Managing Risk
- Scrum is all about risk management
- RISK: (Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility
- The best way to reduce risk in general is: to build potentially releasable increments for users
- Financial Risk - Can we pay for it? / Are we building the right product?
- Control Risk: by building empirically
- The sooner the (first) release goes out, the sooner the financial risk decreases
- Product Owner: control of the budget and planning of the product
- Developers: cross-functional professionals who can get the job done, start to finish
- Scrum Master: facilitate this Scrum Team to encourage empirical process control and coach this team to be a little bit better every day
- By asking the team how long it takes to validate the first wishes into a concrete result
- Business Risk - Will it be used? Does it solve the problem? / Are we delivering value?
- Risk of people (users) actually not using your product, thus not solving the problem that the product needed to fix in the first place
- And not because our teams are dumb or stubborn, but mostly because a customer really knows what he needs the moment he can actually use the product. Everything before that is useful but does not take away the risk of people not actually using your product
- Control Risk:
- Product Owner: keep in close contact with stakeholders and Developers, to build the right thing
- Reviewing the releasable increment with stakeholders every Sprint and pivoting or persevering from there
- Technical Risk - Can it be made/built? (With the proper cost) /Are we creating it at a good cost?
- Can it be built with a good ROI?
- Can we maintain the product during and afterward?
- The Development Teams need to be accountable for the quality of the product and how it's made. That's a risk right there!
- Control Risk:
- Communication is key for: the effort that is put into a feature is worth the value?
- Scout Rule for: being able to maintain the product?
- DoD & adhering to it: enhance the quality & maintainability of the overall product
- Using a "Technical Debt Register" in Scrum
- Managing Technical Risk - Defer Constraining Commitments
- Chuck discusses some ideas on how to make decisions on prioritization, especially as they impact architecture and design
- His focus is on
- how decisions can be made now or postponed for later when you have more information
- how with smaller experiments you can gather information to help make the right decisions downstream
- defer a constraining commitment until the last responsible moment: postpone architectural decisions