A year of Scrum
Lessons learned “going agile”
The Werks, 11th October 2008

Agile adoption at Future Platforms Skillswap, 21st November 2007

./&++-+,
0\"+1$'23$-\"+
.'(4-3$&5-/-$6
Agile adoption at Future Platforms !\"#$%&'()*+,-+(('-+,
Skillswap, 21st November 2007

!\"#$%&'(
)*+&,$*-.*%
/*0,.1&'%#2&3&%4
!\"#*5&*5(
6.78&,.-.*%9
:.$03.(;#'%$,9
6.%,$90.'%&+.(
!$\".,.*'.
Agile adoption at Future Platforms Skillswap, 21st November 2007

!\"#$%\"#&'()*\"%+',#-\"..\"%#/$01#)2#3\"*\"4)5+',#
1)2./$%\"#-0#3)+',#+.#$'3#6\"45+',#).6\"%1#3)#+.7#
86%)&,6#.6+1#/)%9#/\"#6$*\"#():\"#.)#*$4&\";#
!\"#$%$#&'()*'\"#*$\"+,-'.+$/\") )*\"%#5%)(\"11\"1#
$'3#.))41#
0/-1$\"2*)/3+4'-, )*\"%#():5%\"6\"'1+*\"#
3)(&:\"'.$.+)'#
5&)+/6,-*./(('7/-'+$/\" )*\"%#()'.%$(.#
'\",).+$.+)'#
8,)9/\"#$\"2*+/*.:'\"2, )*\"%#2)44)/+',#$#54$'#
86$.#+1<#/6+4\"#.6\"%\"#+1#*$4&\"#+'#.6\"#+.\":1#)'#
.6\"#%+,6.<#/\"#*$4&\"#.6\"#+.\":1#)'#.6\"#4\"2.#:)%\"7#
== >,+4\"#?$'+2\"1.)<#@AAB
Agile adoption at Future Platforms Skillswap, 21st November 2007

!\"#$%&'#()*+)%,-#*+(
.-&#(&/&)0$-&
12%3%&#(&+*&,$/++#+\"&
!\"#$%&\"#'()*+$(\"$(\",#-.)+/+0\")
.-&#(&0+4#()#,$#+%4
.-&#(&0+,3%4#)-/5$%
.-&#(&%/(6
.-&#(&(*$4&/(&/&(#$7%3&50$$%-
1+$(\".%)*+$%,/'.
.-&#(&8/(2#*+/5$%&50-&#-&9#$$&+*-&$/(-
Agile adoption at Future Platforms Skillswap, 21st November 2007

!\"#$%&'()*+$,#-\").)/)0(#+
! 1#/(#%#$(2$.#/(%#'(20$%&/*#
! 1#/(#%#$(2$3&(/(20$3&+-
! 3)4*+$)2$5#)5/#$6&4-)'+7$
\" 8),,*2(4&-()2
\" 9#/6:;'0&2(+(20$!#&,+
\" 8*+-),#'$<2%)/%#,#2-
! =/>&?+$<2+5#4-$&2.$=.&5-$
Agile adoption at Future Platforms Skillswap, 21st November 2007

Corporate growth pains
We tried Scrum previously and messed it up
We engaged a consultant to help us
It didn’t seem to be working so well

24
ho Daily standups
urs
Pro 2–
Ba duc
ckl t 4w
og
Sp ee
Ba rint
ckl
og
ks
Sprints never change length
S
Sprint backlog is fixed for sprint duration P
R
IN
Roles: Product Owner, Scrum Master, Team
T
Scrum in 3 minutes
De
live
rab
le

Crappy paper diagrams require little effort
Sprint progress is instantly visible
Effort burns down over time
Tracking a single sprint

What happened this sprint?
What worked?
What didn’t work?
What don’t we understand?
Retrospectives: inspect and adapt

Always finish the retrospective with a clear list of 4-8 items
Retrospectives: actions for next sprint

Rationalised stakeholders! 2 weeks til deadline, not 6 months
Definitive TODO list How fast you will go = how fast you have gone
One product owner Change welcomed
One product backlog Early visible progress
Prioritised requirements Realistic projections
Focused team Minimal overhead
Immediate benefits

also in our toolbox...

700
Additional
Original
Velocity is obvious
400 Demonstrates scope creep
100
-200
17 18 19 20 21 22 23 24 25 26
Tracking progress through a project

Pink = Awaiting QA
Prioritised left to right
Green = Done and QAd
Planning a sprint (S1-S23)

Work-in-progress limited
Requirements move through stages
Planning a sprint (S24)

“As a user, I want Implement
to be able to start protocol to
and resume chats start IM chat
with my IM buddies” VS.
+
Use customers language
Cut across disciplines Implement UI
Stories individually deliver value for IM chat
Placeholders for conversations
(backed onto foggy)
Acceptance tests documented
Easy to visibly prioritise
Both digital and physica
Express requirements as user stories

Continuous integration
Over-the-shoulder code reviews tied into CVS
- cross-projects?
Unit testing
UI/regression testing
Bug tracking/wiki
Never leave anyone behind
Informal lectures
TECHNICAL PRACTICES

Halves our estimation time...
...with no loss of accuracy
Planning poker for estimation

Lessons learned

Daily meetings
Problems surface early
Planning, review and retrospective always happen
It’s more discipline, not less

Change is going to happen - deal with it Don’t blame the customer
5 months
81 revisions
“Wireframes are Thanks to: to date
pretty much there. Should
be able to sign them off
- Competitive pressure
next week.” - Mid-project learning
- Usability testing
- Unpredictable good ideas
Dealing with change, not discouraging it

Our dev team are as cynical as I am
Some people don’t like working this way
(you should be able to incorporate them)
Scrum gets used in high-pressure environments e.g. medical
Expect some negativity

Extremely deficient Scrum Master (me)
Warnings only help if you listen to them

Spread workload evenly over project life We’ve eliminated culture of overtime
Plan and replan regularly
Team run at constant pace
Sustainable working life
“You know nothing of The Crunch”

Needs
Working Well
Improvement
ories Planning
Sizing st Having a Cross-project
y concept design
effectivel backlog prioritisation
Defining Contractual
Gold cards Multiple
“Done” frameworks projects
Sharing data riven
Process-d
with clients design
Bugs, then Good
features facilitation
Retrospective on the last year

As a beginner, you’re unqualified to change the process
Try it, get comfortable, then make changes
Experiences adopting

AGILE
MEANS
NOTHING
It’s a buzzword, and it’s overused
Parting thoughts

Thankyou
If you haven’t read them...
The Werks, 11th October 2008