Talk from Plone Conference 2012 in Arnhem, the Netherlands

1. Running successful Agile projects
© 2011 Deloitte MCS Limited. Private and confidential.

2. Hi, I’m Martin Aspeli. You may know me from such Plone
Conference talks as ….
“Design and Development with Dexterity”
“Extending and “Tools and techniques for a successful
“Coding for 2.1” customising Plone 3” Plone project”
2005 2006 2007 2008 2009 2010 2011
“Creating content types “Simplifying Plone” “State of the three D’s”
the Plone 2.5 way”
© 2011 Deloitte MCS Limited. Private and confidential.

3. Software development is
hard
3 © 2010 Deloitte MCS Limited. Private and confidential

4. Customers “If I'd asked my
customers what
don’t know
they wanted, they'd
what they want have said a faster
at the start of a horse. ”
project Henry Ford
© 2011 Deloitte MCS Limited. Private and confidential.

5. Developers don’t know
how to build it at the
start
© 2011 Deloitte MCS Limited. Private and confidential.

6. Things
Change
© 2011 Deloitte MCS Limited. Private and confidential.

7. It’s hard
work
© 2011 Deloitte MCS Limited. Private and confidential.

8. People do
not like bad
news
© 2011 Deloitte MCS Limited. Private and confidential.

9. Agile methods address
these challenges
9 © 2010 Deloitte MCS Limited. Private and confidential

10. © 2011 Deloitte MCS Limited. Private and confidential.

11. An empirical vs. a defined process
Software development is as much an art as a science, with low task
repetition and much uncertainty
Empirical Process Defined Process
V
Lean / Agile Waterfall
Daily
Stand
Up
Requirements
Validation 4 Week
Iteration Project Wrap-up
&
Design
11 © 2011 Deloitte MCS Limited. Private and confidential.

12. The aims of Agile methods
Deliver business value regularly and incrementally
Provide visibility to the business throughout the project
Reduce delivery risk steadily throughout the project
Maintain adaptability to business change as long as possible
Linear, ‘waterfall’ methods Agile methods © 2011 Deloitte MCS Limited. Private and confidential.

13. 1. The right project
13 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.

14. Your core strengths
• Is this something you are good at?
• What is your ‘sell’ to the client?
14 © 2011 Deloitte MCS Limited. Private and confidential.

15. Your strategic objectives
• Will the project make you money?
• Will it give you a credential for the
future that’s worth taking a risk for?
• Will it open up a new client?
• Will you learn something new?
15 © 2011 Deloitte MCS Limited. Private and confidential.

16. The right size client
If:
• Size of client > 10 x size of
supplier?
• Size of supplier > 10 x size of
client?
Think twice!
16 © 2011 Deloitte MCS Limited. Private and confidential.

17. 2. The right contract
17 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.

18. Why is it always fixed price?
Imagine you are middle management at
a medium-to-large size company
Problem:
• Meet your budget
• Deliver on time
• Make the business happy
Solution: Put all the risk on the supplier
18 © 2011 Deloitte MCS Limited. Private and confidential.

19. The iron quadrangle
Pick any three…
Scope
Time
Cost
Quality
19 © 2011 Deloitte MCS Limited. Private and confidential.

20. How to deal with fixed price/fixed scope
• Estimate well
• Put the baseline scope in the
contract
• Add a risk premium of 10-25% (see
‘Dark Matter’ later)
• Establish a fair and efficient change
control process
• Allow ‘one-in-one-out’ change for
free, but track it
20 © 2011 Deloitte MCS Limited. Private and confidential.

21. Variable scope
• The problem with ‘fixed price’ isn’t
fixing the price…
• … it’s fixing the scope
• A better question: How much value
can you deliver for how much
money?
• Fixed price for fixed capacity: “We
will work with you to prioritise the
scope, and work through it in priority
order. You can change priorities on
anything we haven’t started yet.
Hence, we will give you the best
value we can deliver for $xx in total”
21 © 2011 Deloitte MCS Limited. Private and confidential.

