timeboxed releases - peter antman

19
atex.com 1 timeboxed.releases@polopoly

Upload: manssandstrom

Post on 02-Jul-2015

354 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Timeboxed releases - Peter Antman

atex.com1

timeboxed.releases@polopoly

Page 2: Timeboxed releases - Peter Antman

atex.com

Polopoly – Enterprise Web CMS

Page 3: Timeboxed releases - Peter Antman

atex.com

Agile Axioms

“Timebox, don't scope box” “Runnable increment at end of sprint” “Release early, release often”

No discussion of why they are good axioms But: what effects do they have on a software

product company

Page 4: Timeboxed releases - Peter Antman

atex.com

Time Boxed Releases

2 weeks A quarter

DP1

Major

DP5

DP4

DP3

Minor

DP2

A month

Page 5: Timeboxed releases - Peter Antman

atex.com

A changed way of working

How did we get here? Get Scrum basic running (plan and adapt) Handle support caos (kanban team)

Then we had to change/adapt almost every process What is a feature? When is it done? How is it tested?

Page 6: Timeboxed releases - Peter Antman

atex.com

First Step: Learn How to Plan (Lean)

Learn PO to formulate the smallest possible stories that gives bussines value (Least Marketable Feature) max 5 sp

Find a sprint length where team continously succeed in finnishing what it commited on (1 week)

Meassure stories in size (complexity/story points) Meassure the velocity over time Let the teams be stable Learn to formulate super stories and roughly esitmate them (15 – 20

sp) Select super stories from a theme Plan a “release sprint” with a number of deliver sprint (12)

Page 7: Timeboxed releases - Peter Antman

atex.com

Avoid Peripetia

Page 8: Timeboxed releases - Peter Antman

atex.com

Burn Down Release Plan

Page 9: Timeboxed releases - Peter Antman

atex.com

Second Step: Organize Delivery

Keep focus Don't step on each others toes Plan for maintenance Prepare next release sprint in advance

Page 10: Timeboxed releases - Peter Antman

atex.com

Our Current Delivery Organization

One major team delivers next major One minor team delivers updates (minors) to last major One team maintain all previously delivered majors and

do reasearch for next major Physical team switch every quarter A team is responsible for a major for 36 weeks

Page 11: Timeboxed releases - Peter Antman

atex.com

Third Step: Automate Everything

Everything must be tracable through the IT-infrastructure A ticket for every story All changesets on storys autmatically All releasenotes and upgrade info on tickets Documentation generated for each branch on the fly Releases build every night Build releases are feature complete (including version

numbering)

Page 12: Timeboxed releases - Peter Antman

atex.com

Follow the Trace

Page 13: Timeboxed releases - Peter Antman

atex.com

Fourth Step: Test EVRYTHING

Test code locally Test integration continously Test all supported plattform every night Test documentation Test that all code on a branch have a ticket and is

documented Test that all tickets for a branch have code on that

branch

Page 14: Timeboxed releases - Peter Antman

atex.com

Stop the Line When Test Fails

Page 15: Timeboxed releases - Peter Antman

atex.com

Test Infrastructure

Page 16: Timeboxed releases - Peter Antman

atex.com

Fifth Step: Always be Integrated

No junk on trunk = throw away trunk Releases are done from release branches New release branches are always taken from current

release branch Teams have their own work branches (svn or git) Only finnished stories are merged to a release branch

Page 17: Timeboxed releases - Peter Antman

atex.com

Always releaseble!

Page 18: Timeboxed releases - Peter Antman

atex.com

Unresolved Issues

To much expectations on a release sprint (make them shorter)

Lots of releases to maintain (make frozen ones) Merge hell (use git)

Page 19: Timeboxed releases - Peter Antman

atex.com

END