Tocico2016 Agile CCPM

2016 TOCICO International Conference
How Agile CCPM enables us to

successfully complete challenging
projects for major upgrades of
exis?ng so@ware products, and
maintain 100% DDP for years
Koichi Ujigawa
2016 TOCICO. All Rights Reserved.
About the Project
The project was challenging, because:

it was a Major Upgrade of an exisGng
soHware product
it required DisconGnuous InnovaGon
and state-of-the-art technologies
(we need to get on the red curve)
DisconGnuous
And also, needless to say, InnovaGon
due date of the project had to
be met and the ow of the
system had to be maintained
About the Project (cont.)
There are several modaliGes for recognizing a

projects environment, such as Complicated
and Complex
In the Complicated environment, Cause and
Eect can be captured in planning phase, even
it seems to be (almost) impossible at rst sight

In the Complex environment, Cause and Eect

cannot always be captured, even it appears so in
retrospect
It constantly changes according to external
condiGons
But a big direcGon/paZern can be obtained

The project was challenging, because its

environment was recognized as Complex
Complicated
Complex

We believe that the following percepGons

are more important than usual in the
Complex environment
it is beZer to be approximately right than to
be precisely wrong
the more complex the problem is, the more
simple the soluGon has to be
And we believe that we should be more
innovaGve and invenGve than usual
We knew that more adaptability,

responsiveness and autonomy would
enhance the intuiGon of developers
during the project
We decided to apply Agile CCPM
In our pipeline, projects are managed by either
standard CCPM (*) or Agile CCPM
*The term standard CCPM is used to
avoid confusion during the presentaGon
Agile CCPM in a nutshell
Agile CCPM is an enhancement of

CCPM, employing the following for SW
development (*):
Modied Network ConstrucGon Process
Modied Buer Management Method
*Conceptually, this can be applied to other environments

such as R&D, NPD and organizaGon design
Agile CCPM in a nutshell (cont.)
All the benets and aZributes of CCPM are

maintained while building in the
adaptability, responsiveness and
autonomy of some of the pracGces
adopted by Agile
It is agile, not in the sense that it is a
hybridizaGon of Agile and CCPM, but in the
sense that it makes standard CCPM more
adaptable to change
Agile CCPM in a nutshell (cont.)
Although we use slightly dierent

techniques in certain situaGons,
none of the fundamental rules or
benets of CCPM are sacriced
For this reason, the applicaGon
enhancement is truly CCPM

Quick Review of standard CCPM
Procedure in planning
Add tasks and dependencies
Level resources
IdenGfy the CriGcal Chain
Insert buers
Procedure in execuGon
Execute tasks and report RDU
Update buer status
Take recovery acGon as required
Procedure in Planning
- Standard CCPM -
Add tasks and dependencies

- Standard CCPM -
Level resources

- Standard CCPM -

- Standard CCPM -
Insert the project buer

- Standard CCPM -
Insert feeding buers

Procedure in Execution
- Standard CCPM -

Update buer status

- Standard CCPM -

Update buer status

- Standard CCPM -

Update buer status

- Standard CCPM -

Update buer status

- Standard CCPM -
Take recovery acGons as required
Before a recovery acGon is taken

- Standard CCPM -
Take recovery acGons as required
AHer a recovery acGon is taken

Overview of Agile CCPM
CCPM
Standard Agile
Procedure in planning Modied Network
Add tasks and dependencies ConstrucGon Process
Level resources Feature
Insert buers
Procedure in execuGon Modied Buer
Execute tasks and report RDU Management Method
Update buer status
Flow of Modified Network
Construction Process
Car Drive (The process is similar to a long drive)

Where to Go? Set the goal/purpose of the drive
How Far? Get the distance to the goal
EsGmate Gme required according to

How Long?
the distance and the average velocity
ETA? Get the esGmated Gme of arrival

Flow of Modified Network
Construction Process (cont.)
Car Drive Agile CCPM (The process is similar to a long drive)

Where to Go? Value Set the Value of the project
Select features for the project from
the feature list unGl the Value is
How Far? Size saGsed, and calculate the Size
Calculate the project DuraGon
How Long? DuraGon according to the Size of features
and the iniGal planned velocity
ETA? Due Date

Feature
Set the Due Date (staggering)
Size Velocity
DuraGon
Value 2016 TOCICO. All Rights Reserved.
Procedure for Network Construction
Process in Agile CCPM
A network is developed from a Feature List

