Real-life Agile Scaling Consultant www.crisp.se
Keynote - Agile Tour Bangkok Nov 21, 2015
Henrik Kniberg
Parent
[email protected] @HenrikKniberg
Agile & Lean coach Author
Not too hard
Henrik Kniberg
A bit trickier
Henrik Kniberg
Hard!
Henrik Kniberg
How do we avoid THIS?
Henrik Kniberg
Beware of Scaling
Henrik Kniberg
01:32
Beware of Scaling
?
! Guaranteed Downside • Cost • Complexity Henrik Kniberg
?
Potential Upside: • Shorter delivery time more hands on deck, parallell work • Better product access to wider range of competences Potential Downside (Risk): • Longer delivery time because of misalignment & dependencies • Worse product because of bad communication
Stuff you need to figure out with multiple teams How to slice the elephant
Team structure
Henrik Kniberg
Team sync / alignment
Feedback loop
Dependencies!
Slice the elephant
Henrik Kniberg
01:32
Big Bang = Big Risk
10% succeed 38% totally fail1
Source: Chaos Manifesto 2013, Standish group
Cumulative RISK Value Henrik Kniberg
≈250 people involved 4 years to first public release Shut down after 2 years of operation
Henrik Kniberg
Lego Universe
Not like this....
1
2
3
4
Like this!
1 Henrik Kniberg
2
3
4
5
Slice the elephant!
Region Östergötland, Uppsala, etc
1.0 Crime types (weapon, drunk driving, shoplifting, etc)
1.1
1.3
1.4
1.2 1.5
Integrations
Henrik Kniberg
MVP – Minimum Viable Product
Henrik Kniberg
Minimum viable
Earliest Testable Product
Earliest Usable Product
Earliest testable/usable/lovable Earliest Lovable Product
Aim for the Clouds... But deliver in Small Steps
Henrik Kniberg
Two types of slicing Release 1.0
Slicing to enable early & frequent release Release 1.1
Release 1.2
Release 1.3
Slicing to enable parallel development
Henrik Kniberg
Build a suitable Team Structure
01:32
Component team vs Feature team
User Client
Client team C
C
S
D
Feature team 1
S C S
D
Test team T
Henrik Kniberg
T
S
S
D
D
D
T T
T
Feature team 2 C
C
DB team D
DB
C
Server team S
Server
T Communities of interest
Two conflicting goals (at scale): 1. Team should be “full-stack” 2. Team should be small Security
Performance Front end
Marketing
DB Test
Hardware
UX
Monitoring Back end Data analytics Operations
Henrik Kniberg
Build systems
Design
Big Data
Team types - finding the right balance
100% feature teams
Small orgs
Large orgs Henrik Kniberg
Trade-off
100% Component teams
Small orgs
Small orgs
Large orgs
Large orgs
Types of dependencies independent teams
Knowledge sharing
Henrik Kniberg
Building different products, but have dependencies
Knowledge sharing Dependency sync
Building the same product (implicit dependency!)
Knowledge sharing Dependency sync Product integration
Dependencies
Good Dependency (aka “collaboration”)
Bad Dependency Henrik Kniberg
!?#@%
Example: Visualizing team dependencies Team Bazinga
Team TBBT
Our Team Team Snap
Team Sheldon
Henrik Kniberg & Jan Grape
Team Flash
Example: Visualizing team dependencies
Henrik Kniberg
Good vs bad dependencies Full-stack team. Can deliver customer value independently.
Coupled teams A must sync with B in order to deliver customer value.
A
Platformized teams Team A1 and A2 are more effective because of team B’s platform
A1
A2
A Platform B
Henrik Kniberg
B
Customer-driven platform teams
External-facing teams Focus on delivering value to external customers
A1
Internal-facing teams Focus on making other teams more effective at delivering value to their customers. The other teams must obey us!
A2
Platform B
The other teams are our customers!
Key decision:
Where can we accept low-bandwidth communication? The speed of development is determined by the speed of ideas spreading
High bandwidth
Low bandwidth
Henrik Kniberg
High bandwidth Alistair Cockburn
Teams of Teams! Bunch of individuals
Small Teams
Teams of Small teams
Henrik Kniberg
Big teams
Decoupling to enable frequent releases
Client App squad
!#?
Feature squads Henrik Kniberg
Guidelines for team structure Try to ensure that each team: ❏ is 3-9 people ❏ is stable(ish), full-time & co-located. ❏ has a mission ❏ has clear customers ❏ can prioritize between customers (ex: via a PO role, or via clear strategic guidelines) ❏ cross-functional: has all skills and tools needed to deliver value to customers ❏ autonomous: doesn’t get blocked waiting for other teams and individuals. Henrik Kniberg
Scale the feedback loop
Henrik Kniberg
01:32
Single team feedback loops Sprint review Unit tests
Daily Standup Retrospective Continuous Integration
Henrik Kniberg
Multiteam feedback loops Whole Product review Cross team sync, retro, etc
Henrik Kniberg
Pattern: Integration Cadence
Henrik Kniberg
Henrik Kniberg
Pattern: 2-tier planning/alignment Months
Weeks
Henrik Kniberg
Weeks
Weeks
Weeks
Pattern: Plan on a cadence, release on demand Release 1.0
Planning event
Release 1.2.1 Release 2.0 Release 1.2
Release 1.1 Planning event
Release candidates
Henrik Kniberg
Release candidates
Planning event
Continuous Delivery = Aspirational.
Continuous Integration = Mandatory!
Automatic Manual Code & commit
Henrik Kniberg
Build
Test & integrate
Deploy to staging
Single click
Manual test
Deploy to prod
Get everyone aligned
Henrik Kniberg
01:32
Misaligned teams move very slowly
Henrik Kniberg
More teams = more likely that you will need dedicated leader(s)
Henrik Kniberg
Example: Leadership ”Trios”
Henrik Kniberg
Tech
Product
Design
T
P
D
Alignment & Autonomy
Alignment Do what I say!
Henrik Kniberg
False d
ichot omy
Autonomy
Do whatever
Alignment enables Autonomy We need to cross the river
High Alignment
Build a bridge!
Authoritative organization Conformist culture
Micromanaging organization
Low Alignment
Henrik Kniberg
Indifferent culture
Low Autonomy
Aligned Autonomy!
We need to cross the river
Figure out how!
Innovative organization Collaborative culture
Entrepreneurial organization Chaotic culture
High Autonomy
Hope someone is working on the river problem…
Example: Big-room planning/alignment at Lego Planning as a social event
Henrik Kniberg
2 days, 19 teams, 150 people
Henrik Kniberg
Demo video – what have we accomplished?
Henrik Kniberg
Lightning talks High level priorities: 1. ... 2. ... 3. .... Architecture vision / priorities / constraints
Digital Child Safety
Henrik Kniberg
Global Insights
Data Privacy Law
Pattern: Different levels of granularity Program/Product backlog Feature/Epic Marketable Releasable
Team Backlog
Team Backlog
Story
Testable Fits in a sprint
Henrik Kniberg
Story
Testable Fits in a sprint
Team breakout: Pulling from the program backlog
Henrik Kniberg
Team breakout: Pulling from the program backlog (digital version)
Henrik Kniberg Henrik Kniberg
Team breakouts
Henrik Kniberg
Law of 2 feet....
Program Board
(a.k.a Dependency Board)
Henrik Kniberg
Early detection of dependency problems
Henrik Kniberg
Scrum of Scrums = dependency sync
Henrik Kniberg
Simpler version of dependency sync Dependency board ”right now, who’s waiting for what from whom”
Henrik Kniberg
Risk board
(per project/epic)
Henrik Kniberg
Management review / problem solving
Henrik Kniberg
Day 2
Management feedback & commitment to help
Henrik Kniberg
Pattern: Information radiators
• In the hallway • Or in a War Room Zen Room
Henrik Kniberg
Big Picture – features/epics
Team 1 - stories
Henrik Kniberg
Team 2 - stories
Team 3 - stories
Example: Measuring velocity by counting cards
Count cards
Velocity per week
Henrik Kniberg
Example: Release planning using a burnup chart All of these will be done
Total # of delivered features
Week Some of these will be done, but not all
None of these will be done 65 Henrik Kniberg
65
Wrapup
01:32
Don’t go overboard with Agile! No plan
Rough, adaptive plan
No architecture
Rough, adaptive architecture
Bad Agile
Good Agile
Henrik Kniberg
Big up front plan
Big up front architecture
Waterfall
Stuff you need to figure out with multiple teams How to slice the elephant
Team structure
Henrik Kniberg
Team sync / alignment
Feedback loop
Dependencies!
Real-life agile scaling – take aways • Scaling hurts Keep things as small as possible • Agile is a means, not a goal Don’t go Agile Jihad. Don’t dump old practices that work • There is no “right” or “wrong” way Just tradeoffs • There is no one-size-fits-all But plenty of good practices • Build feedback loops at all levels Gives you better products and a self-improving organization. Henrik Kniberg
