The document provides 10 tips for making Agile adoption more successful. The tips are: 1) use a physical board, 2) collect and use statistics, 3) engage a coach or consultant, 4) prioritize action over talking, 5) the only way to know is to do it, 6) enthuse and pull people rather than push change, 7) be clear on the reasons for adopting Agile, 8) don't forget the technical aspects, 9) ensure a clear flow of requirements, and 10) consider structural changes like using vertical teams rather than projects. The document is authored by Allan Kelly from Software Strategy Ltd.

1. 10 Tips to make Agile Adoption
more successful
allan kelly
Twitter: @allankellynet
http://www.softwarestrategy.co.uk/allankelly

2. Allan Kelly
Director, Software Strategy Ltd
– Consulting & Training for Agile
– Custom Software Development
Author
– Changing Software Development: Learning
to be Agile (2008, Wiley)
– Business Patterns for Software Developers
(2012, Wiley - ISBN: 978-1119999249)
97 Things Every Programmer Should Know
Henney, 2010
Context Encapsulation in
Pattern Languages of Program Design
Volume 5, 2006
(c) Allan Kelly http://www.softwarestrategy.co.uk 2

3. The amount of significant, often
The Problem traumatic, change in
organizations has grown
tremendously over the past two
• Change fails decades.
– 70% change initiatives fail
– (Commonly cited % but from where?)
• Agile introduction fails Prof John P. Kotter, 1996
“Leading change”
• Agile delivery fails
– (We even have names for it)
Scrummer
Fall Has this
changed?

4. 10 Tips for Agile Adoption
① Use a physical board ⑦ Clear on Why?
② Collect & Use Statistics ⑧ Don’t forget the
③ Engage Technical
Coach/Consultant ⑨ Clear requirements flow
④ Action over talking ⑩ Structural change
⑤ Only way to know is to
Do
⑥ Enthuse, Pull, don’t
Push

5. Some advice…
"I can't understand why
people are frightened of
new ideas. I'm frightened
of the old ones."
John Cage

6. #1 Use a Physical Board
“I put the shotgun in an Adidas bag
and padded it out with four pairs of
tennis socks, not my style at all, but
that was what I was aiming for: If they
think you're crude, go technical; if
they think you're technical, go crude.
I'm a very technical boy. So I decided
to get as crude as possible.”
William Gibson, Johnny Mnemonic (in Burning Chrome, 1995)

8. Lightsabre
Every team must design their own board

9. Use the board, Luke
• Accelerates learning
• Always visible
– Shared view
• Easy to change

10. #2 Collect & Use statistics
Basic Product Burn-Down Chart
250
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Iteration
Work to do

11. Burn-Up, Burn-Down
Burn-Up, Burn-Down
250
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Iteration
Series5
(c) Software Strategy Ltd. 11

12. Burn-down with velocity
Burn-Down with Velocity
250 40
35
200
30
25
150
20
100
15
10
50
5
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Iteration
Work to do Velocity
(c) Software Strategy Ltd. 12

13. Layered burn-down
250
• By
200
release, milestone
150
, phase, etc.
100
• By epic or
50 collection of
0 stories
1 2 3 4 5 6 7 8 9 10 11 12
13

14. Simple Cumulative Flow Diagram
140
120
100
Points
80
60
40
20
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13
Iteration
Work to do Total done

15. Do you know?
• Velocity: How fast are
you going?
• Backlog:
– How much work do you
currently know about?
• How long does it take
for work to clear board?
– Rate of increase? (Scope
Creep) • How many “bugs” do
– Rate of decrease? (Scope you have?
Retreat) • What else is useful for
• Where you time is you to track?
going?

16. Metrics warning!
1. Avoid hours: Human’s can’t
estimate
2. “Points” break-down with
experience & stress
3. Goodhart’s Law Any observed statistical
regularity will tend to
collapse once pressure is
placed upon it for control
purposes.

17. #3 Engage a Coach/Consultant
• You can do this yourself, but…
– Increase risk
– Adoption slower
Warning:
Consultant talking

18. Agile Coach
• Notice
• Feedback The art of Agile coaching
is understanding the
• Educate situation, the values
underlying Agile
• Facilitate software
development, and how
• Support the two can combine.
Agile Coaching
Davies & Sedley, 2009
(c) Software Strategy Ltd. 18

19. Agile Coach
• Advisor – consultant?
• Process expert
• Someone with War Stories & Scars
• Commonly
– Occasional visitor who advises on Agile
adoption, problems
– Suggests, mentors, trains
(c) Software Strategy Ltd. 19

20. 4D Coaching What is the company making?
How is the company organized?
Company: Strategy Advice for senior managers
What processes are followed?
Are you delivering?
Product: Process Advice for teams
What is the architecture? Is the
code tested?
Code: Technical Are you finding bugs?
Advice for programmers
Time…. Don’t expect everything at once
Use different coaches in different dimensions

21. What's the best way Both ends at once
to take a bridge?
Brigadier General Gavin
Major Julian Cook
Quote: A Bridge Too Far
• Cornelius Ryan (Book) Image: Nijmegen bridge from
FaceMePLS, Creative Commons License on
• Richard Attenborough (Film) Flickr

22. Our bridges have 3 ends! Technical
Management
Process &
Products
Tridge, Midland, Michigan - Image from © Gary Teall, Fenton Low Altitude
FLAP @ http://www.panoramio.com/photo/15573763