The structure of resulGng network can be very
simple, and is necessary and sucient for performing
the Modied Buer Management Method
Task(s) may represent mulGple features (even all
features) and are referred to as the Mother Task
Feature
Mother Task

Process in Agile CCPM (cont.)
No Feature Size A Feature List is prepared/

.
maintained for a product/
1
2
F001
F002
8
5
service prior to creaGng
3 F003 No8 Feature Size the network of a project
.3
4 F004
5 F005 1313 F013 13
Features are described in
6 F006 143 F014 5
user stories
7 F007 155 F015 8 Features are sorted in
8 F008 13
25 F025 13
approximate order based
9 F009
10 F010
8
26
5 F026 3 on value/importance for
11 F011 27
8 F027 5 the product/service
12 F012 28
5 F028 8
The relaGve size of each
feature is esGmated
29 F029 3
30 F030 13
31 F031 13
32 F032 5

.
1
2
F001
F002
8
5
.3
4 F004
5 F005 1313 F013 13
6 F006 143
user stories
As a pipeline manager, I want to display
F014 5
8 F008 13
25 F025 13
a mulG-project fever chart, because it
9 F009 8
on value/importance for
10 F010
11 F011
enables us to see the health of whole
26
5
27
8
F026
F027
3
5 the product/service
12 F012 5 pipeline and tells us which project
28 F028 8
feature is esGmated
29 F029 3
30 F030 needs help at a glance.

13
31 F031 13
32 F032 5

.
1
2
F001
F002
8
5
.3
4 F004
5 F005 1313 F013 13
6 F006 143 F014 5
user stories
8 F008 13
25 F025 13
9 F009
10 F010
8
26
5 F026 3 on value/importance for
11 F011 27
8 F027 5 the product/service
12 F012 28
5 F028 8
feature is esGmated
29 F029 3
30 F030 13
31 F031 13
32 F032 5
No Feature Size
.
1 F001 8
Set the Value of the project 2

3
F002
F003 No
5
8 Feature Size
4 F004 . 3
5 F005 13 13 F013 13
Select features for the 6 F006 14 3 F014 5

7 F007 15 5 F015 8
project from the feature list 8 F008

25 8
13
F025 13
9 F009
unGl the Value is saGsed 10 F010

26
27
5
F026
F027
3
5
11 F011 8
28 F028 8
12 F012 5
Set a scope buer 29
30
F029
F030 13
3
31 F031 13
32 F032 5
When the feature list consists of similar features

(requires the same type of skill to execute)
Total story points of all features
as the Size of the project
Calculate the DuraGon of the iniGal
task bar represenGng all features by
dividing the Size by the IniGal ex. 220 [sp]
Planned Velocity
ex. 220 [sp] / 2 [sp/d] = 110 [d]

When the feature list consists of similar features

(requires the same type of skill to execute)
Convert the iniGal task bar to a CriGcal

Chain schedule consisGng of a Mother
Task and a Project Buer
Mother Task Project Buer

When the feature list consists of dierent types of

features (requires dierent skills to execute)
Make groups of features

by type (or based on some #1
other rule), and total the #2 #1
story points of each group #1
#2
#2
#1
ex. Group #1 : 140 [sp]
Group #2 : 80 [sp] ex. 220 [sp]

Calculate the DuraGon of the iniGal

task bar for each group by dividing the
Size by the IniGal Planned Velocity
ex. Group #1 : 140 [sp] / 2 [sp/d] = 70 [d]
ex. Group #2 : 80 [sp] / 2 [sp/d] = 40 [d]


Convert the iniGal

task bars to a
CriGcal Chain Mother Task #1 PB
schedule consisGng
of Mother Tasks and FB
Mother Task #2
Buers 2016 TOCICO. All Rights Reserved.
When in a mulG-project environment,

an integraGon phase is specied and
staggering is performed in the same
way as with standard CCPM

Tasks represenGng each feature(*) will be

broken out from the Mother Task(**) and
will be executed during project execuGon
Mother Task
Task to execute next

*This doesnt necessarily mean tasks and features always have a
one-for-one relaGonship
**Technically, VBE and VBBM can be accomplished with a single
Mother Task, without feature breakdown through project execuGon
Tips and Examples for Network
Feature List
A feature list is prepared
The iniGal task bar is created

from the feature list
The iniGal task bar is

