Scrum = ? KTH, 2014-10-01
Consultant www.crisp.se
Henrik Kniberg
Father
henrik.kniberg@crisp.se @HenrikKniberg
Agile & Lean coach Author
Scrum? Agile
Lean
User stories
Continuous Integration
Kanban
Sprint
Velocity
TDD Pair programming
XP
Daily standup Henrik Kniberg
Retrospective
Personal story
Henrik Kniberg
01:39
Once upon a weekend...
(Nov 10-12, 2006)
5
Henrik Kniberg
Nov 13, 2006 Date: Monday, Nov 13, 2006! from: Henrik! to: scrumdevelopment@yahoogroups.com! subject: Scrum & XP from the trenches - how we do Scrum! ! I've written a paper (well more like a small book) describing lessons learnt after a year of Scrum experimentation with a group of 40 developers. Includes details on how we approached multi-team sprint planning, testing, retrospectives, etc. Here's the final draft: http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf Any feedback is welcome! Those of you who are authors, any ideas on what I should do with a paper like this? Haven't done this kind of stuff before... /Henrik!
6
Henrik Kniberg
4 years later...
250,000 downloads 13 languages
7
Henrik Kniberg
20 countries later...
Yes, Scrum works. Mostly.
8
Henrik Kniberg
March 23 2008 (6.5 years ago)
Henrik Kniberg
Henrik Kniberg
≈600 people in tech/prod ≈70 teams Stockholm 350 Gothenburg 30
Boston 30 San Francisco 10
New York 150
11
Henrik Kniberg
OK, so what is Agile then?
Henrik Kniberg
01:39
February 2001 Agile Manifesto (13.5 years ago)
www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Henrik Kniberg
That is, while there is value in the items on the right, we value the items on the left more.
Agile ”umbrella” –
a family of iterative, incremental methods
Scrum
XP
Kanban
Henrik Kniberg
DSDM
FDD Crystal
Agile is...
Early delivery of business value Less bureaucracy
Henrik Kniberg
(Thanks Alistair Cockburn for this simplified definition of Agile)
Case study: Game development company Design-ready games
Game backlog
15
8
1m
Concept pres.
4h
6m
Actual work: 3 months Time to market: 25 months
Resource planning
1d
1w
Graphics design
Sound design
1m
3w
Production-ready games
12 Dev
6m
6m
3m (1m+2m)
Integr. & deploy
3w
Most companies are organized for things like: • • • •
Minimum cost Maximum control Maximum accountability Maximum resource utilization
Henrik Kniberg
Who’s fault was it?
Needed: 5 volunteers
100% resource utilization = 0% flow High resource utilization
Henrik Kniberg
Fast flow
Beware the “productivity” illusion!
• Nobody actually wants software. • Your job is to produce as LITTLE software as possible to solve the business problem import java.sql.Connection; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class Dog { private Executor executor = Executors.newFixedThreadPool(18); private int CACHE_SIZE = 50; public Dog() { try { Class.forName("oracle.jdbc.ThinDriver"); connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); } catch (ClassNotFoundException e) {} new Thread().start(); } public void woof(Person woofCaller) { Connection connection = null; PreparedStatement statement = null; try { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); statement.setString(2, person.getName()); statement.setString(3, person.getPhoneNumber().getNumber()); statement.executeUpdate(); } } } } Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); b = a.prepareStatement("select * from Dog where name = '" + name + "'"); c = b.executeQuery(); if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); return person; } else { return new Person("", null); } } catch (SQLException e) { return null; } catch (IllegalArgumentException x) { throw x; } } public List<Person> getAll() { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); } if (statement != null) { if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); return person; } else {
Henrik Kniberg
Before Design-ready games
Game backlog
15
8
1m
Concept pres.
4h
6m
Resource planning
1d
1w
Graphics design
Sound design
1m
3w
Actual work: 3 months
12 Dev
6m
Cross-functional game teams
7 times faster!
Game team (graphics, sound, dev, test, deploy, etc)
Time to market: 3-4 months
Better games!
6m
3m (1m+2m)
Time to market: 25 months
After
Production-ready games
More fun!
Integr. & deploy
3w
Year 1 Q1
Year 2 Q2
Henrik Kniberg
Q3
Q4
Q1
Year 3 Q2
Q3
Q4
Q1
Q2
Q3
Q4
What about Scrum?
Henrik Kniberg
01:39
Small, cross-functional, self-organizing team
Henrik Kniberg
Split your organization
Scrum in a nutshell Split your product
Order the backlog
Large group spending a long time building a huge thing Small team spending a little time building a small thing ... but integrating regularly to see the whole Optimize process
$$$
Split time April
January $
Not checked out checked out
Done! :o) Deposit
SPRINT GOAL: Beta-‐ready release!
Write failing test
Burndown
2d
DAO
Code p cleanu
1d
GUI spec 2d
Migration tool
Tapes try spike
1d
Impl. migration 8d
Backoffice Login Integr. with JBoss 2d
Write failing test
Backoffice User admin GUI design (CSS) 1d
Henrik Kniberg
2d
Impl GUI
Clarify requirements 2d
1d
Write failing test 3d
Integr test 2d 0.5d
DB design 2d 1d
Write failing 2d test 3d 1d
2d
Unplanned items Fix memo ry leak Write (JIRA 125) 2d failing test
Sales support 3d
Write whitepaper 4d
Impl GUI
6d
Next Withdraw Perf test W ithdraw
Shu Ha Ri Shu = Follow the rules Ha = Adapt the rules Ri = Ignore the rules Scrumbutophobia (n) See also: Scrumdamentalism
Fear of doing Scrum wrong Symptom: Stuck in Shu Henrik Kniberg
Scrum overview – structure Product Backlog
Stakeholders
Scrum Team Sprint Backlog
Dev Team
Cross-functional, self-organizing Team - How much to pull in - How to build it - Quality - Sustainable pace
Users
Helpdesk
PO Direct communication
Operations
Management
... etc ...
Henrik Kniberg
Product owner - Vision: Where are we going & why? - Priorities & tradeoffs - Release planning
SM
Scrum Master - Process leader/coach - Impediment remover
Typical sprint Product Backlog
Potentially shippable product increment
PO
v1.3.2
Not checked out checked out
Deposit Code cleanup 1d
GUI
Migration tool
Tapest ry spike
1d
Impl. migration 8d
Integr. with 2d
GUI design (CSS) 1d
Clarify
(Backlog Backlog refinement) grooming
DB design 2d 1d
failing 2d 1d test 3d
2d
failing 2d test
GUI 1d
require2d ments
2d test
DAO Integr test 2d 0.5d
Write
JBoss
Backoffice User admin
Burndown
Write failing
Write
spec 2d
Backoffice Login Impl
Daily Scrum
SPRINT GOAL: Beta-ready release!
Done! :o)
Write failing test3d
Unplanned items Fix me mory Write leak (JI 2d failing RA 125)
test
Sales support 3d
Write whitepaper
Week 1
Next
Week 2
Week 3
Withdr f test
Per With draw aw
4d
Impl GUI 6d
Sprint backlog (Task board / Scrum board)
Demo/Review Retrospective
Sprintplanning
Timeline
Henrik Kniberg
Sprint isnâ&#x20AC;&#x2122;t the only way to iterate
Scrum sprints
week 1
week 2
week 3
week 4
Sprint 1 Plan & forecast
Alternative 1
week 5
week 6
week 7
week 8
Sprint 2
Review (release?)
Retrospective
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
Retrospectives (4w) Planning cadence (2w) Release cadence (1w)
Alternative 2 Retrospectives (4w) Planning (on demand) Release (on demand)
Henrik Kniberg
Why does this work?
Henrik Kniberg
01:39
Big Bang = Big Risk
Henrik Kniberg
Big Projects usually fail. Regardless of process. ”The Standish Group has categorically stated with much conviction—backed by intense research— that the secret to project success is to strongly recommend and enforce limits on size and complexity.” ”These two factors trump all other factors.”
< $1 million
Henrik Kniberg
> $1 million
What is a successful project? Scope
nah....
Budget
Henrik Kniberg
Schedule
What is a successful project? Project A
Project B
Scope
Budget
Budget
Customer
Schedule
Customer
Happy stakeholders!
Development team
Henrik Kniberg
Scope
Scope
Schedule
Users
Project C
Users
Development team
Budget
Schedule
Customer
Users
Happy stakeholders!
Development team
Big Bang = cannon ball Assumptions: • The customer knows what he wants • The developers know how to build it • Nothing will change along the way
Henrik Kniberg
Agile = homing missile
Assumptions: • The customer discovers what he wants • The developers discover how to build it • Most things change along the way
Henrik Kniberg
Minimize the need for Big Projects Big Bang = Big Risk
Henrik Kniberg
Agile = Iterative + Incremental Donâ&#x20AC;&#x2122;t try to get it all right from the beginning
cost
RISK
Henrik Kniberg
Donâ&#x20AC;&#x2122;t build it all at once
value
cost value
Not â&#x20AC;?horizontalâ&#x20AC;? increments
value
Henrik Kniberg
Client
3
Server
2
DB
1
”Vertical” increments! value
Client Server DB
Henrik Kniberg
1
2
3
Not like this....
1
2
3
4
Like this!
1 Henrik Kniberg
2
3
4
5
Cross-functional teams Client
Client team C
Server
C C
Server team S
S
Test team
Henrik Kniberg
Feature team 1
C
D D D
T
DB
S
DB team
T
User
T
Feature team 2 C
C
D T
S
S
D T Communities of interest
S D T
Improving the Value Curve RISK Big Bang
Big increments
Value
Henrik Kniberg
Effort
Small increments
Highest value first
Maximize Value, not Output
Henrik Kniberg
Always ask Why
Build a Bridge OK
Henrik Kniberg
Always ask Why
Build a Bridge Why?
?
We need to get to the other village without getting wet.
Options: • Bridge • Ferry • Tunnel • Move the villages together • Reroute the river Henrik Kniberg
What about planning?
Henrik Kniberg
01:39
Plan for change A B
Plan
C D
(doomed to fail, but we don’t know it yet)
Week 1 Week 2 Week 3 Week 4
Big Bang scenario
Oops, we’re late.
”We will deliver ABCD in 4 weeks”
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Agile scenario
”We always deliver something every sprint (2 weeks)” ”We think we can finish ABCD in 4 weeks, but we aren’t sure” A ”We always deliver the most important items first”
A B
A B E
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6
Henrik Kniberg
Oops, our velocity is lower than we thought. It looks like we’ll only finish AB by week 4. What should we do now?
A B C D
Example: Measuring velocity by counting cards
Done!
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 51 Henrik Kniberg
51
Shorten the feedback loop!
Henrik Kniberg
01:39
Fastest learner wins!
Delivery frequency = Speed of learning Stakeholders
Feedback and Requests
Demos and Releases
Development team
Henrik Kniberg
Minimize distance between Maker and User 1
People (# of handoffs)
2
Maker
User
Time (feedback delay) Henrik Kniberg
3
Release must be REALLY easy!
Release = Drama! Release!
Req
Release seldom
Code
Release is big
Test
Release is hard Release = Routine
Release often Henrik Kniberg
Release is small
Release is simple
Example: Decoupling to enable frequent releases
Client App squad
!#?
Feature squads
Henrik Kniberg
Continuous Delivery
How long does it take to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?
Automatic Manual Code & commit
Henrik Kniberg
Build
Test & integrate
Deploy to staging
Deploy to prod Manual test
Henrik Kniberg
Deployment should be so easy that even an Agile Coach can do it!
Henrik Kniberg
Face-2-face communication
Whoâ&#x20AC;&#x2122;s fault was it?
Improvement workshops
(retrospectives, post-mortems, etc) What did we learn? What will we change?
Henrik Kniberg
Idea/Problem â&#x20AC;&#x153;Radio you can save!â&#x20AC;?
Backlog Developing Released
Impact achieved
Narrative & Metrics & Prototypes Build MVP
Minimum Viable Product
Tweak
Deploy
to X% of users
Impact A/B test
Analyze data
Henrik Kniberg
Wrapup
Henrik Kniberg
01:39
Donâ&#x20AC;&#x2122;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
Many traditional projects
15,000 person-years of experience
Communication User involvement Small steps Henrik Kniberg
Agile is...
Early delivery of business value Less bureaucracy
Henrik Kniberg
(Thanks Alistair Cockburn for this simplified definition of Agile)
Find (or create) agile companies! How to recognize real agility: • Work in small, cross-functional, self-organizing teams • Release often & get real user feedback • Focus on Value rather than Output/Cost • Experiment a lot with product & process Beware empty buzzwords We do Scrum! We are Agile!
Henrik Kniberg
Agile @ KTH?
• Find common working hours • Use GIT to share code • Use Trello or Google drive to visualize progress
How to recognize real agility: • Work in small, cross-functional, self-organizing teams • Release often & get real user feedback • Focus on Value rather than Output/Cost • Experiment a lot with product & process Awesome (and free!) online tools: Trello
Henrik Kniberg
Google drive