Agile and ToC - Case Study


Published on

This lecture was given by me during the latest PMI 2010 Conference - the annual event of the Project Management Community in Israel.
It outlines a case study we performed in utilizing Theory Of Constraints best practices in the macro level of a complex, multi-site project and Agile best practices in the micro-level of the various teams

Published in: Technology, Business

Agile and ToC - Case Study

  1. 1. Agile & ToC<br />Size Does Matter<br />Aviram Eisenberg<br />Ignite<br />
  2. 2. Size Does Matter!<br />Place Holder for a Joke on: <br />Size Does Matter!<br />
  3. 3. About Ignite<br />A SW Development Management company<br />Expertise in Project Management<br />Expertise in SW Development methodologies<br />Agile/Scrum<br />TOC<br />Lean/Kanban<br />Customized flavor<br />Expertise in Global Delivery models<br />Distributed development<br />Senior onsite Israeli R&D managers<br />Offshore centers in Ukraine, Belarus, Russia and Mexico<br />
  4. 4. One Size Doesn’t Fit All<br />Agile has very good best practices for SW dev<br />Agile is best suited for:<br />New project development<br />Single, co-located homogeneous team<br />Projects that has some level of freedom<br />Projects that has some level of customer collaboration<br />Agile and TOC<br />For complex projects<br />Multi-teams<br />Multi sites<br />Low level of freedom<br />
  5. 5. Agile Highlights <br />Claims that SW development is a spiral process hence waterfall model is usually not effective<br />Develop in short iterations (sprints) that contain that each contain the spec analysis, estimations, design develop and testing<br />Working software must be delivered at each iteration<br />Due dates are fixed, scope can be changed<br />Pareto: 80% of SW value comes from 20% of the features<br />Customer collaboration – prioritization of backlog<br />User stories vs. system specifications<br /> Self Organizing teams<br />Test Automation<br />Continuous integration – code cannot break!<br />
  6. 6. Agile – take 1<br />Planning I0<br />Task 1<br />Task 2<br />Testing<br />Planning I1<br />Task 3<br />Task 4<br />Testing<br />
  7. 7. Agile – take 2<br />Planning I0<br />Task 1<br />HL Planning<br />Task 2<br />Testing<br />Integration<br />Integration <br />Planning<br />Planning I1<br />Testing<br />Task 4<br />Task 3<br />Testing<br />
  8. 8. TOC Highlights <br />Improve throughput of complex projects<br />Identify and protect the critical chain<br />The TOC process:<br />Identify the system’s constraint(s)<br />Decide how to exploit the system’s constraint(s)<br />Subordinate everything else to the decision in step 2 <br />Solve the system’s constraint(s)<br />Return to step 1 if the system’s constraints were changed<br />
  9. 9. TOC Highlights <br />Plan all activities according to 50% probability estimations – Parkinson’s Law<br />Add time buffer at the end of each path (feeding/project buffers)<br />Add resource buffers to assist on bottlenecks<br />Avoid multitasking along the critical chain<br />Monitor buffer consumption as opposed to task schedule<br />
  10. 10. TOC<br />Architecture<br />Design<br />Task 1<br />Task 2<br />Testing<br />Design<br />Task 3<br />Design<br />Design<br />Design<br />Design<br />Integration<br />Integration<br />Task 4<br />Testing<br />Task 4<br />Testing<br />Task 4<br />Testing<br />Task 4<br />Management<br />
  11. 11. TOC<br />Architecture<br />Architecture<br />Architecture<br />Architecture<br />Architecture<br />Design<br />Task 1<br />Task 2<br />Testing<br />FB<br />Design<br />Task 3<br />FB<br />Integration<br />PB<br />Task 4<br />Testing<br />Resource Pool<br />Management<br />
  12. 12. TOC vs Agile <br />
  13. 13. Statistics<br />The standard stats:<br />More than 60% projects fail to meet budget and due date objectives by more than 200%<br />30% of projects are cancelled<br />70% fall short of scope<br />Agile stats:<br />99% chance to meet due date<br />Better quality software<br />Improved customer satisfaction<br />TOC:<br />10% to 50% improvement on throughput<br />90 to 95% chances to meet due date and budget<br />
  14. 14. Agile or TOC<br />So, Agile or TOC?<br />It depends on project characteristics<br />Why not use both? <br />
  15. 15. TOC with Agile<br />Planning I0<br />Iteration 0<br />FB<br />Task 1<br />HL Planning<br />Task 2<br />Testing<br />Integration<br />Integration <br />Planning<br />Integration<br />PB<br />Planning I1<br />Testing<br />Iteration 1<br />Iteration 1<br />Task 4<br />Task 3<br />Testing<br />
  16. 16. Agile-ToC Simulation<br />Let’s Start with the Simulation!<br />
  17. 17. The Project<br />Company A has a major project: developing a new module: “Zubora”<br />The company has 12 months and 40 people for this mission<br />The teams are distributed:<br />15 people in Ukraine: 12 testing engineers and 3 UI developers with low experience<br />20 in US: 2 team leaders, 12 developers, 3 DBAs, 3 testing engineers<br />5 in Israel: developers + highly experienced UI engineers<br />
  18. 18. The Challenge<br />There are 10 potential customers for this new module in the coming year <br />Many RFPs talking about features that would be enabled by the new module <br />Prioritization is tough<br />The market is quite new<br />
  19. 19. Observations<br />We have a hard stop after 12 months<br />Throughput is critical (isn’t it always???)<br />Prioritization is tough<br />We have to complete the full scope on time<br />Teams are distributed all over the globe<br />Creates a lot of waste due to excessive communication<br />Time zone differences: longer decision/resolution time = waste<br />Market is new = changes will come<br />
  20. 20. Delivery Model<br />Team 1<br />US: DBA+Server Side <br />US: Testers<br />UKR: Test Engineers<br />Team 2<br />US: DBA+Server Side <br />US: Tester<br />UKR: Test Engineers<br />Team3<br />ISR: UI Developers<br />UKR: UI Developers<br />UKR: Test Engineers<br />Team 4<br />UKR: System Testers<br />
  21. 21. Agile & ToC<br />T1: Infrastructure<br />T1: Infrastructure<br />T1: BL<br />FB<br />FB<br />T2: BL<br />T2: BL<br />FB<br />T2: BL<br />FB<br />Release<br /> Planning<br />PB<br />T3: UI<br />T3: UI Infra<br />T3: UI<br />T3: UI<br />All:Tests<br />UI Design<br />UI Design<br />UI Design<br />FB<br />FB<br />FB<br />T4: System <br />Tests<br />T4: System <br />Tests<br />FB<br />Resource Pool<br />
  22. 22. Things We Take from Agile<br />Incremental Development (sprints) <br />Agile Estimation<br />Early integration cycles<br />Embedded QA<br />Continuous Integration<br />Just enough design <br />Just enough documentation<br />Customer engagement<br />
  23. 23. Things We Take from TOC<br />High Level Planning Principles<br />Optimistic estimates planning<br />Critical Chain Management<br />Buffer Management (with Agile twist)<br />Bottleneck monitoring and resolution<br />
  24. 24. What Do We Do If<br />Sprint scope is only 50% done<br />This is natural and integrated into the plan<br />BL/Infra teams are falling behind schedule<br />We add sprints, consuming feeding buffers<br />Design team is falling behind schedule<br />We add sprints, consuming feeding buffers<br />Prioritization is changed<br />Move stories from one sprint to another, across all teams<br />Change requests are added<br />Remove lower priority stories or extend the project<br />UI team falls behind schedule<br />Utilize resource pool as much as possible<br />Add sprints and consume project buffer<br />
  25. 25. Q&AAviram<br />Q&AAviram<br />