converted to a CriGcal Chain
schedule which consist of IniGal Task Bar
mother task(s) and buer(s)
Mother Task
A next task is broken out
from the mother task 2016 TOCICO. All Rights Reserved.
Next Task
Feature List


Tip #1: How to
Make Planning
Poker Successful
Mother Task
Next Task
Feature List
Tip #2: Buer Sizing and Velocity
Based EsGmaGon in Agile CCPM

Mother Task
Next Task
Feature List

Tip #3: Available Resources and
Velocity Based EsGmaGon
Mother Task
Next Task
Feature List

Example #1: How Tasks are
Broken Out from the Mother Task
Mother Task
Next Task
Feature List


Tip #1: How to
Make Planning
Poker Successful
Mother Task
Next Task
Tip #1: How to Make Planning
Poker Successful
Planning poker is a pracGcal and

consensus-based technique for
esGmaGng the relaGve size of
3 5
8
features, while intuiGon among
members is fully uGlized.
1. EsGmate by playing numbered
cards face-down on the table,
instead of speaking them aloud
2. The cards are revealed, and the
esGmates are then discussed
h"p://en.wikipedia.org/wiki/Planning_poker
Poker Successful (cont.)
Play with a feeling that you are creaGng groups of

features by RelaGve Size, instead of esGmaGng
each feature as a specic numerical value
it is beZer to be approximately right than to
be precisely wrong 2
5? 8?
3 5
8? 13? 2? 3?
If it is your rst Gme and you are struggling to

use Planning Poker, it is recommended you:
1. Find an easy enough feature and set its size as 1
2. EsGmate remaining features vs. easier ones, by
comparison to the rst/preceding features
1 2
When there is a big gap in esGmaGon among

members, the following can help you nd out
what is causing the gap
1. Find both the smallest and the largest cards
2. Ask for a discussion between the players who
played the smallest and the largest cards
Since, it seems
that most of 5 5
parts can be 1
1
duplicated smallest 8 Because there

easily... largest are many parts...
Feature List
Tip #2: Buer Sizing and Velocity
Based EsGmaGon in Agile CCPM

Mother Task
Next Task
Tip #2: Buffer Sizing and Velocity
Based Estimation in Agile CCPM
In Agile CCPM, task duraGons are

recognized as something in between
Aggressive But Possible(ABP : 50% chance)
and Highly Possible(HP : 90% chance)
They are calculated by dividing Story Points
of completed features by the Actual Velocity
obtained from the past results, including
both best and worst cases
Tip #2: Buffer Sizing and Velocity Based
Estimation in Agile CCPM (cont.)
Pre CCPM DuraGon

Our experience has shown
that if task duraGon is treated HP Method
Too Short
by the HP Method, the
resulGng project period
esGmates are too short
If task duraGon is treated by the
ABP Method, the resulGng ABP Method
project period esGmates are too long Too Long
Due dates need to be calculated in-between,

by a certain simple method
Tip #2: Buffer Sizing and Velocity Based
Estimation in Agile CCPM (cont.)
The 1/3 rule is applied by Pre CCPM DuraGon

default for buer sizing and HP Method
the Velocity Based EsGmaGon Too Short
This can be done using the SP / V (Agile CCPM)

following formulas [33% is set ED ED
to Cb (Buer Coecient)]
67% 33%
Buer Part : ED = SP / V x Cb
= SP / V x 33% ABP Method
Too Long
Leg Part : ED = SP / V x (1 - Cb)
= SP / V x 67%
*To simplify the explanaGon, a short version of the formula ED = SP /
V (Cb is omiZed) is applied for the Velocity Based EsGmaGon in this
presentaGon
Feature List

Tip #3: Available Resources
and Velocity Based EsGmaGon
Mother Task
Next Task
Velocity Based Estimation
IniGally, there is a single Mother Task (100 [sp])

There are 3 resources X1, X2 and Y
available for this project
A task (3 [sp]) is broken out from the Mother
Task and the size of the Mother Task is
decreased to 97 [sp] as a result
Mother Task 1 [sp/d]
X1
Next Task 100 [sp] 2 [sp/d]
X2
3 [sp/d]
3 [sp] 97 [sp]
2016 TOCICO. All Rights Reserved. Y
Velocity Based Estimation - Case #1
1
Here only X1 is available
1 1
ED = 3 / 1 = 3 [d] ED = 97 / 1 = 97 [d]
Next Task Mother Task
67% 33%
1/3 rule
3 / 1 x 67% = 2 [d] 97 / 1 x 67% 65 [d]
1-Cb 1-Cb
*To be precise, the formula should be ED = SP / V x (1 Cb),
but the short version ED = SP / V is applied in this presentaGon
1 1
Here two X1s are available
1 1
1 1
ED = 3 / 2 = 1.5 [d] ED = 97 / 2 = 48.5 [d]

