Meeting Tight Software Schedules Through Cycle Time Reduction

1. Meeting Tight Software Schedules ThroughCycle Time Reduction Dennis J. Frailey Retired Principal Fellow, Raytheon Company Sole Proprietor, DJF CO Frailey@ACM.ORG

2. 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

3. I need that software no later than next week! Why is it taking so long? We’ll work overtime to get it out, sir. But we’re already working overtime! Why Cycle Time is Important Yes, Sir! Right Away, Sir.

4. Definition of Cycle Time Cycle time is the time required to execute all activities in a process, including actual processing time AND all waiting time Consider a “10 minute” oil change

5. 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

6. 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?

7. Some Lessons from the Cycle Time Video What did they do? Is there a software counterpart? Things they did: +_%$#@& ~~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~

8. CT1 + CT2 + CT3 + CT4 +...+ CTn Cycle Time = n How do You Measure Cycle Time? STATIC CYCLE TIME The average of the actual cycle times (CT) experienced by some number (n) of products 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

9. WIP (products being developed) Cycle Time = THROUGHPUT (products produced/unit time) Dynamic Cycle Time The total work in process divided by the throughput of the process For related background, see Gross and Harris, in reference list, p83. WIP = Work in Process

10. How is Cycle Time Improved? • Doing every process step faster? • Working longer hours? • Piling up work? Faster!!!

11. Cycle Time Improvement Is … Improving the Process

12. Cycle Time Improvement Is … Improving the Process Reducing the Critical Path

13. Cycle Time Improvement Is … Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks

14. Cycle Time Improvement Is … Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks Helping People work Smarter

15. Cycle Time Improvement Is … Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks Helping People work Smarter Increased Cycles of Learning

16. Cycle Time Improvement Is … Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks Helping People work Smarter Increased Cycles of Learning Reengineering the Process

17. 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

18. Variability Complexity Bottlenecks ü ü Misplaced Priorities ü ü Incompatible Tools ü ü ü Inefficient Procedures ü ü ü Poor Planning ü ü ü etc. Typical Causes ofCycle Time Problems

19. WIP (products being developed) Cycle Time = THROUGHPUT (products produced/unit time) 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

20. Examples of Excessive WIP for 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...

21. Other Symptoms ofCycle Time Problems • Long waits and queues • High inventory levels • Excessive overtime • High levels of rework / scrap Tickets --> How long is this line?

22. Defect Detected Process Step Process Step Undetected Defect Several Steps Reducing Rework - The Impact of Defects on Cycle Time

23. Defect Detected Process Step Process Step Undetected Defect Several Steps Doing it Over Again Rework costs money and time

24. 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

25. 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 reworkthan you think

26. Fixing the Problems --Five Principles of Cycle Time Improvement Warning … some of these are counter-intuitive

27. Where are the Opportunities? ~30% of the improvement comes from technical changes • Process changes • Tool changes • Changing rules and operations

28. Where are the Opportunities? ~70% of the improvement comes from organizational, cultural and environmental changes, such as • Education • Communication • Management • Teamwork

29. Principle #1 Look at the Entire Process • 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!

30. Example Process – Pizza Shop Deliver Take Order Where could the bottlenecks be? Box Toppings Slicer Pizza Oven Crust

31.        Gain from Cycles of Learning Principle #2 Sometimes it is better to do the job many times, in small chunks, than to do it all at once Changes are received and processed here ()

32. 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

33. Principle #3 Use Small Batches • 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 1 Rework Batch 2 Rework Batch 3 Batch 4 Batch 5

34. Principle #4 Aim for Smooth Flow The typical process runs unevenly, like vehicles on a city street • 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

35. The Ideal is Smooth Flow The ideal process flows smoothly, like a train running on tracks • Note: tracks are empty most of the time

36. 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

37. Principle #5 Avoid the Naïve, Obvious and Wrong Solutions to Cycle Time Problems 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

38. 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

39. Productivity is NOT being ... • Wealthy • Hardworking • etc. • 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

40. Output Productivity = Input or Investment Measuring Productivity Productivity is usually measured in terms of how much you produce in relation to how much you invest

41. 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.

42. A Few Lessons Learned

43. Lesson LearnedBe Careful Whom you Reward • Know the difference between busy and productive • Examine the valueproduced, 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

44. Lesson Learned Independent Observers May See Problems and Opportunities the Best 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

45. The Athletic Coach Analogy Just as athletes rely on coaches, software engineers need to learn to trust in others to observe and help them do better

46. 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

47. 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

48. 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.

49. END Questions? Comments?