Think Outside the
(Time) Box
Transitioning from Timeboxes
to Continuous Product Delivery
Intro
Stephen Younge works here Steve Stolt works here
“Continuous Product
Delivery?”
Feature Inventory
Continuous delivery? Easy!
Just change everything.
(Well, maybe it isn’t that easy)
Tuesday, August 6 • 3:45pm - 5:00pm • ...
Learning Objectives
After today's session, you'll be able to:
● decide if continuous product delivery is right
for your te...
About you
● Kanban or Scrum?
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
Starting Point
May 2010
In business 9+ years
Agile and Scrum from day 1
2 Scrum teams
2 week sprints
8 week releases
Stakeholders
● Published roadmap
● Release planning every 8
weeks
● Publish major features
● Everyone plans to those dates...
Roadmap
Q1 Q2 Q3 Q4
Initiative
Feature
Initiative
Feature
Initiative
Feature
Initiative
Feature
InitiativeFeature
Initiati...
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
Timeboxes - good and bad
● Stakeholder expectations
● Feature finished week 2
● Feature "close" week 7-8
● Feature isn't i...
Intellectual curiosity
● Intellectual curiosity around kanban and Lean
● Value Stream Mapping
● A3
● Donald Reinertsen
● D...
Agreement
Continuous deployment for engineering
Continuous flow for the business (in-part kanban)
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
We love change - we move fast
Canceled meetings
Training on kanban and lean
Set up kanban boards
This felt great.............
Tooling Changes
Tooling Changes
Delivery team process
Kanban
● manage work in process (WIP) limits
● track story/defect throughput
Moving away from dates...
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
Role confusion
Scrum Masters?
Product Owners?
Lost Routines
Iteration Planning
Release Planning
Retros
Estimation
Still needed?
Do we still need to estimate stories?
Do we need to estimate tasks?
Interruptions
No timebox
It is always a good time
How about now?
Stakeholders
“Where are our dates?”
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
Role Changes
Scrum Masters - Full-time Coaches
Removal of roadblocks - Product Owners
New team routines
Weekly time booked
● replenish ready queue - if needed
● plan upcoming work - if needed
● retrospectives...
Delivery team features
Features
● planned end dates
● check-ins
Feature toggles
Are awesome!
Give you control
● staged rollouts
● A/B testing
● rollback
● market release
● incremental fe...
Feature kanban
● transparency
● self-serve
Feature-level Status Reporting
How to Align ‘Above’ Features?
Objectives
Check-ins with Stakeholders
Are we on track?
Do we need to make adjustments?
Objectives - delivery team
Objectives
● co-authored by the product and delivery team
● a guidepost for the delivery team
●...
Objectives - A few walls help
Alignment between Stakeholders and Team
Stakeholders
Team
ObjectivesFeatures
Initiatives Business Goals
Shield
and
Check-i...
Roadmap
Previous
Quarter
Feature
Initiative
Feature
Initiative
Feature
Feature
Initiative
Feature
Initiative
Initiative
In...
Everybody Bought In
Team
● more efficient and
responsive with
continuous delivery
● focus on WIP and
cycle time
Stakeholde...
Our New Reality
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
Engineering efficiency
Small, frequent releases
Less to debug, if needed - good
Not free - bad
No More Branches
No More Patches
The last 5%
If we need another week we can get it
Requires discipline
Delivery Teams
prefer continuous delivery
(at least ours seem to)
Rapid Response for new features
We plan to have space to respond
Smaller releases = smaller feedback (focused)
Less to res...
We have come far...
... but we’re not done
Agenda
● Where we started from
● Why we changed
● What we changed
● Challenges
● Inspect and Adapt
● Advantages
● Q&A
QUESTIONS?
Stephen Younge
syounge@rallydev.com
@stephen_younge
Steve Stolt
sstolt@rallydev.com
@stevestolt
or stop by our ...
end
Transitioning from Timeboxes to Continuous Product Delivery (by Steve Stolt and Steven Younge)
Transitioning from Timeboxes to Continuous Product Delivery (by Steve Stolt and Steven Younge)
Upcoming SlideShare
Loading in …5
×

Transitioning from Timeboxes to Continuous Product Delivery (by Steve Stolt and Steven Younge)

1,478 views

Published on

Agile continuous flow (Kanban) methods aren’t only for Operations and Support anymore -- Product Development teams now use them for strategic, date-sensitive initiatives to achieve faster time to market. Proceed with caution! Simply throwing away timeboxes can be dangerous.

We took the journey from a timeboxed to a continuous flow software delivery model. We brought along a large tribe of developers, testers, product owners, dev-ops people, UX designers, and stakeholders. We got lost a few times on the way, but we did find our destination.

Published in: Business, Technology