1 2
2
Here X1 and X2
are available (X1 and X2
ED = 3 / 2 = 1.5 [d] are the same in skill type,
and are dierent in velocity)
2 2
1 1
ED = 3 / 3 = 1 [d] ED = 97 / 3 32 [d]
1 3
Here X1 and Y are available
Velocity of Y : 3 [sp/d]
Resource Y
90 [sp]
Mother Task for Y
Feature
Velocity of X1 : 1 [sp/d]
Resource X1
10 [sp]
Mother Task for X1

Tip #3: Available Resources and Velocity
Based Estimation - Case #4 (cont.)
Here X1 and Y are available

3 3
ED = 3 / 3 = 1 [d] ED = 87 / 3 = 29 [d]
3 [sp] 87 [sp]
2 [sp] 8 [sp]
1
1

ED = 2 / 1 = 2 [d] ED = 8 / 1 = 8 [d]
Tip #3: Available Resources and Velocity
Based Estimation - All Cases on a Page
ED = 97 / 1 = 97 [d]
Case #1 1 1
Only a single X1 is available ED = 3 / 1 = 3 [d]
ED = 97 / 2 = 48.5 [d]
Case #2 1 1 1 1
Two X1s are available ED = 3 / 2 = 1.5 [d]
Case #3 2
2
ED = 3 / 2 = 1.5 [d] 1
X1 and X2
are available 2 ED = 97 / 3 32 [d]
1
ED = 3 / 3 = 1 [d]
ED = 87 / 3 = 29 [d]
Case #4 3 3
X1 and Y are available ED = 3 / 3 = 1 [d]
1
ED = 8 / 1 = 8 [d]
1

ED = 2 / 1 = 2 [d]
Feature List

Mother Task
Next Task
At the kick-o of the project
At the end of the project

Example #1: How Tasks are Broken
Out from the Mother Task (cont.)
Feature
At the kick-o of a project, the network
has only small number of Mother Tasks
represenGng all features for the project
Mother Task #1
Mother Task #2
Mother Task #3
IntegraGon Phase
(not a Mother Task)
The integraGon phase is specied so that the project can be staggered in the
pipeline by the Virtual Drum, but is not considered a Mother Task in our case
IniGally, no task is broken

out from the mother task
Mother Task
Below, 4 tasks are
broken out from
the mother task,
the rst 2 tasks are
iniGated, and are
sGll in execuGon
The rst 2 tasks are

completed and the
next 2 tasks are
iniGated
Another task is
broken out from the
mother task just
before the preceding
task is completed 2016 TOCICO. All Rights Reserved.
At the kick-o of the project
Tasks are broken out from the mother

task and are executed in a similar
fashion unGl the project completes
At the end of the project

Overview of Agile CCPM
CCPM
Standard Agile
Procedure in planning Modied Network
Add tasks and dependencies ConstrucGon Process
Level resources Feature
Insert buers
Procedure in execuGon Modied Buer
Execute tasks and report RDU Management Method
Update buer status
Flow of the Modified Buffer
Management Method
(The process is similar to a long drive)
Car Drive EsGmate the arrival Gme according to

the distance to the goal and the
ETA? velocity which is obtained by travel
distance and drive Gme at the moment
Change the route as required so
that the iniGal ETA can be met
Re-rouGng
ConGnue the same procedure unGl
the car will get to the goal
Flow of the Modified Buffer
Management Method (cont.)
(The process is similar to a long drive)
Car Drive Execute tasks and update project status

Agile CCPM
according to the SPs of remaining
Project features, and the velocity which is
ETA? obtained by the SPs of completed features
Status?
and development Gme at the moment
Take recovery acGon as required so
Recovery
Re-rouGng that the due date can be met
AcGon
ConGnue the same procedure unGl
the project is completed
Procedure for Buffer Management in
Agile CCPM
The procedure is referred to as the Velocity-Based

