This document discusses adapting kanban methods to fixed-size projects. It proposes using earned value management (EVM) techniques like tracking planned value, earned value, and actual costs to monitor project progress. Cumulative flow diagrams (CFDs) are recommended to visualize work flow and ensure the team is delivering at the desired throughput. When scope changes occur, multiple options should be evaluated using CFDs to determine their impact on capacity, timeline, and planned value before agreeing on an approach with stakeholders.
2. Fixed price projects...
9/23/2013
2
They have been estimated, scheduled and planned
with a certain in the pre-sales stage
Once you get the PO, you kick off the project with a
defined scope, budget and timeline
Further, the eco-system is not always fully agile:
There is a need for:
“Dynamic” resource capacity planning
Budget tracking and monitoring
Keeping the Stakeholders aware of whether the overall
scope is on track to be delivered in the committed timeline
Presales to
SOW
• Waterfall
Development
to Delivery
• Agile
Delivery to
Acceptance
• Waterfall
3. The Kanban Method
9/23/2013
3
Visualization using a
Project Board
- Map your value stream
- Show all work with
different swim lanes
Implement WIP to:
-Induce Flow
-Reduce multi-tasking
Establish Pull
-Uniform Cadence
-Greater commitment
Define explicit
policies
- DOD
5. Changing focus with
Agile/Lean...
Instead of asking... Ask...
What resources are available? Which team is ready to pull this
work into their backlog?
For an enterprise view of my
resources...
For an enterprise view of my work
execution, across projects
What is our (enterprise) capacity
in person months?
What is our (enterprise)
throughput/velocity in points?
How many people does this
project team need?
Am I getting enough throughput?
Incremental people !=
Incremental throughput
Discouraging Scope Change Recognize scope change as an
imperative and communicate with
the customer on impact/timeline
5 9/23/2013
6. Agile systems
9/23/20136
Agile extrapolates past throughput to predict
future
Inherently, they assume stable teams
They assume CFT teams
However, in service organizations, resource
allocations keep changing (# of
people, experience of people)
Solution: Applying EVM to Agile/Lean
methods
Traditional
EVM
Approach
Agile
Analytics
Expanded
Agile
Analytics
7. Here is what we do...
Define a
resource
plan for the
MMF scope
Use this as
the basis
for EVM
Track
velocity/
throughput
information
Re-calibrate
capacity to
delivery date
Allow for
scope
changes to
happen
7 9/23/2013
Planning
Phase
Activities
Execution
Phase
Activities
8. Original budget 48.57 MM 1020 MD
Original timeline 10
Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10
Productivity 100% 100% 100% 100% 100% 100% 100% 100% 100% 100%
Overall Development Resources 14 14 18.5 18.5 18.5 18.5 18.5 18.5 18.5 18.5
Overall ST Resources 3 3 3 3 3 3 3 3 3 3
Overall Development Resources 14 14 18.5 18.5 16.5 18.5 18.5 18.5 18.5 18.5
Overall ST Resources 3 3 3 3 3 3 3 3 3 3
Technical Requirement 1 2 2 4 4 2 2
MMF 1
User Story 1.1 2 2 4 1 1
User Story 1.2 2 2 2 2 2
User Story 1.3 1 1 1 1 1
ST Resources 1.5 1.5 1.5 1 1
MMF2
User Story 2.1 2 2 2 1 1
User Story 2.2 2 2 2 2 2
User Story 2.3 1 1 1.5 1.5 1.5
ST Resources 1.5 1.5 1.5 1 1
MMF3
User Story 3.1 2 2 2 2 2 2 2
ST Resources 1 1 1 1
MMF4
User Story 4.1 2 2 4 5 6 6 6
User Story 4.2 2 2 2 2 2
User Story 4.3 1.5 1.5 1.5 1.5 1.5
ST Resources 1 1 1.5 1.5 1.5
MMF5
User Story 5.1 2 2 4 5 6 6 6
User Story 5.2 2 2 2 2 2
User Story 5.3 1 1 1 1 1
ST Resources 1 1 1.5 1.5 1.5
Total (Current) 17 17 21.5 21.5 19.5 21.5 21.5 21.5 21.5 21.5
Planned value 85 85 107.5 107.5 97.5 107.5 107.5 107.5 107.5 107.5
Cumm. Original Plan Value 85 170 278 385 483 590 698 805 913 1020
Weeks
You would do something like
this...8
Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10
Overall Development
Resources 14 14 18.5 18.5 16.5 18.5 18.5 18.5 18.5 18.5
Overall ST Resources 3 3 3 3 3 3 3 3 3 3
Total (Current) 17 17 21.5 21.5 19.5 21.5 21.5 21.5 21.5 21.5
Cumm. Original Plan
Value 85 170 278 385 483 590 698 805 913 1020
0
200
400
600
800
1000
1200
ManDays
Planned Value
9. Making it a little more
practical...
Positive/negative factors on
productivity:
Resource ramp-up, skill
training, domain training, etc.
Team decides how to calibrate
productivity across time
Benefits:
PV: Planned Value
PV reflects reality
S-curve in PV
0
200
400
600
800
1000
1200
ManDays
Planned Value
Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10
Productivity 25% 50% 75% 100% 125% 125% 125% 125% 112% 112%
Development Res. 14 14 18.5 18.5 18.5 18.5 18.5 18.5 18.5 18.5
ST res. 3 3 3 3 3 3 3 3 3 3
Total (Current) 4.25 8.5 16.13 21.5 26.88 26.88 26.88 26.88 24.08 24.08
Cumm. Original Plan Value 21 64 144 252 386 521 655 789 910 1030
9 9/23/2013
10. Using AgileEVM for Planning
9/23/2013
10
AgileEVM approach
Defined by Tamara Suleiman and 2 others
An approach for EVM to Agile projects
Sound approach but we used a simpler template
for the following reasons:
Planned Value uniformly spread across project
duration
Accommodates scope change but does not
accommodate for a schedule change in the middle of
the project
Hard to read and interpret
Adoption is tentative
EVM modelling is available in some Agile tools
today
11. A little more complexity... with an
example
Estimated scope of 100mm; available
capacity: 80mm
10 calendar months fixed timeline
Plan for initial ramp-up
11 9/23/2013
12. Scenario I:
Dev Manager believes
than he/she will deliver
100mm with 80mm of
capacity
Total PV at proj completion
(EAC) = 100mm
Planned value distribution
based on resource
allocation distribution
Summary:
SV measured on PV =
100mm
CV measured on PV =
80mm
Scenario II:
Dev Manager believes that he/she
can deliver only 90mm of scope with
80mm of capacity
Total PV at project completion (EAC) =
90pm
Communicate to CDU for
remaining10mm
Planned value distribution based on
resource allocation distribution +
uniform distribution of gap (10pm)
This is because you want to plan for
90pm though the resource allocation
distribution is for 80mm
Summary:
SV measured on PV = 90mm
CV measured on PV = 80mm12 9/23/2013
14. The approach...
9/23/2013
14
On a weekly basis, EV is computed using
AgileEVM approach and plotted against the PV
To track EV:
Most Kanban tools dump their Board data to an Excel
Gives card wise, stage wise breakup
Two alternatives:
You can give a certain % completion to each stage of the
value stream completed on their estimated size
For example: Requirement done is 20% value
earned, Design completed is 15% value earned.... OR
Stick to Agile emphasis on “working software” and give 100%
value earned when a card is archived
Aggregate across the Board weekly and you will get the EV
trend
To track Actual Cost, get a weekly resource allocation
data
15. You will get a plot like this...
9/23/2013
15
20 40
95
149
204
258
313
418
523
628
733
919
1104
1290
1475
1546
1616
1686
1757
1827
0 0 0
50 80 100
150
200
308
350
0
200
400
600
800
1000
1200
1400
1600
1800
2000
Planned Value
Earned Value
Actual Cost
Schedule
Variance
Cost
Variance
16. Accepting change is “key” to Agile thinking
Challenge:
In fixed projects, how done one handle timeline and
budget?
Impacting Scope Change16
9/23/2013
17. The Approach...
CFD Shows the project end date for revised
scope @ current throughput
Reallocate capacity to match required
throughput
17 9/23/2013
18. Let us understand this with an
example...
Consider the following Board....
18 9/23/2013
XXXXXXXXXXXXXXXXX
XXXXXXXXXX
XXX
XXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXX
20. Now, evaluate Scope change...
120md of work has been added and updated
in the Backlog (highligted in red)
20 9/23/2013
XXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXX
21. Project the CFD again...
Required Throughput increases from 16.13/day to 18.09/day to
meet the same timeline
An increase of 12% in addition
21 9/23/2013
22. An iterative process with
stakeholders to evaluate options
and converge
Option I:
Increase capacity by 12-15% to reach desired throughput
Factor in an increase in overhead as team size increases
Option II:
Keep the same capacity but push back the timeline by 12-15%
Option III
Reprioritize scope to keep the total scope largely unchanged but deliver
to the revised timeline
Option IV
A combination of all of above for overall stakeholder agreement
Partial capacity increase + partial extension in timeline + reprioritizing
scope
For each option, use CFD projection to evaluate the final result
22 9/23/2013
23. Step 3: Adjust PV for revised
plan
For small changes in
resource
availability/scope, Planned
Value need not change
Small: < 10% estimate
variation
For significant
changes, rework Planned
Value as for modified
Resource Plan
0
200
400
600
800
1000
1200
1400
Cumm. Original
Plan Value
Cumm. Revised
Plan Value
23
Revised Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Wk11 Wk12
Productivity 25% 50% 75% 100% 125% 125% 125% 125% 112% 112% 112% 112%
Development Res. 14 14 15 15 15 18 18 18 18 12 12 12
ST res. 3 3 3 3 4 4 4 4 4 4 4 4
Total (Current) 4.25 8.5 13.5 18 23.75 27.5 27.5 27.5 24.64 17.92 17.92 17.92
Scope Addition (in mm) 5
Cumm. Revised Plan Value 21.3 63.8 131.3 221.3 340 477.5 615 752.5 875.7 965.3 1054.9 1144.5
9/23/2013
24. A quick re-cap
9/23/2013
24
Fixed price projects have characteristics that
need us to go beyond just Velocity/Throughput
tracking
Use AgileEVM thinking to track variance
between planned progress and actual
Use CFD to keep track of whether the team is
delivering at the desired Throughput
When scope changes, evaluate multiple
options using the Throughput and iterate with
stakeholders
The same approach would apply to SCRUM
projects also
25. Thank you for your time today...
For any questions or
clarifications, you can
reach me at:
@sudiptal
slahiri@digite.com
I share my experiences at:
http://www.swiftkanban.com/
blog/sudipta-lahiri
http://sudi-
thoughts.blogspot.in/
Join Limited WIP Society
Bangalore/Pune Chapters 9/23/2013
25