22. Time-and-materials
• Theoretically the most efficient
contract structure
• Good if there is significant trust and
a track record
• Needs mature risk and change
management on both sides
• There is always a budget
somewhere!
22 © 2011 Deloitte MCS Limited. Private and confidential.

23. Fixed time box
• Combination of the above
• “We work in time boxed iterations of
2 weeks. Each iteration costs $xx.
We will prioritise the scope and
work through it in order. At the end
of each iteration, we will deliver
‘shippable’ functionality. You can
terminate the project by giving one
full iteration’s notice”
• Gives you some certainty and
control
• Gives the client some certainty and
control
23 © 2011 Deloitte MCS Limited. Private and confidential.

24. 3. The right method
24 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.

25. Our methodology framework
… is based on core values, disciplines and activities
Evaluate environment Iterative delivery (2-4 weeks)
Requirements
Post implementation
and define process
Core activities
validation
Release planning Iteration review
Design
Architecture
definition
Iteration planning Development Deployment
Testing
Business analysis Acceptance
Continuous delivery
Core disciplines
Planning
Requirements management
Quality assurance
Change management
Risk management
Core values
Focus on Quality in
business everything Simplicity Collaboration Feedback Commitment Visibility
value we do
25 © 2011 Deloitte MCS Limited. Private and confidential.

26. Method overview
Our most commonly used method is based on Scrum™, with additional
elements tailored to a professional services environment
Phases Iterative Phase 2-4 Weeks
Iteration Zero Design
Iteration Review Project
Preparation Working
Planning wrap up
Produce Software
Build
Produce Initial Backlog
Update Project Project Review
Business &
Backlog &
Case Release Plan Test
& Training
& & Review
Agree Iteration &
Vision Executable Process
Backlog Support
Architecture Deploy
Daily
Artifacts Stand-up Roles
Project & Iteration Backlog Product Owner
Impediments List Project Manager
Project, Release & Iteration burn-down Team
Working Software Stakeholders
Users
26 © 2011 Deloitte MCS Limited. Private and confidential.

27. Requirement lifecycle
Each user story goes through a defined lifecycle that includes the definition
of detailed acceptance criteria, and quality assurance once it has been
built.
Prioritise Define Sign off
Build and Technical
and acceptance acceptance Deploy
test and BA QA
schedule criteria criteria
Requirements decision matrix Acceptance criteria
Given a login page
When I enter my username and password correctly
Clarify Implement Then I am logged in
Given a login page
Priority
When I enter an incorrect username and password
Then I am shown an error message
Park Wait Given a login page
....
Clarity
27 © 2011 Deloitte MCS Limited. Private and confidential.

28. Release process
‘Big Bang’ releases carry too much risk too late into the project. Smaller,
incremental releases reduce risk and improve visibility and feedback.
One or more sequential iterations in a release
Release 1
Iteration 1
Release Release
Release Review Iteration Iteration Release 2 n
Planning Iteration 2 n Review
Implementation Working
Planning
Software
One or more sequential releases in a project
28 © 2011 Deloitte MCS Limited. Private and confidential.

29. Flow of work (Kanban)
The lightweight method defines key events such as iteration meetings and
daily stand-ups. Within (or across) the iteration, work flows through a
process that will differ between teams. This can be visualised with a
kanban board.
Work in progress limits enable
a pull system of work allocation
Project Iteration In Dev (8) QA (4) Done
Backlog Backlog (10) Slack
capacity is
key to
The board continuous
visualises improveme
work and nt
bottlenecks /
slack
Capacity can be based on work item
types (e.g. features vs. bugs)
29 © 2011 Deloitte MCS Limited. Private and confidential.

30. Are we being Agile?
Agile Decision Filter (David J Anderson)
1. Are we making progress with imperfect information vs. delaying in order to get
more perfect information?
2. Are we encouraging a high trust culture?
3. Do we treat unfinished work (WIP) as a liability and not an asset?
It helps to understand the cost of delay: The longer we wait to build something, the
longer we have to wait to realise its value.
30 © 2011 Deloitte MCS Limited. Private and confidential.