Buer Management(VBBM)
EsGmated duraGon (ED) of the Mother Task is
adjusted by the Velocity Based EsGmaGon(VBE)
according to the following formulas:
Completed SP Remaining SP
Velocity = ED =
Elapsed Time Velocity
Velocity
Feature
Elapsed Time
Completed
Remaining
Mother Task
Completed Remaining
Agile CCPM (cont.)
Task Board
ToDo Doing Done
Lets take a look at the
concept and the procedure
through a Task Board so
that we can see it more
intuiGvely and simply
Completed SP Remaining SP
Velocity = ED =
Velocity
Feature
Elapsed Time
Completed
Remaining
Mother Task
Completed Remaining
Agile CCPM (cont.)
Task Board
ToDo Doing Done Day 4
4
Mother Task
Remaining Completed
Velocity
25 [d]
45 [sp] 5 [sp] 8 [sp] 2 [sp/d]
Completed SP Elapsed Time Remaining SP
8 [sp]
Completed SP 50 [sp]
Remaining SP
Velocity = ED =
4 [d]
Elapsed Time 2 [sp/d]
Velocity
= 2
2 [sp/d] 2016 TOCICO. All Rights Reserved. = 25 [d]
Agile CCPM (cont.)
ToDo Doing Done

IniGally, there is only a
Mother Task represenGng all
target features for the project.
Its length is calculated based
on the IniGal Planned
Velocity
Mother Task
As-of Date

Agile CCPM (cont.)
The 1st task (Task 1),

ToDo Doing Done
corresponding to the highest

priority feature is broken out
from the Mother Task
Task 1
Mother Task
When a task is broken out, the duraGon

of the Mother Task is adjusted as well
Agile CCPM (cont.)
ToDo Done
Task 1 is started and
Doing
remaining duraGon (RDU) is

reported in the same way as
in standard CCPM
RDU
Mother Task
Task 1
The project buer is consumed in

the same way as in standard CCPM
Agile CCPM (cont.)
ToDo Doing Done
The 2nd task (Task 2) for

the next highest priority
feature is broken out from
the Mother Task
Task 2
Mother Task
Task 1

Agile CCPM (cont.)
ToDo Doing Done
Task 2 is started aHer

Task 1 is completed, and
the RDU of Task 2 is
reported
RDU
Task 1 Task 2 Mother Task
Project buer is consumed

Agile CCPM (cont.)
ToDo Doing Done
The 3rd task (Task 3) for

the next highest priority
feature is broken out from
the Mother Task
Task 3
Task 1 Mother Task
Task 2

Agile CCPM (cont.)
ToDo Doing Done
Task 3 is started aHer

Task 2 is completed, and
the RDU of Task 3 is
reported
RDU
Task 1 Task 3 Mother Task
Task 2
Project buer is consumed

Agile CCPM (cont.)
ToDo Doing Done

The 4th task (Task 4) for the
next highest priority feature is
broken out from the Mother
Task
Task 4
Task 1 Mother Task
Task 2 Task 3

Agile CCPM (cont.)
ToDo Doing Done
Task 4 is started aHer Task 3 is

completed, and the RDU of Task 4 is
reported
It is indicated that the Actual
Velocity is decreasing at this stage
Task 1 Task 3 Task 4 Mother Task
Task 2
RDU
Actual Velocity

Elapsed Time
Agile CCPM (cont.)
The duraGon of the Mother Task is adjusted

by the Velocity Based EsGmaGon,
according to the Actual Velocity
Task 2
Remaining SP Actual Velocity
ED =
Velocity
Elapsed Time
Agile CCPM (cont.)
For this reason, we refer to this as

Velocity Based Buer Management
The duraGon of the Mother Task is
adjusted by Velocity Based EsGmaGon,
according to the Actual Velocity
Task 2
The project buer is consumed by Actual Velocity
both the RDU of Task 4 and the

duraGon of the adjusted Mother Task
Elapsed Time
Agile CCPM (cont.)
Velocity Based EsGmaGon can be applied

even if the Velocity doesnt change, when it
is recognized that the story points of
features have changed (for any reason), so
the Mother Task shows relevant duraGon
Task 2
Actual Velocity
Remaining SP
ED =
Velocity
Elapsed Time
Agile CCPM (cont.)
No. Feature Size Remaining SP

1 F001 8 ED =
Velocity
25 F025 13
26 F026 3
Scope Buer
27
28
F027
F028
5
8
Velocity Based EsGmaGon
29 F029 3 is also applied when the
30 F030 13
Scope Buer is invoked
Mother Task

