© 2014 ripplerock
Reducing the Release Cycle Time
when Scaling Agile
Colin Bird
colin.bird@ripple-rock.com
© 2014 ripplerock
What is Scaled Agile?
• Organisational Agile adoption
• Many teams working on the same
product/programme...
© 2014 ripplerock
ScalingStrategies& Principles
© 2014 ripplerock
Scaling Strategies 1/2
• Organisational Change must be part of the scaling process
• Keep it Lean – syst...
© 2014 ripplerock
Scaling Strategies 2/2
• Continuous Delivery – Work towards a friction free path to live
• Decouple arch...
© 2014 ripplerock
IdentifyingWaste in the Release Cycle
© 2014 ripplerock
Lean: Reduce Waste & Lead Time
Lead Time
Define Engineer Deploy
Productive
Unproductive
CUSTOMERCONCEPT
...
© 2014 ripplerock
Types of waste
• Requirements specified and analysed but never delivered
• Sign-offs: budgetary, require...
© 2014 ripplerock
Types of waste
• Governance
– Technical
– Project management
– Sign-offs
– Reporting overhead
• Team(s)
...
© 2014 ripplerock
Types of waste
• Wasteful and toothless de-risking processes
– Interim documentation creation
– Meaningl...
© 2014 ripplerock
RemovingWaste in the Release Cycle
© 2014 ripplerock
Agile Portfolio Management
Programme
WIP Limit
Programme Area 1 Programme Area 2 Programme Area 3 Progra...
© 2014 ripplerock
Run the Portfolio with Kanban
• Restrict WIP
• It’s a Pull System
• Just enough preparation detail
• Tra...
© 2014 ripplerock
Continuous Integration?
Integrate
!!!
© 2014 ripplerock
CombinedSprint
Review
Build core infrastructure initially
Initial Deliverables
• Executable Architecture...
© 2014 ripplerock
Share start and end dates
Team 1 Team 1
Team 2Team 2
Team 3 Team 3
• Don’t stagger Sprints like this:
• ...
© 2014 ripplerock
Component versus Feature Team Model
Solution Layer
Solution Layer
Solution Layer
Customer
Backlog
Compon...
© 2014 ripplerock
ALM “Component” Team Supporting Feature Teams
Solution Layer
Solution Layer
Solution Layer
Customer
Back...
© 2014 ripplerock
Changing the Emphasis of Testing Effort
Exploratory
Testing
Scripted
Testing
Automated
Testing
Explorato...
© 2014 ripplerock
Automated Testing Coverage
Automated
UI Testing
Automated
API Testing
Automated
Unit Testing
QA assisted...
© 2014 ripplerock
Environments: Relative QA Value Add
0
1
2
3
4
5
6
7
8
9
10
Dev PC Dev Test INT OPS Live
Environments: Re...
© 2014 ripplerock
Develop-Deploy-Test Feedback Cycle
Gated CI Build +
Packaging
Integration Deployment
Staging/Preproducti...
© 2014 ripplerock
Scrum of Scrums
Authority
1 – 3
times/week
Decisions
Retain Autonomy in
the teams
© 2014 ripplerock
More Thoughts
• Minimise cross-timezone communication
– Match team structure to geography
• Internal Ope...
© 2014 ripplerock
Reducing Cycle Time at Scale: Summary
• Apply Systems Thinking
• Measure the entire Lead Time
• Measure ...
© 2014 ripplerock
Questionsand possibly, answers
Upcoming SlideShare
Loading in …5
×

Reducing Release Cycle Times with Scaled Agile

937 views

Published on

A presentation by Colin Bird of RippleRock given at the Agile Practitioners Group 26/3/14.

