Copyright © 1995-2014, Dennis J. FraileyReducing SW Cycle Time 1 Meeting Tight Software Schedules...

Reducing SW Cycle Time

Meeting Tight Software Schedules Through

Cycle Time Reduction

Dennis J. FraileyRetired Principal Fellow, Raytheon Company

Sole Proprietor, DJF COFrailey@ACM.ORG

Outline

Background - Why Cycle Time is Important– Cycle Time Reduction Issues and

Examples– Defining Cycle Time

Three Fundamental Problems Typical Causes Spotting the Symptoms and

Opportunities Fixing the Problems - Five Principles A Few Lessons Learned

Why Cycle Time is Important

Yes, Sir!Right Away,

I needthat software

no later than next week! Why is it taking so long?

But we’re already working

overtime!

We’ll work overtime to get

it out, sir.

Cycle time is the time required to execute all activities in a process, including actual processing time AND all waiting time

Definition of Cycle Time

Consider a “10 minute” oil change

Short Cycle Time Gives You a Competitive Edge

You sell your software while the competitor is still completing theirs

You start the next software product while the competitor is still completing the current one

You lower your costs Or you can start development later in the

program cycle– More time to determine the requirements– And, once you start, you allow less time to

change requirements

How Can Cycle Time be Improved?

The following video illustrates how to improve cycle time

As you watch, think of ideas that might be applicable to software development

What did they do to reduce cycle time?

Some Lessons from the Cycle Time Video

What did they do?

Is there a software counterpart?

Things they did:+_%$#@&

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How do You Measure Cycle Time?

STATIC CYCLE TIME

The average of the actual cycle times (CT)experienced by some number (n) of products

CT1 + CT2 + CT3 + CT4 +...+ CTn

nCycle Time =

But this is not always easy to measure when many of the products are only partway through the process

… so we need a dynamic measure

Dynamic Cycle Time

Cycle Time = WIP (products being developed)

THROUGHPUT (products produced/unit time)

The total work in process divided by the throughput of the process

WIP = Work in Process For related background, see Gross and Harris, in reference list, p83.

Doing every process step faster? Working longer hours? Piling up work?

Faster!!!Faster!!!

How is Cycle Time Improved?

Improving the Process

Cycle Time Improvement Is …

Reducing the Critical Path

Eliminating Waits, Queues, Bottlenecks

Helping People work Smarter

Increased Cycles of Learning

Reengineering the Process

Three Fundamental Problems

Variability– Some parts of the process are starved while

other parts are producing excessive output– Performance becomes inconsistent and

unreliable– This is what causes traffic jams!

Complex Processes– More work to do than is necessary– More opportunities to make mistakes

Bottlenecks and Constraints– Things that slow everything down

Typical Causes ofCycle Time Problems

Variability Complexity Bottlenecks

MisplacedPriorities

IncompatibleTools

InefficientProcedures

PoorPlanning

Spotting the Symptoms and the Opportunities

Symptom: excess WIP or “work in process”

– work waiting to be done that is not being done -- waiting in queues instead

– something is holding up the process

Causes: limited capacity, bottlenecks, poor processes, poor execution, various barriers imposed by the organization

Cycle Time = WIP (products being developed)

THROUGHPUT (products produced/unit time)

Examples of Excessive WIPfor Software

Code waiting to be tested─ Not enough test equipment?─ Poor test planning?

Designs waiting to be coded

Specifications waiting to be inspected

Change requests waiting for approval

People waiting for the network to come up

… Hundreds more...

Other Symptoms ofCycle Time Problems

Long waits and queues High inventory levels Excessive overtime High levels of rework / scrap

Tickets -->Tickets -->

How long isthis line?

Reducing Rework - The Impact of Defects on Cycle Time

ProcessStep

Undetected

Defect

Several Steps

ProcessStep

Defect Detected

Doing it Over Again

ProcessStep

Undetected

Defect

Several Steps

ProcessStep