Transitioning from Timeboxes to Continuous Product Delivery (by Steve Stolt and Steven Younge)

  1. 1. Think Outside the (Time) Box Transitioning from Timeboxes to Continuous Product Delivery
  2. 2. Intro Stephen Younge works here Steve Stolt works here
  3. 3. “Continuous Product Delivery?”
  4. 4. Feature Inventory
  5. 5. Continuous delivery? Easy! Just change everything. (Well, maybe it isn’t that easy) Tuesday, August 6 • 3:45pm - 5:00pm • Canal B Steve Stolt and Steve Neely
  6. 6. Learning Objectives After today's session, you'll be able to: ● decide if continuous product delivery is right for your team ● create a transition plan based on our learnings ● deal with the reality of dates ● apply kanban principles to higher levels of planning and tracking ● engage with stakeholders during the journey
  7. 7. About you ● Kanban or Scrum?
  8. 8. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  9. 9. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  10. 10. Starting Point May 2010 In business 9+ years Agile and Scrum from day 1 2 Scrum teams 2 week sprints 8 week releases
  11. 11. Stakeholders ● Published roadmap ● Release planning every 8 weeks ● Publish major features ● Everyone plans to those dates ● Monthly product council meeting
  12. 12. Roadmap Q1 Q2 Q3 Q4 Initiative Feature Initiative Feature Initiative Feature Initiative Feature InitiativeFeature Initiative Feature Initiative Feature Initiative Feature Feature Feature RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE
  13. 13. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  14. 14. Timeboxes - good and bad ● Stakeholder expectations ● Feature finished week 2 ● Feature "close" week 7-8 ● Feature isn't included in a release
  15. 15. Intellectual curiosity ● Intellectual curiosity around kanban and Lean ● Value Stream Mapping ● A3 ● Donald Reinertsen ● Desire to inspect and adapt
  16. 16. Agreement Continuous deployment for engineering Continuous flow for the business (in-part kanban)
  17. 17. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  18. 18. We love change - we move fast Canceled meetings Training on kanban and lean Set up kanban boards This felt great.............................AT FIRST!
  19. 19. Tooling Changes
  20. 20. Tooling Changes
  21. 21. Delivery team process Kanban ● manage work in process (WIP) limits ● track story/defect throughput
  22. 22. Moving away from dates...
  23. 23. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  24. 24. Role confusion Scrum Masters? Product Owners?
  25. 25. Lost Routines Iteration Planning Release Planning Retros
  26. 26. Estimation Still needed? Do we still need to estimate stories? Do we need to estimate tasks?
  27. 27. Interruptions No timebox It is always a good time How about now?
  28. 28. Stakeholders “Where are our dates?”
  29. 29. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  30. 30. Role Changes Scrum Masters - Full-time Coaches Removal of roadblocks - Product Owners
  31. 31. New team routines Weekly time booked ● replenish ready queue - if needed ● plan upcoming work - if needed ● retrospectives - always
  32. 32. Delivery team features Features ● planned end dates ● check-ins
  33. 33. Feature toggles Are awesome! Give you control ● staged rollouts ● A/B testing ● rollback ● market release ● incremental feedback!
  34. 34. Feature kanban ● transparency ● self-serve
  35. 35. Feature-level Status Reporting
  36. 36. How to Align ‘Above’ Features?
  37. 37. Objectives
  38. 38. Check-ins with Stakeholders Are we on track? Do we need to make adjustments?
  39. 39. Objectives - delivery team Objectives ● co-authored by the product and delivery team ● a guidepost for the delivery team ● delivery team - stakeholder alignment
  40. 40. Objectives - A few walls help
  41. 41. Alignment between Stakeholders and Team Stakeholders Team ObjectivesFeatures Initiatives Business Goals Shield and Check-ins Stories and Defects
  42. 42. Roadmap Previous Quarter Feature Initiative Feature Initiative Feature Feature Initiative Feature Initiative Initiative Initiative Feature Feature Feature Recently Delivered Current Quarter Next Quarter Beyond FEATURES In Progress Prep Ideas
  43. 43. Everybody Bought In Team ● more efficient and responsive with continuous delivery ● focus on WIP and cycle time Stakeholders ● features out faster ● transparency ● engaged Alignment on a single set of business objectives and medium grained features
  44. 44. Our New Reality
  45. 45. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  46. 46. Engineering efficiency
  47. 47. Small, frequent releases Less to debug, if needed - good Not free - bad
  48. 48. No More Branches
  49. 49. No More Patches
  50. 50. The last 5% If we need another week we can get it Requires discipline
  51. 51. Delivery Teams prefer continuous delivery (at least ours seem to)
  52. 52. Rapid Response for new features We plan to have space to respond Smaller releases = smaller feedback (focused) Less to respond to - if needed ASAP
  53. 53. We have come far... ... but we’re not done
  54. 54. Agenda ● Where we started from ● Why we changed ● What we changed ● Challenges ● Inspect and Adapt ● Advantages ● Q&A
  55. 55. QUESTIONS? Stephen Younge syounge@rallydev.com @stephen_younge Steve Stolt sstolt@rallydev.com @stevestolt or stop by our booth or our reception on Tuesday at 7p
  56. 56. end

×