Colin Birds talk at ITV

1. Scaling Agile
Colin Bird
colin.bird@ripple-rock.com
© 2014 ripplerock

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

3. There are a number of competing Scaling Approaches…
© 2014 ripplerock

4. SAFe from Dean Leffingwell
Scaled Agile Framework™ Big Picture

5. DAD – Disciplined Agile Delivery

6. LeSS – A Principle & Pattern Approach

7. One Size Doesn’t Fit All
Context Matters
• Type of Problem/Product/System
• Organisation Culture
• Size: Organisation/Group/Programme
• Agile Maturity
• Geography
• Constraints
© 2014 ripplerock

8. Some Patterns to think about…
© 2014 ripplerock

9. Agile Portfolio Management
Programme 2
Programme 3
High Value
Low Effort
Programme 1
WIP Limit
Low Value
High Effort
Minimal
Marketable
Features
(MMFs)
Team A
Backlogs
© 2013 ripplerock
Team B
Team C
Team D
Team E
Programme 4

10. Agile Portfolio Management - Principles
• Maximise value of software development investment
– Increase ROI
• Reduce project size – release sooner and more often
• Reduce waste
– Reduce WIP Work In Progress
– Only build most valuable software
• Provide visibility
– Support decision making
© 2014 ripplerock

11. Component versus Feature Teams
Customer
Backlog
Component
Team
Solution Layer
Component
Team
11
Feature Team
Solution Layer
© 2014 ripplerock
Component
Team
Feature Team
Solution Layer
Feature Team
Customer
Backlog
Component
Component
Component
Backlog(s)
Backlog(s)
Backlog(s)

12. Start Small
Initial deliverables
• Architecture
• Development/test environments
• Standards
• Interfaces
• Some tangible piece of business value
© 2014 ripplerock
12

13. Share start and end dates
• Don’t stagger Sprints like this:
Team 1
Team 1
Team 2
Team 2
Team 3
Team 3
• Synchronise Sprint starts instead
Team 1
Team 2
Team 3
Start
© 2014 ripplerock
Team 2
Team 3
Finish Start
13
Finish

14. Scrum Meetings
• Stagger daily stand-up meetings to allow
cross-team attendance
15 Mins
15 Mins
15 Mins
Team 1
Team 2
Team 3
© 2014 ripplerock
14

15. Scrum of Scrums
Scrum of Scrums of Scrums
Scrum of Scrums
Daily
Scrums
© 2014 ripplerock
15

16. Scaling the Product Owner
Programme Product
Owner
Product Line/Stream
Owners
Product
Owners
© 2014 ripplerock
16

17. Communities of Practice
• Augment the multi-team
structure with orthogonal,
virtual teams
• Informal or semi-formal
• Meet periodically
• Discuss and resolve issues
related to their specialty
– May want to work off
their own community
backlog
© 2014 ripplerock
17

18. Spotify
• Squad
– Equivalent to a Scrum team
– Autonomous as possible
• Tribes
– Same office < 100 people
– Common area of the system
– Organised for minimum
interdependency
• Chapter
– Skills community
– Chapter Lead is line manager
• Guilds
– Community of interest
– Cross Tribe group
– Guild Unconferences
Source: Henrik Kniberg & Anders Ivarsson Oct 2012

19. More Patterns
• Minimise cross-timezone communication
– Match team structure to geography
• Internal Open(ish) Source – for common services/components
• Enable cross-pollination
– Chief Architect on walkabout
– Communities
– Allow gradual team member cycle
• Improvement Ideas Board
– “Definition of Awesome”
© 2013 ripplerock

20. Scaling Strategies & Principles
© 2014 ripplerock

21. 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, etc…
© 2013 ripplerock

22. Scaling Strategies 2/2
• Continuous Delivery – Work towards a friction free path to live
• Decouple architecture as much as possible to maximise autonomy
• 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!
© 2013 ripplerock

23. Scale Principles
• Favour Autonomy over Consistency
– Team processes do not have to be 100% consistent
– Autonomy doesn't necessarily lead to lack of alignment
•
•
•
•
Favour Trust over Control
Monitor Value & Impact rather than Velocity
Make Failure Recovery more important than Failure Avoidance
Value Innovation over Predictability
– 100% Predictability = 0% Innovation
• Use Experiments & Data rather than Arguments & Opinion
• Focus on Community rather than Structure
Adapted from: Henrik Kniberg Culture over Process SG Paris 2013
© 2013 ripplerock

24. Scaling Agile Summary
• Use a Principles led approach to try appropriate scaling
patterns
– Adapt and combine as necessary
– Continuously evolve – Inspect and Adapt!
– Stay Agile & Lean
© 2013 ripplerock