Defect Detected

Rework costs money and time

Look for Rework

REWORK is anything you do because you didn’t do it right the first time– debugging– correcting documentation– correcting designs– correcting requirements– retesting– responding to customer complaints

Isn’t Rework Inevitable?

SOME rework is necessary, but much of it is not

Total rework is a measure of process efficiency

You probably have a lot more rework than you think

Fixing the Problems --Five Principles of Cycle Time Improvement

Warning … some of these are counter-intuitive

Where are the Opportunities?

~30% of the improvement comes from technical changes

– Process changes

– Tool changes

– Changing rules and operations

Where are the Opportunities?

~70% of the improvement comes from organizational, cultural and environmental changes, such as

– Education

– Communication

– Management

– Teamwork

Principle #1

Don’t optimize only your local part of the process

Speeding up every step of the process will cost a lot and will not help as much as speeding up the bottlenecks

Beware of inappropriate reward systems!

Look at the Entire Process

Example Process – Pizza Shop

Pizza OvenPizza Oven

ToppingsToppings

CrustCrust

BoxBox

SlicerSlicer

DeliverDeliver

Take OrderTake Order Where could

the bottlenecks

Where could the

bottlenecks be?

Gain from Cycles of Learning

Changes are received and processed here ()

Sometimes it is better to do the job many times, in small chunks, than to do it all at

Principle #2

Ways to Implement the Cycles of Learning Principle

Try a new compiler or debugging tool on one module first to see how well it works– Then decide whether to use it on more

modules Write one module using the new language

– Then decide whether to use the new language on a larger scale

Take one subset of the features through the whole process flow first to work out the quirks

Test server performance using dummy data

Principle #3

Important when requirements change a lot or the process is new

The work to be done

Small batch principle

- allows for finding errors and requirements changes without large amounts of rework

Batch 1Rework

Batch 2Rework

Batch 3 Batch 4 Batch 5

Use Small Batches

Principle #4

– Lots of entrances and exits– Vehicles of different sizes

and speeds– Some drivers uncertain of

what they want to do– Lots of stoplights to

“control” the flow (mainly to prevent collisions)

– Note: streets are usually crowded

The typical process runs unevenly, like vehicles on a city street

Aim for Smooth Flow

The Ideal is Smooth Flow

The ideal process flows smoothly, like a train running on tracks

– Note: tracks are empty most of the time

What Prevents Smooth Flow?

Bottlenecks and constraints that lead to:

– Queues and waits

– Work in process

For example:– Work piling up– Machines or software not

being available– Excessive approval

requirements

– People pulled off projects– Excessive rework– Product stuck in test

Incoming work

Principle #5

Such as …– Shortening the longest step of the

process

– Shortening every step of the process

– Cutting the overhead without assessing the impact of the cut

Avoid the Naïve, Obvious and Wrong Solutions to Cycle Time Problems

Productivity is ...

The quality or state of being productive

Webster’s 9th New Collegiate Dictionary

Productive:Having the power of producing;

Yielding or furnishing results, benefits, or profits

Webster’s 9th New Collegiate Dictionary

Productivity is NOT being ...

Busy Industrious Virtuous

Productivity has to do with results (what and how much you produce), not with the means or

methods of production or the characteristics of the producer

Wealthy Hardworking etc.

Measuring Productivity

Productivity is usually measured in terms of how much you produce in relation to how much you invest

Productivity = Output

Input or Investment

Productivity Measures

Products produced per labor hour

Return on investment

Bushels of grain per acre of land

Modules tested per week

Requirements validated per day

A farmer who invents a new method of growing that doubles the output per acre would be more productive than a farmer

who works longer hours and doubles output per acre.

A Few Lessons Learned

Lesson Learned

Be Careful Whom you Reward Know the difference between busy and

productive Examine the value produced, not the

effort spent

Employee A•Works 8am – 9pm

Employee B•Works 8am – 5pm

• Produces 10 code units per month

