10 - andy watt_ john muncaster_21 tocpa_uk_11 november 2015_for web

21st International Conference of the

TOC Practitioners Alliance - TOCPAwww.tocpractice.com 11 November 2015, UK

Critical Chain and Agile –

Working Together in a Software

Environment

Andy Watt & John Muncaster, Goldratt UK

11 November, 2015

Your logo


TOC Practitioners Alliance - TOCPAwww.tocpractice.com

Andy Watt & John

Muncaster

1985 – 2000: Engineer and Senior Manager in DefenceManufacturer

2000: joined Goldratt

2004 – present: Managing Director Goldratt UK

2007 – 2009: Kitchons (Installation and Service)

2011: Formed RopeWeaver Business Systems

2013: Purchased Tenon [email protected]

07980 637073

1985 – 1994: Engineer and Manager in Defence Manufacturer

1994 – 96: SBAC Lean Consultant

96 – 2001: Phase Devices Operations Manager

2001 – 2005: BE Aerospace Operations Manager [email protected] 451177

Your logo



The problem we face…

• Many software environments have invested heavily in Agile

(time and money), have buy-in to it and achieved some success.

However…..

• Most still do not meet all of the project commitments (on-time,

to scope or budget)

But…

• Most don’t want to lose the success they have gained, the buy-

in of the people, or investment made by stopping and doing

something demanding a fresh start – its too risky

Your logo



The Common Ground

Both Agile and Critical Chain aim to:

• Complete more projects without increasing resources or

decreasing scope

• Reduce bad multi-tasking by focusing on fewer open

activities and rapidly completing these activities before

releasing more work

• Reduce the lead-time to complete projects

Your logo



Different Assumptions

Agile Critical Chain

Projects are built of modules and these modules can be completed in any sequence

There is a plan sequencing the delivery of the project with robust cause and effect logic between tasks

The organisation makes financial gain as soon as any software module is completed

The project has a fixed due date and the project is of little or no financial value to the organisation until it is complete

Projects are delivered faster if all resources can be kept busy all of the time

It is not possible to keep all resources fully utilised all of the time

Tasks are hours with estimated durationbased on touch time (booked hours) assuming no “losses”

Tasks are days with estimated duration based on elapsed time (calendar days)

Progress measured by task burn down Progress measured by buffer consumption

Time duration (Sprint) is fixed and workcontent flexes to fit the Sprint

Work Content is fixed and time flexes to accommodate the work

Your logo



Agile Overview

• Project broken down into “Stories” (a piece of functionality

that can be delivered)

• Stories are broken down into discreet detailed tasks with

hours assigned to each task

• New tasks are released only when a current task is completed

• Regular drumbeat of Sprints where progress of content

delivery is reviewed

• Project progress is measured on burn down of tasks

completed

Your logo



Estimating task duration

• Agile estimates tend to focus on coding only and on effort (bookable / chargeable

hours)

• Dwell time, queue time and rework can be unaccounted for

• Development of a software module generally comprises the following:

Scope….Code….Peer review….Rework….Documentation….Release

Scope Code Queue Review QueueRe-work

Queue Doc Queue

• Estimates in planning made for green tasks, sometimes blue tasks but seldom

for orange queue tasks

• These tasks are the biggest proportion of time

Your logo



What to keep from Agile

• For Individual resources:

– Minimising multi-tasking

– Choke Release of tasks to individuals

– Work as fast as possible until completion

• Sprint duration of 10-20 days

• Work Content of a Sprint is detailed just prior to release

Your logo



What to STOP in Agile and

ADD from Critical Chain

STOP

• Fixed duration Sprints

• Pushing work not complete into the next Sprint

• Reviewing progress by task burndown

• Potential for Parkinson’s from fixed durations

ADD

• Signal to take recovery actions earlier

– Daily updates of remaining Sprint duration

• Fixed worked content with flexible completion time

• High level sequence of the plan

– Trying to push high risk activities to the front of the project

• Task duration estimates include all dwell, review and documentation

• Uncertainty is managed with buffers of time

Your logo



Define “Drumbeat”

Functionality

• First step is to identify stories; defining functionality to be

delivered in frequent steps

– Entire programme broken down into interim deliverables,

Sprints, that require approximately 4 weeks of duration

– Sequence deliverables ensuring:

• Project risk is minimised (force it to the front)

• Functionality is delivered to support the development

of future functionality

Your logo



Build Software Network

1. Start with sequence of

functionality to be

delivered

2. Describe the activity

required to deliver the

functionality.

– Make sure the activity

describes all activities

required to complete

definition of done

3. Just in Time - Elaborate

the Scope to the team

instructions.

Do 1

Do 2

Do 3

Do 4

Do 5

Scope 1

Scope 2

Scope 3

Scope 4

Scope 5

Do 1

Do 2

Do 3

Do 4

Do 5

1

2

3

Note:

There may be scope and

resources available to run

more then 1 “do”

simultaneously.

The Critical Chain is used

to guide the Project leader

to the most important

activity.

The project leader and

team will have to make a

judgement as to how

many “Do” activities can

be managed concurrently.

Execution

Planning

Your logo



Synchronise Hardware

and Software Networks

• Identify the Sprints

• Identify the long lead activities

required to support sprints

• Define the tasks within the Sprints

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Your logo



Work Package Ownership

Task Description Assigned To Hours

Coding Fred 30

Code Review Review Board 5

Unit Testing Joe 10

Validation Mike 10

Defect Fix Fred 15

Sprint Task Management

Task Description Assigned To Remaining

Days

Code Complete Fred 15

Software Released Fred 12

Critical Chain Task Management

The detail of the task and the required touch

time is managed in Sprint tracking system.• This give a good indication of work content and

hours required

Detail rolled up and reported into Critical

Chain (Concerto) as number of days until the

rolled up task will be complete• someone responsible for collecting progress

from Sprint task owners and reporting rolled up

task completion

• Gives better indicator whether the project is

likely to finish on time

• Focuses on ensuring all Sprint task

management tasks are completed in the

correct sequence to allow the project to flow

Your logo



Visibility & Quality of

Management Information

Task Level

Project Level

Senior Management Level

• Deliverables in danger• Where is work stuck• Focus areas for recovery• How much recovery

• Consolidated view• Visibility of blockages• Challenge & support recovery actions

PB

%

Consumed

Project Completion 100%

0

100

%PB

%

Consumed

Project Completion 100%

0

100

%

• Priorities• Released / active tasks• Full kit indication• Upcoming ‘hot potato’s’

Your logo



Application

• Initial trial in a large business developing software driven

physical products

• Good levels of buy-in to the process from software engineers

• Easier integration of software into hardware projects

• Much higher level of focus on the critical activities

• Much earlier warning of potential delay

– Enabling recovery actions to be taken

Your logo



Challenges

• Getting good duration of elapsed time

– Software engineers seem conditioned to estimate touch

time for code only

• Getting good estimates of remaining duration

• Getting ownership at the task manager level

10 - andy watt_ john muncaster_21 tocpa_uk_11 november 2015_for web

Documents

international conference

agile time

time flexes

completedthe project

project commitments

touch time booked hours

comagile overview project

estimated duration