Timeboxed releases - Peter Antman


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Timeboxed releases - Peter Antman

  1. 1. [email_address]
  2. 2. Polopoly – Enterprise Web CMS
  3. 3. Agile Axioms <ul><li>“ Timebox, don't scope box” </li></ul><ul><li>“ Runnable increment at end of sprint” </li></ul><ul><li>“ Release early, release often” </li></ul><ul><li>No discussion of why they are good axioms </li></ul><ul><li>But: what effects do they have on a software product company </li></ul>
  4. 4. Time Boxed Releases 2 weeks A quarter DP1 Major DP5 DP4 DP3 Minor DP2 A month
  5. 5. A changed way of working <ul><li>How did we get here? </li></ul><ul><ul><li>Get Scrum basic running (plan and adapt) </li></ul></ul><ul><ul><li>Handle support caos (kanban team) </li></ul></ul><ul><li>Then we had to change/adapt almost every process </li></ul><ul><ul><li>What is a feature? </li></ul></ul><ul><ul><li>When is it done? </li></ul></ul><ul><ul><li>How is it tested? </li></ul></ul>
  6. 6. First Step: Learn How to Plan (Lean) <ul><li>Learn PO to formulate the smallest possible stories that gives bussines value (Least Marketable Feature) max 5 sp </li></ul><ul><li>Find a sprint length where team continously succeed in finnishing what it commited on (1 week) </li></ul><ul><li>Meassure stories in size (complexity/story points) </li></ul><ul><li>Meassure the velocity over time </li></ul><ul><li>Let the teams be stable </li></ul><ul><li>Learn to formulate super stories and roughly esitmate them (15 – 20 sp) </li></ul><ul><li>Select super stories from a theme </li></ul><ul><li>Plan a “release sprint” with a number of deliver sprint (12) </li></ul>
  7. 7. Avoid Peripetia
  8. 8. Burn Down Release Plan
  9. 9. Second Step: Organize Delivery <ul><li>Keep focus </li></ul><ul><li>Don't step on each others toes </li></ul><ul><li>Plan for maintenance </li></ul><ul><li>Prepare next release sprint in advance </li></ul>
  10. 10. Our Current Delivery Organization <ul><li>One major team delivers next major </li></ul><ul><li>One minor team delivers updates (minors) to last major </li></ul><ul><li>One team maintain all previously delivered majors and do reasearch for next major </li></ul><ul><li>Physical team switch every quarter </li></ul><ul><li>A team is responsible for a major for 36 weeks </li></ul>
  11. 11. Third Step: Automate Everything <ul><li>Everything must be tracable through the IT-infrastructure </li></ul><ul><li>A ticket for every story </li></ul><ul><li>All changesets on storys autmatically </li></ul><ul><li>All releasenotes and upgrade info on tickets </li></ul><ul><li>Documentation generated for each branch on the fly </li></ul><ul><li>Releases build every night </li></ul><ul><li>Build releases are feature complete (including version numbering) </li></ul>
  12. 12. Follow the Trace
  13. 13. Fourth Step: Test EVRYTHING <ul><li>Test code locally </li></ul><ul><li>Test integration continously </li></ul><ul><li>Test all supported plattform every night </li></ul><ul><li>Test documentation </li></ul><ul><li>Test that all code on a branch have a ticket and is documented </li></ul><ul><li>Test that all tickets for a branch have code on that branch </li></ul>
  14. 14. Stop the Line When Test Fails
  15. 15. Test Infrastructure
  16. 16. Fifth Step: Always be Integrated <ul><li>No junk on trunk = throw away trunk </li></ul><ul><li>Releases are done from release branches </li></ul><ul><li>New release branches are always taken from current release branch </li></ul><ul><li>Teams have their own work branches (svn or git) </li></ul><ul><li>Only finnished stories are merged to a release branch </li></ul>
  17. 17. <ul><li>Always releaseble! </li></ul>
  18. 18. Unresolved Issues <ul><li>To much expectations on a release sprint (make them shorter) </li></ul><ul><li>Lots of releases to maintain (make frozen ones) </li></ul><ul><li>Merge hell (use git) </li></ul>
  19. 19. END