Managing Iterative Development Using Scrum

Managing Iterative
Development Using
Scrum
control the chaos

© 2001-2005 Craig Murphy

Does this look familiar?

Most software projects fail in
some way

Most software is buggy

Most software is hard to use
Dr..Neil Roodyn, International Developer, October 2004

Iterative Development…[and Scrum!]

Can reduce the failure rate

Can reduce the number of bugs

Can make software easier to use

Closer interaction with the customer

Disclaimer
 One person’s view…
 What works for me, might not work for you…
 Not intended to be a “my method’s better than your method”
session

 Not a “nitty-gritty” project management session

 I will be talking about:
 Why I have not adopted Scrum in its entirety
 Why I adopted the parts of Scrum that I did
 Why I adapted Scrum to suit my needs
 How I am using Scrum, yet still “appearing” to use traditional
heavyweight methods

 Like Scrum, this is a lightweight session 
 More of a Case Study perhaps…

Agenda

 Motivation
 Why Focus on Iterative Development?
 Setting the Scene
 What is Scrum?
 Scrum’s Artifacts
 Why Scrum Works…For Me (Adopting Scrum)
 Summary

Motivation
 To put my Scrum research and training to good use

 To adopt Scrum, albeit incrementally
 No “big bang” adoption

 To develop a façade that [initially] looks like we’re practicing
traditional project management

 Traditional project management seems to revolve around the
creation of often unnecessary artifacts that deliver little or no value
to the project

 Annoyingly, management seem to want these artifacts sooner rather
than later…BDUF, “fixed” or complete project plans…

Why focus on Iterative Development?
 Iterative Development
 Lots of small “product releases” over the project’s lifetime
 As opposed to one major product release at the end
 Bugs / Problems are found early
 Products are usable earlier in the process
 Involves the customer during each iteration

 Iterative Development lends itself to the Scrum
modus operandi
 Scrum’s artifacts promote customer involvement
 They allow the customer to re-prioritise the order in which
“development” work is done

Waterfall vs. Iterative Development

Customer
requirement gathering

happy, early
analysis & design

release?
development

testing
cost
of
change 80% of a
product’s

deployment
value comes
from 20% of
its features

time

 Traditional, Waterfall profit & loss cost curve

 Iterative Development, early release profit & loss cost
curve

Setting the Scene
 I use Scrum to manage development projects

 Typically internal systems, licensed to our clients

 Borland Delphi / InterBase / SQL Server or PHP / MySQL
 Pushing .NET as our recommended base platform

 Rarely “new” greenfield systems, typically improvements to existing
brownfield systems

 Development used to by a group of three internal developers
 External developers (contractors)

 Moderate amount of “developer on site”
 as opposed to XP’s “customer on site”

Setting the Scene
 I also use Scrum to manage

 User Group/Community activities

 Seemingly endless personal “to do list”

 Writing / Presentation schedule

What is Scrum?
 Scrum: It’s about common sense

 Is an agile, lightweight process
 Can manage and control software and product development
 Uses iterative, incremental practices
 Has a simple implementation
 Increases productivity
 Reduces time to benefits
 Embraces adaptive, empirical systems development
 Is not restricted to software development projects

 Embraces the opposite of the waterfall approach…

The Opposite of Waterfall

Source: “The New New Product
Development Game”, Hirotaka Takeuchi
and Ikujiro Nonaka, Harvard Business
Review, January 1986.

What is Scrum?

24 hours
Daily Scrum
Meeting

Backlog tasks 30 days
expanded
Sprint Backlog by team

Potentially Shippable
Product Backlog Product Increment
As prioritized by Product Owner
Source: Adapted from Agile Software
Development with Scrum by Ken
Schwaber and Mike Beedle.

What is Scrum?
 Scrum revolves around the ethos of simplicity, resulting in
delivery of something that moves the project forward:

1. What have you done during the last 24 hours?
2. What do you plan to do in the next 24 hours?
3. What’s stopping you getting on with the work of the next 24
hours?

 This is useful because:

1. This is progress, it’s work completed to date
2. This is forward planning, it is work you are about to do
3. These are your impediments or obstructions, it might be things
you need in order to work…more forward planning. It’s also
identification of immediate risks.

What is Scrum?
 Roles
 Product Owner
 Possibly a Product Manager or Project Sponsor
 Marketing
 Internal Customer
 etc.

 ScrumMaster
 Represents management to the project
 Typically filled by a Project Manager or Team Leader
 Responsible for enacting Scrum values and practices
 Main job is to remove impediments and remove any politics

 Project Team
 5-10 members
 Cross-functional: QA, Programmers, UI Designers, etc.

What is Scrum?
 Daily “stand up” meetings

 Folks who sit down at meetings get too comfortable
 They attend meetings for the coffee and doughnuts, not for the project’s