Agile CCPM (cont.)
No. Feature Size Remaining SP

1 F001 8 ED =
Velocity
25 F025 13
26 F026 3 Remaining SPs decrease by
Scope Buer
27
28
F027
F028
5
8
cuxng some features in
29 F029 3 the scope buer
30 F030 13
EsGmated duraGon of the Mother Task

is reduced and buer status
is recovered as a result
Mother Task

Tips and Examples for Buffer
Management in Agile CCPM 2016 TOCICO International Conference
Next Task
The next task is broken out from the mother task
Mother Task
The next task is executed and the RDU RDU
is reported
Actual velocity is calculated and the Velocity
applied velocity is updated as required Elapsed Time
The mother task is adjusted by the

latest applied velocity as required
Project status is updated according to
Feature List
both the RDU of the current task and
the mother task
Scope buer is invoked as required 2016 TOCICO. All Rights Reserved.
Next Task
Mother Task
is reported

Tip #4: How Actual

Feature List
the mother task Velocity is recognized
Tip #5: How to Specify the
Management in Agile CCPM
Velocity Applied to Velocity
Next Task
Based EsGmaGon
Mother Task
is reported

Feature List
the mother task
Scope buer is invoked as required
Next Task
Mother Task
is reported
Tip #6: Using a Scope Buer or
Expanding the Project Buer?


Feature List
the mother task
Example #2: How VBBM Works
Next Task
Mother Task
is reported

Feature List
the mother task
Next Task
Mother Task
is reported

Tip #4: How Actual

Feature List
the mother task Velocity is recognized
Tip #4: How Actual Velocity is
recognized
Feature List At the kick-o of a project, all

ToDo Doing Done tasks are placed in the ToDo
lane (not started) and the Actual
Velocity is recognized as 0

recognized (cont.)
Feature List A few days later, no task is yet

ToDo Doing Done completed, although some tasks
are in execuGon (placed in the
Doing lane), and the Actual
Velocity is sGll recognized as 0

recognized (cont.)
Feature List When the rst task is completed

ToDo Doing Done (and placed in the Done lane),
the Actual Velocity can be
calculated according to the size
of the task and elapsed Gme

recognized (cont.)
Feature List A few weeks later, 2 more tasks

ToDo Doing Done have been completed, but they
have taken longer than the rst
task, and the Actual Velocity is
decreased

recognized (cont.)
Feature List Another a few weeks later,

ToDo Doing Done some more tasks have
completed faster, and the
Actual Velocity has slightly
recovered

Velocity Applied to Velocity
Next Task
Based EsGmaGon
Mother Task
is reported

Feature List
the mother task
Scope buer is invoked as required
Velocity Applied to VBE
To be precise, EsGmated DuraGon is calculated

according to the Applied Velocity instead of the
IniGal Planned Velocity or the Actual Velocity
Actual Velocity
Applied Velocity
Remaining SP
IniGal Planned Velocity ED =
Velocity
Applied
Velocity
Velocity Applied to VBE (cont.)
At the beginning of this project, the IniGal Planned

Velocity (1.5 [sp/d]) was used as the Applied
Velocity, even as the Actual Velocity was showing
a good result

The IniGal Planned Velocity was sGll used as

the Applied Velocity since the Actual
Velocity had been uctuaGng
Actual Velocity is unstable and can

uctuate widely in the early stages
of a project (the same logic as when
velocity is measured in a car drive)
When it seemed that Actual Velocity had stabilized,

IniGal Planned Velocity was sGll maintained for a liZle
while, because Actual Velocity stayed close to IniGal
Planned Velocity. But later Actual Velocity increased
even more

It was decided that the Applied Velocity

should be increased to 1.7 [sp/d] (as
indicated by the trend of Actual Velocity)

Next Task
Mother Task
is reported
Tip #6: Using a Scope Buer or
Expanding the Project Buer?


Feature List
the mother task
Tip #6: Using a Scope Buffer or
Expanding the Project Buffer?
Why a Scope Buer? Feature
Scope Buer without &

extending Project Buer?
Feature
Extending Project Buer
&
without Scope Buer?
Using a Scope Buer instead of extending the
Project Buer is benecial when you need to
avoid the following:
Longer projects and resulGng later compleGon dates
Increase in WIP
Next Task
Mother Task
is reported

Feature List
the mother task
- % Chain Complete : 5% -
The project gets started and the IniGal