31. A typical project plan
Ready to build Working software Project complete
Mobilisation Iterative Delivery Handover
2-6 weeks 2-4 weeks x N 2-6 weeks
Iteration +1
Iteration planning Factory testing Iteration review
pre-planning
Daily stand-up meetings
Daily risk/issue calls
31 © 2011 Deloitte MCS Limited. Private and confidential.

32. Things to track
e.g. in JIRA, Trac, …
Item type Description Reporting
Developer
Defect A bug discovered in testing by the client Defect list
or a third party, i.e. after code released Cumulative Flow Diagram
from the factory.
User story A requirement in scope. Kept in priority Burndown chart
(Requirement) order, and fleshed out with detailed Cumulative Flow Diagram
acceptance criteria just in time.
Epic High level area of scope. Useful for Release plan
release planning.
Clarification A question outstanding linked to a Dashboard with due dates
requirement.
Dependency A dependency on the client with a due Dashboard with due dates
date, required to complete build.
Risk A project risk, including probability and Dashboard in priority order
impact. Daily calls
Issue A live project issue, e.g. a development Dashboard in priority order
Manager
impediment. Daily calls
Change A discussed or agreed change in project Dashboard in priority order
scope. Daily calls
32 © 2011 Deloitte MCS Limited. Private and confidential.

33. 5. The right metrics
33 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.

34. Estimating user stories
Estimating the effort involved in a user story is done by the team that will
be committing to delivering it, and only that team. Estimates should be
based on size and complexity, not duration, and must be shared by the
team.
Story points
Story points are a relative measure of the size (or complexity) of a story. A
user story estimated at 10 story points will take twice as long as one estimated
at 5.
Ideal time
Ideal time is the time it would take to complete a task should there be no
interruptions. A football match lasts 90 ideal minutes but the elapsed time it
takes is more like 120 minutes.
Three techniques can be used to derive an estimate:
‒ Expert opinion
‒ Analogy
‒ Divide-and-conquer
34 © 2011 Deloitte MCS Limited. Private and confidential.

35. Prioritising user stories
… is the primary responsibility of the Product Owner. Others can provide
guidance and support, but the decision rests with him or her.
Factors to consider
• The business value of having the story
• The cost of developing the story
• The amount of knowledge and understanding of the system and future
requirements that will be gained from implementing the story
• Dependencies
• The amount of risk removed by implementing the story
35 © 2011 Deloitte MCS Limited. Private and confidential.

36. Planning
… is an on-going process. Planning far in future is kept general and
planning for the near future is detailed. There are three types of planning
involved in an agile process:
Release Planning
• A release is made up of a number of iterations
• Can include themes and epics
• Buffer for time, features or both
Iteration Planning
• An iteration last between 2 and 4 weeks
• Themes and epics must be broken down
• User stories which are selected for the iteration are broken
into tasks
Daily Planning
• Daily 15 minute stand-up
• Focused on tasks and impediments
36 © 2011 Deloitte MCS Limited. Private and confidential.

37. Velocity
Measuring the speed of the team
“Number of story points delivered by
the team in a complete iteration”
It is a fallacy to measure ‘individual’ velocity or ‘day’ velocity. It is also dangerous to
try to calculate a ‘points-to-days’ multiplier – it will be ~ 20% wrong at least, and so
should not be used for individual items.
37 © 2011 Deloitte MCS Limited. Private and confidential.

38. Burn-down
Measuring progress against the backlog over time
A Burn Down Chart is used to show work done against time. It lets all those
involved in the project quickly see the progress of the team and allows a trend
(velocity) to be identified so completion date can be estimated.
Example burn-down chart
Project Burndow n Chart
700
600
Effort Points
500
400 Original + Replanning + Change
300 Original + Replanning
200
100
0
07
07
07
07
07
07
07
07
07
07
07
07
07
07
07
07
07
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
20
4/
4/
4/
5/
5/
6/
6/
7/
7/
8/
8/
9/
9/
0/
0/
0/
1/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/1
/1
/1
/1
02
16
30
14
28
11
25
09
23
06
20
03
17
01
15
29
12
Date
38 © 2011 Deloitte MCS Limited. Private and confidential.