23. Should we use
#4 Action over talking Scrum or XP?
• You could…
– Ask lots of legitimate Should we be
questions Agile or Lean?
– Make lots of plans
How do we get
We need to plan the business to
our adoption buy in?
carefully
Our Project Where is the
Office won’t evidence it
like it works?

24. #4 Action over talking
Or
• You could just start doing what you can and
see what happens
• Just Do It

25. #5 Only way To Know is To Do
• Just do it!
• Until you try doing Agile you can’t answer the
questions
• Agile is Empirical
– Try it and see what happens
• Agile is Learning
– Learning -> Change -> Learning

26. #6 Enthuse, Pull, don’t Push
• Agile is a change initiative
• Why would agile be any different?

27. Don’t push change - Let them pull!
• Lay out your stall • Support interest
– And wait
• Fan the flames

28. The Change from Above Myth
• Might work for a dictator, but..
– Communication, Motivation, Ap
plicability, Local differences, Self-
Interest
Push from top
– (Dictators typically carry a big
stick, IT Mangers don’t)
(c) Allan Kelly - April 2006

29. Just Do It! ™
“Nobody gives
Stop being led by your
you power,
leaders…
You just take it”
And start leading them
Rossanne Barr
quoted by Tom Peters in Re-Imagine!

30. #7 Be clear: Why?
• What are you trying to achieve?
• How do you know what tools to
choose?
• What are you trying to optimize?
– Elapsed time: idea to product
– Efficiency of delivery
– Maximize revenue
– Minimize costs
– Speed to completing some “Backlog”

31. #8 Don’t forget TECHNICAL
It’s the
• Poor technology… code, stup
– Lots of bugs – is the story done? id
– Can you close a iteration? - can you
deliver at the end of iteration?
• Developers morale 
– “Technical debt…
– Technical debt….
– Technical debt…”

32. The Technical side
• Increase quality
• Eliminate….

33. Invest in Technical
Software Craftsmanship
– Take quality seriously
Images from WikiCommons under Creative Commons license
Alegro - Charles01, Rolls Royce & VW - Thomas doerfer

34. TDD works!
IBM Microsoft Microsoft Microsoft
drivers Windows MSN Visual
Studio
Defect density W X Y Z
(non-TDD)
Defect density 61% of W 38% of X 24% of Y 9% of Z
(with TDD)
Increased time 15-20% 25-25% 15% 25-20%
(with TDD)
Nagappan, Maximilien, Bhat and Williams (Microsoft Research, IBM Research, North Carolina
State University). Empirical Software Engineering journal 2008
http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

35. Bugs
• How much time do you spend finding
bugs?
• How many testers do you need?
• How many bugs do you have logged?
• How many bugs do you fix before
shipping?
• How much time do you spend in
meetings discussing bugs?
How would your life change if there
were no bugs?

36. Without technical side…
• Bugs overwhelm
– Can’t deliver working software
• Code becomes difficult to change
– Velocity slows
• So we test…
– Test is slow & expensive
• And we avoid change…
– Avoiding change is avoiding Agile

37. Agile without quality?
• How do you know you are done?
• How do you time box?
– How do you eliminate Test-Fix cycle?
Agile without Quality
is like Starbucks
without Coffee
Starbucks image © Louis Abate, Creative Commons License, c/o Flickr

38. #9 Clear Requirements Flow
Every 2 weeks….
Development Team Working
software
• Keep arteries clear – keep feeding team
– Keep work flowing – little and often

39. Please
OK, here’s
A story… help… we
what you
want to be
do….
Agile!
Umm… but I
don’t think they
really know what
they are building
Or why….
Gee… we took In fact, they don’t
even have a
the medicine business strategy
Dev Team
and things are that makes sense
much better

40. Supply and Demand
Quantity of
Software / IT Demand also needs fixing
(but fix it second)
Supply
(Development)
Demand
(Business
Case/Requirem
ents)
0 Price of Software / IT
Initial focus on development
improving supply

41. The Real Problem Demand is rampant
Quantity of and inelastic
Software / IT
Mind the gap
Supply
(Development)
0 Price of Software / IT
Supply is severely development
constrained and inelastic

42. Worse? Demand - More
Quantity of technology we
Software / IT have, the more we
want
Mind the gap
Supply
constrained by
Brooks Law
0 Price of Software / IT
development

43. #10 Structural change
• Process will take you so far…
• Technical (alone) will buy you lots…
• But…

44. Vertical teams
• Staffed to delivery
languages), Requirements, Manage business value
ment, Testing, etc. etc. • Responsible for delivering
business value
• All skills needed
Code (all
• Keep together
– Grow, shrink
– Add new people, let folk
leave

45. Forget projects
• Form around Products
• Project thinking is an obstacle
• Good systems never die The initial difficulty with
– They just evolve schedule measurement is
a basic one: Identifying
• Bad systems die the start point of any
• “Done” given project!
– Empty backlog is a sign of failure
• Leave “Project” for accountants
Capers Jones, 2008

46. ① Use a physical board
② Collect & Use Statistics
③ Engage Coach/Consultant
④ Action over talking
⑤ Only way to know is to Do
⑥ Enthuse, Pull, don’t Push
⑦ Clear on Why?
⑧ Don’t forget the Technical allan kelly
⑨ Clear requirements flow Software Strategy Ltd.
⑩ Structural change www.softwarestrategy.co.uk/
allankelly
allan@allankelly.net
Twitter: @allankellynet