Planned Velocity is used as the
Applied Velocity

The IniGal Planned Velocity is sGll used as the

Applied Velocity, even while the Actual Velocity is
gexng beZer, since developers skill for the new
technologies is increasing
Buer status is gexng worse because there are a
lot of addiGonal requirements by stakeholders
Remaining SP
ED =
Velocity
- % Chain Complete : 35% - (cont.)
AHer VBE is applied

Remaining SP
Mother Task ED =
Velocity
Before VBE is applied

Mother Task

The IniGal Planned Velocity is sGll used as the

Applied Velocity since it is almost the same as the
Actual Velocity
The size of features keeps increasing at a higher
pace against the increase of the prociency
among developers
Remaining SP
ED =
Velocity
- % Chain Complete : 45% - (cont.)
Buer status is deterioraGng sharply

because developers are struggling
to complete the toughest features
in this project
(like reverse running a on moving walk!)
Remaining SP
ED =
Velocity
The 80% mark is achieved just before iniGaGng

the integraGon phase (QA phase)
Buer status is sGll gexng worse even as a high
level of velocity is maintained, since some small
bugs are found and need to be xed before QA
Remaining SP
ED =
Velocity
The project completes on Gme

(only 24 min to the due date!)

Conclusions
The project was challenging, because:

it was a Major Upgrade of exisGng SW product
it required DisconGnuous InnovaGon and
state-of-the-art technologies
its environment was recognized as Complex
DisconGnuous
InnovaGon

Conclusions (cont.)
Although threatening situaGons were

experienced several Gmes, the project
completed on the due date
(with only 24 min remaining!)
Relevant recovery acGons
were taken in a Gmely manner
based on Velocity Based
Buer Management (VBBM)
VBBM Works! 2016 TOCICO. All Rights Reserved.
Conclusions (cont.)
100
DDP Trend
90 Before standard CCPM was introduced in 2004,
80 our due dates were almost always missed and
70 DDP was unknown. Around 2005 to Project M
60 2009, MulGple Single Project CCPM

Project N
Project O
50 was introduced and DDP increased Project P
Project Q
40
to 20% - 30% Project R
30 Project S
Project T
20 Project U
10 Single Project CCPM Project V
0
03 04 05 06 07 08 09 10 11 12 13 14 15 16
Conclusions (cont.)
100
DDP Trend
90 Around the middle of 2009, some pracGces of
80 Agile methods were started to be applied so
70 that the pipeline could be managed more
60 intuiGvely and simply, and DDP was a bit
50 beZer
40
30 Single Project CCPM
20 + Some Agile PracGces
0
03 04 05 06 07 08 09 10 11 12 13 14 15 16
Conclusions (cont.)
100
DDP Trend
90 Around the end of 2010,
80 MulG Project CCPM was
70 applied and DDP improved
60 rapidly up to 90% MulG-Project CCPM
50
40
0
03 04 05 06 07 08 09 10 11 12 13 14 15 16
Conclusions (cont.)
100
DDP Trend
90 Around 2013, Agile MulG-Project CCPM
80 CCPM was applied to + Agile CCPM (5%)
70 5% of projects and DDP
60 moved over 90% MulG-Project CCPM
50
40
0
03 04 05 06 07 08 09 10 11 12 13 14 15 16
Conclusions (cont.)
100
DDP Trend Agile CCPM
90 In recent years, Agile CCPM MulG-Project CCPM Project A
has been uGlized even more + Agile CCPM (5%)

Project B
80 Project C
70 and 100% DDP is maintained Project D
60 Project E
Project M
Project N
MulG-Project CCPM
Project F
50 Project O Project G
40 Project P
Project H
30
Project Q
Project R
Single Project CCPM
Project I
20
Project S + Some Agile PracGces
Project J
Project T Project K

Project U
Project V
Project L
0
03 04 05 06 07 08 09 10 11 12 13 14 15 16
Conclusions (cont.)
100
DDP Trend Agile CCPM
90 Currently, in our pipeline, 2/3rds of Project A
80 our projects are managed by Project B
Project C
70 Standard CCPM and 1/3 by Agile Project D
60 CCPM (33% in terms of the number, Project E
Project F
50 35% in terms of the project duraGon) Project G
40 Project H
30
100% DDP for years Project I
Project J
20
10 Agile CCPM Works!! Project K
Project L
0
03 04 05 06 07 08 09 10 11 12 13 14 15 16
Conclusions (cont.)
Agile CCPM is an enhancement

