Difference between revisions of "Release strategies"
Jump to navigation
Jump to search
(monthly or adopting a {{p|season beat}}) |
({{p|golden triangle}}) |
||
Line 1: | Line 1: | ||
The {{p|golden triangle}} explains the basic mechanism for releasing early and often. In what follows, it is assumed that the ‘resources’ (people & materials) remain constant and quality must comply to a minimum level. | |||
If either time (deadline) or scope is unachievable, consider to: | If either time (deadline) or scope is unachievable, consider to: |
Latest revision as of 07:30, 4 April 2013
The golden triangle explains the basic mechanism for releasing early and often. In what follows, it is assumed that the ‘resources’ (people & materials) remain constant and quality must comply to a minimum level.
If either time (deadline) or scope is unachievable, consider to:
- slow down to speed up—teams that finish early accelerate faster, kaizen;
- offload some of the work to external parties;
- scale up human capacity.
Three primary release strategies:
- Custom-Planned Releases—scope is function of time
- release date estimated from initial feature set and velocity;
- snapshot delivery of whatever is ready by the date;
- scope changes require trade-offs if date remains fixed, consider money for nothing, change for free;
- Fixed Release Cadence—scope is function of time
- delivery on a fixed cadence, e.g. monthly or adopting a season beat;
- snapshot delivery whatever is ready by the date;
- feature set frozen on latest responsible moment (driven by feature set risk profile)
- Multi-Team Releases—time is function of scope;
- epic feature sets split over multiple squads;
- dependencies tagged visually;
- regular joint reviews, e.g. scrum of scrums;
- delivery when a feature set’s components are ready for release.