• Produces 3 bugs per unit

• Produces 12 code units per month

• Produces 1.5 bugs per unit

Practitioners generally focus on their work and on what they THINK is happening rather than on what IS happening

– They tend not to see all of the waits, queues, etc. that they cause themselves

– Their perception of how they spend their time is generally incorrect

– They are too busy getting the job done to see how they might improve it

Lesson Learned

Independent Observers May See Problems and Opportunities the Best

Just as athletes rely on coaches, software engineers need to learn to trust in others to observe and help them do better

The Athletic Coach Analogy

Lesson Learned

Software Developers AreAccustomed to Improving Cycle Time

Think of your software development process as a large computer program that runs too slow. > How would you make it run faster?

Imagine how you would speed up a computer program …….

Then draw analogies to the software development process …

And improve the process the way you would improve a program

Summary

Background - Why Cycle Time is Important– Cycle Time Reduction Issues and

Examples– Defining Cycle Time

Three Fundamental Problems Typical Causes Spotting the Symptoms and

Opportunities Fixing the Problems - Five Principles A Few Lessons Learned

References

Deming, W. Edwards, Out of the Crisis, MIT Press, 1982.

Goldratt, Eliyahu M. & Jeff Cox, The Goal, (North River Press, 1984.) Also, Theory of Constraints, It’s Not Luck, and Critical Chain Management.

Gross and Harris, Fundamentals of Queueing Theory (Wiley).

Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1-56327-043-9.

Questions?Comments?

Copyright © 1995-2014, Dennis J. FraileyReducing SW Cycle Time 1 Meeting Tight Software Schedules...

Documents

January 20, 2000 CSE 7315 - SW Project Management / Chapter 10 – Measuring and Monitoring Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved

August 13, 2000 CSE 7315 - SW Project Management / Chapter 1 – Software Management Overview Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved

CSE 7315 - SW Project Management / Module 35 - Software Process Maturity Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M35 Slide

CSE 7315 - SW Project Management / Module 23 - Cycle Time Management and Negotiation Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M23

CSE 7315 - SW Project Management / Module 6 – Initial Planning Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved CSE7315M06 Slide 1 January

CSE 7315 - SW Project Management / Module 1: Process - the Framework of SW Eng Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M01

January 20, 2000 CSE 7315 - SW Project Management / Chapter 12 – Software Quality Engineering & Assurance Copyright © 1995-2000, Dennis J. Frailey, All

CSE 8314 - SW Metrics and Quality Engineering Copyright 1995-2001, Dennis J. Frailey, All Rights Reserved CSE8314M12 8/20/2001Slide 1 SMU CSE 8314

Computer Science in the Early Years Dennis J. Frailey Purdue MS CS 1968; PhD CS 1971

Copyright 2003-2009, Dennis J. Frailey Software Engineering Best Practices Dennis J. Frailey Frailey@ACM.ORG Things that make a big difference for real

Applying The CMMI/SPI In A Cost Controlled Environment Dennis J. Frailey

CSE 7315 - SW Project Management / Module 37 - Process Appraisal and Assessment Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M37

CSE 7315 - SW Project Management / Module 30 - Managing with Earned Value / Measurement Issues Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved

CSE 7315 - SW Project Management / Module 3 - Product Development Lifecycles Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M03 Slide

Copyright 2003-2013, Dennis J. Frailey Software Engineering Best Practices – Things You Seldom Learn Much About in School Dennis J. Frailey ACM Distinguished

CSE 8314 - SW Measurement and Quality Engineering Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07 version 3.09Slide 1 SMU CSE

Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M34 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project

CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M05

CSE 8314 - SW Measurement and Quality Engineering Copyright © 1995-2005, Dennis J. Frailey, All Rights Reserved CSE8314M15 version 5.09Slide 1 SMU CSE

© Copyright 2000 The Process Group and Dennis J. Frailey. All rights reserved. 1 Version 1.0 Meeting Tight Schedules Through Cycle Time Improvement The