sake

 Only the ScrumMaster and the project team are allowed to
talk: outsiders may listen in, but are removed should they say
anything
 This is all about who is committed to the project or not…

What is Scrum?
 Daily “stand up” meetings

 Time-boxed, typically to 15 minutes
 if you can’t say what you have to say succinctly, you’re waffling

 Three questions:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?

 Keeping it time-boxed focuses folks minds and helps get/keep
agenda items targeted at what’s important:

Moving the project forward towards delivery of “something…” and
identifying and removing obstacles that prevent this goal being met

…that delivers business value

Agenda

 Motivation
 Setting the Scene
 What is Scrum?
 Scrum’s Artifacts
 Why Scrum Works…For Me (Adopting Scrum)
 Summary

Scrum’s Artifacts
 Scrum has remarkably few artifacts
 Product Backlog
 Sprint Backlog
 Burndown Charts

 Can be managed using nothing more than an Excel
spreadsheet
 More advanced / complicated tools exist:
 Expensive
 Web-based – no good for the ScrumMaster/project manager
who travels
 Still under development

Burndown Example
No work being performed
Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint

Burndown Example
Work being performed, but not fast enough
Sprint 1 Burndown

49

48

47

46
Hours remaining

45

44

43

42

41

40
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint

Burndown Example
Work being performed, but too fast!
Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint

Individual Burndown Charts

Craig's Burndown Sprint 1

35

30

25
Hours Remaining

20

15

10

5

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Sprint Day

Why Scrum Works…For Me
 It’s simple, Scrum’s three questions:

 Summary of work completed to date
or
 Summary of work complete in the last 14 days (1)

 Plan of work for the next 14 days (2)

 Project Issues requiring action from the Product Owner (3)

 I first used these three key elements of Scrum early in 2004,
the [small] audience loved the simplicity

 It’s fairly easy to convert a Sprint Backlog in to a
Microsoft Project “plan”
 Despite the cost of Microsoft Project licenses, upper
management seem to like “charts”

 Sprint Backlogs and Burndown Charts are early
warning indicators
 Lack of progress, very visible
 Not enough work or work too easy, very visible
 Assumes that everybody is committed to keeping the Sprint
Backlog up to date

 I’ve had some buy in to “stand up” meetings, but not
enough: we don’t practice them right now
 Perhaps because Scrum expects late-comers to pay a
nominal £1, $1, or €1 fine!

 Here’s another reason why I think some folks have
objected to them:

Summary
 Keep asking these questions:

 What is the simplest thing that can move the project
forward?

 Does what I am doing right now move the project forward at
all?

 Are there any impediments that are preventing progress?

 “Don’t procrastinate, do something, no matter how
small…” – Ken Schwaber, Vienna, April 2004

Summary
 Keep the team small and tight:
 Avoid folks with Teflon shoulders – “hangers on”
TM

 On a recent project, our core team comprised of:
 1 * business expert, with authority
 1 * IT expert, with internal Time & Expense experience
 1 * consultant with specific MIS implementation experience
 2 * business analysts

 Any larger and decisions become committee-driven:
 They won’t be made in a timely fashion

 Sadly, this project became committee-driven 

Summary

Far from
Agreement

Requirements Anarchy

Complex
C
om
pl
ic
at
ed

Close to
Simple
Agreement

Close to Technology Far from
Certainty Certainty

Source: Strategic Management and
Organizational Dynamics by Ralph Stacey
in Agile Software Development with Scrum
by Ken Schwaber and Mike Beedle.

Resources (Books)

Agile Project Management with Scrum
Ken Schwaber
Microsoft Press, 2004
ISBN 073561993X

________________________________

Agile Software Development with
Scrum
Ken Schwaber, Mike Beedle
Prentice Hall, 2002
ISBN 0130676349

Resources (web-sites)
 Scrum: It’s About Common Sense
 http://www.controlchaos.com
 Pay your £1, $1, €1 late-comer fee via this site! 
 http://www.scrumalliance.org
 http://www.mountaingoatsoftware.com
 Home of Mike Cohn’s “User Stories”

 Methods & Tools - Articles
 Improving Application Quality Using Test-Driven
Development
http://www.methodsandtools.com/archive/archive.php?id=20

 Adaptive Project Management Using Scrum
http://www.methodsandtools.com/archive/archive.php?id=18

Contact and Update Information

Craig Murphy

Updated slides, notes and source code:
http://www.CraigMurphy.com

http://www.developerday.co.uk

Managing Iterative Development Using Scrum

More Related Content

What's hot (20)

Similar to Managing Iterative Development Using Scrum (20)

Recently uploaded (20)

Managing Iterative Development Using Scrum