of CCPM. Although we use slightly
dierent techniques in certain
situaGons, none of the fundamental
rules or benets of CCPM are
sacriced, and it is truly CCPM

Conclusions (cont.)
Which means that in a soHware

development environment,
CCPM enables us to successfully
complete challenging projects, and
maintain 100% DDP for years

Conclusions (cont.)
If you idenGfy with our approach,

believe in the power of CCPM and
believe that there is sGll more
room for maximizing the ow of
the system, I strongly recommend
you to try Agile CCPM
Thank You
I hope Agile CCPM will

enable a lot of success for
you in the near future!
ujigawa@beingcorp.co.jp
www.linkedin.com/in/k1ujigawa
About Koichi Ujigawa
Currently leading a soHware engineering div. at Being Co., Ltd. to develop TOC soluGons
that help both TOC consultants and end users implement TOC at the end users' site.
In 1993, joined IHI CorporaGon in Japan and worked for the shipbuilding division for about
14 years. Engaged in soHware development for various in-house computer systems, such
as a Material Control System, Advanced Planning System, CAD for hull structure, etc.
Involved in various systems' projects for the company, and contributed with strong commitment to
successful implementaGon of Kaizen acGviGes, including producGvity improvement of knowledge workers
and introducGon of TPS (Toyota ProducGon System) to Gemba (manufacturing workplace).

During the course of such acGviGes and conGnuous eorts on Kaizen, encountered TOC in 2001, then was
challenged to make various POOGI plans based on the Thinking Process, implemenGng both DBR for
producGon lines and CCPM for the shipbuilding design department.

As the consequence of the conGnuing pursuit of TOC, joined Being Co., Ltd. in 2007.

As new knowledge, provided presentaGons of Agile CCPM at 2012 2014 TOCICO conferences.

Tocico2016 Agile CCPM

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tocico2016 Agile CCPM

Enviado por

Direitos autorais:

Formatos disponíveis

2016 TOCICO International Conference

How Agile CCPM enables us to

The project was challenging, because:

There are several modaliGes for recognizing a

2016 TOCICO. All Rights Reserved.

In the Complex environment, Cause and Eect

2016 TOCICO. All Rights Reserved.

The project was challenging, because its

2016 TOCICO. All Rights Reserved.

We believe that the following percepGons

We knew that more adaptability,

Agile CCPM is an enhancement of

*Conceptually, this can be applied to other environments

All the benets and aZributes of CCPM are

Although we use slightly dierent

2016 TOCICO. All Rights Reserved.

Add tasks and dependencies

2016 TOCICO. All Rights Reserved.

2016 TOCICO. All Rights Reserved.

IdenGfy the CriGcal Chain

2016 TOCICO. All Rights Reserved.

Insert the project buer

2016 TOCICO. All Rights Reserved.

Insert feeding buers

2016 TOCICO. All Rights Reserved.

Execute tasks and report RDU

2016 TOCICO. All Rights Reserved.

Execute tasks and report RDU

2016 TOCICO. All Rights Reserved.

Execute tasks and report RDU

2016 TOCICO. All Rights Reserved.

Execute tasks and report RDU

2016 TOCICO. All Rights Reserved.

Take recovery acGons as required

Before a recovery acGon is taken

Take recovery acGons as required

AHer a recovery acGon is taken

Car Drive (The process is similar to a long drive)

How Far? Get the distance to the goal

EsGmate Gme required according to

ETA? Get the esGmated Gme of arrival

2016 TOCICO. All Rights Reserved.

Car Drive Agile CCPM (The process is similar to a long drive)

ETA? Due Date

A network is developed from a Feature List

2016 TOCICO. All Rights Reserved.

No Feature Size A Feature List is prepared/

No Feature Size A Feature List is prepared/

30 F030 needs help at a glance.

No Feature Size A Feature List is prepared/

Set the Value of the project 2

Select features for the 6 F006 14 3 F014 5

project from the feature list 8 F008

unGl the Value is saGsed 10 F010

When the feature list consists of similar features

ex. 220 [sp] / 2 [sp/d] = 110 [d]

When the feature list consists of similar features

Convert the iniGal task bar to a CriGcal

Mother Task Project Buer

When the feature list consists of dierent types of

Make groups of features

When the feature list consists of dierent types of

Calculate the DuraGon of the iniGal