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.

1. © 2014 ripplerock
Reducing the Release Cycle Time
when Scaling Agile
Colin Bird
colin.bird@ripple-rock.com

2. © 2014 ripplerock
What is Scaled Agile?
• Organisational Agile adoption
• Many teams working on the same
product/programme?
• Distributed teams and/or business

3. © 2014 ripplerock
ScalingStrategies& Principles

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. © 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. © 2014 ripplerock
IdentifyingWaste in the Release Cycle

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. © 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. © 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. © 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. © 2014 ripplerock
RemovingWaste in the Release Cycle

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. © 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. © 2014 ripplerock
Continuous Integration?
Integrate
!!!

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. © 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. © 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. © 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. © 2014 ripplerock
Changing the Emphasis of Testing Effort
Exploratory
Testing
Scripted
Testing
Automated
Testing
Exploratory
Testing
Scripted
Testing
Automated
Testing
From
To

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. © 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. © 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. © 2014 ripplerock
Scrum of Scrums
Authority
1 – 3
times/week
Decisions
Retain Autonomy in
the teams

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. © 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. © 2014 ripplerock
Questionsand possibly, answers