39. Cumulative Flow
Identifying bottlenecks and reviewing work-in-progress
When using Kanban to track flow, we 100
can analyse how the distribution of 90
work-in-progress across different states 80
Number of stories
change over time using a Cumulative 70
WIP
Flow diagram. This plots the number of 60
items in each state as a stacked area 50
chart, either for the duration of the 40 Mean cycle time
project, or for one iteration. 30
20
10
0
Where there are sudden significant 1 2 3 4 5 6 7 8 9 10
changes in the number of items in one Week
state, a bottleneck may be developing.
Done In progress To do
We can identify the mean cycle time by
measuring horizontal lines from the
start state to the end state
39 © 2011 Deloitte MCS Limited. Private and confidential.

40. Throughput forecast
In complex projects, activity-level planning is too difficult and often counter-
productive. Throughput forecasting is more accurate and much easier.
• Break work down into similarly- 100
sized, independently schedulable 90
80
chunks (e.g. user stories)
Number of stories
70
• Track moving average rate of 60
completion (e.g. from detailed 50
analysis/design to completed work) 40
30
• Use this to forecast future
20
performance 10
• Estimation is waste! Historical data 0
1 2 3 4 5 6 7 8 9 10
is more accurate and takes less Week
time away from value-adding work. Done In progress To do
• Ideally, only estimate for items that Moving average throughput
have a true fixed delivery date to
know when they must be started.
40 © 2011 Deloitte MCS Limited. Private and confidential.

41. Little’s Law
We can discover how much parallelisation (WIP) we need by using Little’s
Law
How many things we need to do in parallel.
For efficiency, we want this to be small relative to
number of people, hence this is relative to team size
Work-in-Progress (WIP)
Average Throughput =
Average lead time
Target to achieve the plan
Observed capability: treat as a constant.
Can be improved only over time, or by
changing the process/system.
41 © 2011 Deloitte MCS Limited. Private and confidential.

42. S-curve
Throughput is normally lower at the beginning and end of a project. We
can simulate the “S”-curve effect with a “Z” for estimation purposes.
100
90 Last 20%
80
70
60
50
Middle 60%: 3.5 – 5x throughput
40
30
20
First 20%
10
0
1 2 3 4 5 6 7 8 9 10
Done In progress To do
42 © 2011 Deloitte MCS Limited. Private and confidential.

43. Dark matter
Scope is never fully understood up front. We have a “known unknown”
quantity of additional scope that will come in during the project.
Dark matter (20-50%): Stories were Original scope reduced (e.g. over- Scope creep: Agreed new scope,
underestimated, or are now recognised as estimated) subject to change request.
epics. Client does not consider this to be
new scope.
140
120
100
Number of stories
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10
Week
Original scope Dark matter Scope creep
43 © 2011 Deloitte MCS Limited. Private and confidential.

44. Reporting true progress
Passing tests that meet client’s acceptance criteria = true progress
http://corejet.org
44 © 2011 Deloitte MCS Limited. Private and confidential.

45. Comparing project profitability
• How many hours did the team put in
vs. what you could you charge
(invoice schedule, agreed rate card,
day rate vs. hourly rate…)
• Compare actual rate to theoretical
maximum, i.e. if full rates were
charged for all hours worked
• Absolute number doesn’t matter
(much), but comparison among
projects do!
45 © 2011 Deloitte MCS Limited. Private and confidential.

46. Further reading
46 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.

47. Some interesting things to read
• Various books on Scrum
• User Stories Applied (Mike Cohn)
• Agile Estimating and Planning (Mike Cohn)
• Kanban (David J Anderson)
• Lean Startup (Eric Ries)
47 © 2011 Deloitte MCS Limited. Private and confidential.

48. This is an internal document which provides confidential advice and guidance to partners and staff of Deloitte MCS Limited. It is not to be copied or made
available to any other party.
© 2011 Deloitte MCS Limited. All rights reserved.
Member of Deloitte Touche Tohmatsu Limited
© 2011 Deloitte MCS Limited. Private and confidential.