We look at some of the common wastes we find in the software delivery lifecycle, particularly as the programme size increases. These wastes contribute to a long Lead time for delivery to the customer. We then explore approaches to reducing or avoiding these wasteful areas.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
937
On SlideShare
0
From Embeds
0
Number of Embeds
158
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Reducing Release Cycle Times with Scaled Agile

  1. 1. © 2014 ripplerock Reducing the Release Cycle Time when Scaling Agile Colin Bird colin.bird@ripple-rock.com
  2. 2. © 2014 ripplerock What is Scaled Agile? • Organisational Agile adoption • Many teams working on the same product/programme? • Distributed teams and/or business
  3. 3. © 2014 ripplerock ScalingStrategies& Principles
  4. 4. © 2014 ripplerock Scaling Strategies 1/2 • Organisational Change must be part of the scaling process • Keep it Lean – systematically remove waste – Just enough Process – monitor meeting time to working time ratio – Just enough Roles – monitor % of people managing/guiding process – Remove bureaucracy • Monitor and Reduce Cycle time of the system – How long it takes a requirement to pass through the system – Enable fast feedback cycles – all the way through the system • Optimise the working environment for intra and inter team collaboration – Co-locate teams within geographical boundaries – Meeting areas, whiteboards, dev & test tooling, process support, etc…
  5. 5. © 2014 ripplerock Scaling Strategies 2/2 • Continuous Delivery – Work towards a friction free path to live • Decouple architecture as much as possible to maximise team autonomy and “Deployability” • Always be close to a working, integrated product – Demo integrated working system frequently • Make language your own – Spotify Guilds, Tribes, Squads, etc. work because they came up with the terminology • Continually evolve the process, organisation, structures, tools, etc. – If its perfect now – it won’t be in 6 months!
  6. 6. © 2014 ripplerock IdentifyingWaste in the Release Cycle
  7. 7. © 2014 ripplerock Lean: Reduce Waste & Lead Time Lead Time Define Engineer Deploy Productive Unproductive CUSTOMERCONCEPT Lead Time Define Engineer Deploy Productive Unproductive CONCEPT CUSTOMER Minimise Waste  Defects  Delays  Extra features  Handoffs  Partially done work  Relearning  Task switching
  8. 8. © 2014 ripplerock Types of waste • Requirements specified and analysed but never delivered • Sign-offs: budgetary, requirements, design – Waiting for the next sign-off review meeting • Interim documentation creation – Paper de-risking exercises – Information loss when translated to documents • Cost and decay of analysis & design value over time – Detail requirement specification – Up front design: architecture, UX – Hi fidelity wireframes • Costly Proof of Concepts • Detailed estimation exercises Define Engineer Deploy
  9. 9. © 2014 ripplerock Types of waste • Governance – Technical – Project management – Sign-offs – Reporting overhead • Team(s) – Resourcing & assembly – Specialist resource contention – Task switching • Requirements – Descoped after detailed elaboration and estimation • Communication challenges – Distributed business and/or team members • Integration failure • Environments – Provisioning lead times – Availability contention – Not Live like • Manual Packaging & Deployment – Time sapping – Error prone • Manual Regression Testing • Manual Test Scripts • Defects Define Engineer Deploy
  10. 10. © 2014 ripplerock Types of waste • Wasteful and toothless de-risking processes – Interim documentation creation – Meaningless signoffs • Environments – Infrastructure lead times – Availability – Consistency & quality – Not Live like • Manual processes – Packaging & Deployment – Testing • Load & Performance issues • Handoff to another group for production deployment • Compliance failures • Functional Defects • Security flaws Define Engineer Deploy
  11. 11. © 2014 ripplerock RemovingWaste in the Release Cycle
  12. 12. © 2014 ripplerock Agile Portfolio Management Programme WIP Limit Programme Area 1 Programme Area 2 Programme Area 3 Programme Area 4 Minimal Marketable Features (MMFs) Team A Team B Team C Team D Team E LowValueHighValue HighEffortLowEffort Backlogs Cross-functional Teams
  13. 13. © 2014 ripplerock Run the Portfolio with Kanban • Restrict WIP • It’s a Pull System • Just enough preparation detail • Track Cycle and Lead Time • Systematically reduce waste and overall Lead Time – Budgeting Cycles – Sign-offs, gates and wasteful artefacts – Precise estimation (attempts)
  14. 14. © 2014 ripplerock Continuous Integration? Integrate !!!
  15. 15. © 2014 ripplerock CombinedSprint Review Build core infrastructure initially Initial Deliverables • Executable Architecture • Development/test environments • Version Control, Build, Test & Deploy • Standards • Some tangible piece of business value
  16. 16. © 2014 ripplerock Share start and end dates Team 1 Team 1 Team 2Team 2 Team 3 Team 3 • Don’t stagger Sprints like this: • Synchronise Sprint starts instead: Team 2Team 2 Team 3 Team 3 FinishFinish StartStart Team 1
  17. 17. © 2014 ripplerock Component versus Feature Team Model Solution Layer Solution Layer Solution Layer Customer Backlog Component Team FeatureTeam Component Team Component Team FeatureTeam FeatureTeam Customer Backlog Component Backlog(s) Component Backlog(s) Component Backlog(s)
  18. 18. © 2014 ripplerock ALM “Component” Team Supporting Feature Teams Solution Layer Solution Layer Solution Layer Customer Backlog ALM Platform Team FeatureTeam FeatureTeam FeatureTeam Evolving the Continuous Delivery Platform Not Performing deployment operations for teams!
  19. 19. © 2014 ripplerock Changing the Emphasis of Testing Effort Exploratory Testing Scripted Testing Automated Testing Exploratory Testing Scripted Testing Automated Testing From To
  20. 20. © 2014 ripplerock Automated Testing Coverage Automated UI Testing Automated API Testing Automated Unit Testing QA assisted by Dev QA and Dev Dev assisted by QA Quality:WholeTeamResponsibility Adapted from Mike Cohn’s Automated Testing Pyramid
  21. 21. © 2014 ripplerock Environments: Relative QA Value Add 0 1 2 3 4 5 6 7 8 9 10 Dev PC Dev Test INT OPS Live Environments: Relative Assurance Level Dev Team Control Ops Team Control
  22. 22. © 2014 ripplerock Develop-Deploy-Test Feedback Cycle Gated CI Build + Packaging Integration Deployment Staging/Preproduction Deployment Production Deployment Manytimes/day Multipletimes/day Dev Deploy Multipletimes/day QA Deployment QA“Pull”asrequired>once/day Atleastonce/Release Multipletimes/Sprint Multipletimes/Release Local Dev Build/Test
  23. 23. © 2014 ripplerock Scrum of Scrums Authority 1 – 3 times/week Decisions Retain Autonomy in the teams
  24. 24. © 2014 ripplerock More Thoughts • Minimise cross-timezone communication – Match team structure to geography • Internal Open(ish) Source – for common services/components • Enable cross-pollination versus dictating architectural design – Chief Architect on walkabout – Communities – Allow gradual team member cycle • Improvement Ideas Board – “Definition of Awesome”
  25. 25. © 2014 ripplerock Reducing Cycle Time at Scale: Summary • Apply Systems Thinking • Measure the entire Lead Time • Measure the Cycle Time of the key elements • Identify and remove anything that doesn’t justify enough Value versus its effort/time cost • Maximise team Autonomy and Empowerment • Stay as close as possible to an Integrated Working System • Invest in your Continuous Delivery Platform • Embrace Automation
  26. 26. © 2014 ripplerock Questionsand possibly, answers

×