Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Journey of Agile


Published on

My presentation to Product Owners at McKinsey on the evolution and continuing journey of agile software development

Published in: Software, Technology, Business

Journey of Agile

  1. 1. Journey of Agile Tathagat Varma VP, Strategic Process Innovations & HR, [24]7 Innovation Labs
  2. 2. The GenesiS...... New products   New Services New Markets New Features Improvements Enhancements Extensions … Friction New Tech Competitor Opportunity Initiative …
  3. 3. From Idea to CaSH
  4. 4. Minimize Investment Minimize Time to Market Maximize ReturnS Business success factors
  5. 5. Waterfall Model •  Wrongly inspired by assembly-line manufacturing •  Economics supported “measure twice, cut once” leading to up-front planning and BDUF •  Single-pass, sequential process with hand- offs and feedback loops between adjoining phases •  Transition to next phase only upon completion of current phase •  Focus on Documentation
  6. 6. Waterfall Software Development Picture  from  h-p://­‐development-­‐game-­‐of.html   Limitations and Assumptions 1.  Wrong analogy: Software development ≠ Production 2.  Customers know EVERYTHING upfront and that requirement won’t change 3.  Legacy: implicitly assumes CPU time is costly, so focuses on doing everything upfront to minimize ‘machine time’ for trial and error 4.  “Wicked Problem”: Designers and developers know how exactly how to build 5.  Very long feedback cycles not suitable for today’s pace of innovation
  7. 7. Waterfall challenges: Poor Visibility h-p://    
  8. 8. Waterfall challenges: Poor Risk Management h-p://    
  9. 9. Waterfall challenges: Poor Quality h-p://    
  10. 10. Cost of Fixing Defects in Waterfall Model h-p://­‐us/library/bb756611.aspx    
  11. 11. Waterfall challenges: Poor Change Management h-p://    
  12. 12. Preamble to Agile Movement Software Crisis, 1965-85: The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. — Edsger Dijkstra, The Humble Programmer
  13. 13. Software Crisis The causes of the software crisis were linked to the overall complexity of hardware and the software development process. The crisis manifested itself in several ways: •  Projects running over-budget. •  Projects running over-time. •  Software was very inefficient. •  Software was of low quality. •  Software often did not meet requirements. •  Projects were unmanageable and code difficult to maintain. •  Software was never delivered.
  14. 14. Why? •  Process: Long-lead development process ineffective in a dynamic and global world •  Management: Command and control model unsuitable for fostering collaboration required to solve complex problems •  Technology: Advancements in computers, compilers, debugging and testing tools greatly altered the economics of software development •  Innovation: in the age of hyper-innovation, old processes were simply ineffective
  15. 15. As a result, software is… Late Buggy Costly
  16. 16. and the costs.......? h-p://   h-p://  
  17. 17. Software Project Failure Rates – Standish Report
  18. 18. so, why do projects fail?
  19. 19. Why?
  20. 20. h-p://­‐content/uploads/2012/08/Stacey.png     That’s  the   problem  we   need  to  solve!   And  these  are   the  methods  we   are  using!!!  
  21. 21. But we want software to be…
  22. 22. What is the most important part in these machines? “The Brakes!!!” They let you go faster…
  23. 23. Agility vs. Discipline? h-p://  
  24. 24. Spiral h-p://,_1988%29.svg    
  25. 25. Incremental Development •  Incremental development – is a scheduling and staging strategy – in which the various parts of the system are developed at different times or rates, – and integrated as they are completed. – It does not imply, require nor preclude iterative development or waterfall development - both of those are rework strategies. •  The alternative to incremental development is to develop the entire system with a "big bang" integration
  26. 26. Iterative Development •  Iterative development – is a rework scheduling strategy – in which time is set aside to revise and improve parts of the system. – It does not presuppose incremental development, but works very well with it. A typical difference is that the output from an increment is not necessarily subject to further refinement, and its' testing or user feedback is not used as input for revising the plans or specifications of the successive increments. On the contrary, the output from an iteration is examined for modification, and especially for revising the targets of the successive iterations.
  27. 27. Incremental vs. Iterative h-p://­‐and-­‐incremen=ng/en/resources/ Pa-on_Incremental_Itera=ve_MnaLisa.jpg    
  28. 28. h-p://­‐incremental-­‐mona-­‐lisa.png     Incremental and Iterative
  29. 29. Advent of Agile and Lean Methodologies •  1970: Royce critiques Waterfall and offers improvement ideas •  1986: Barry Boehm proposes Spiral Model •  1971: Harlan Mills proposes Incremental Development •  1987: Cleanroom Software engineering •  1991: Sashimi Overlapping Waterfall Model •  1992: Crystal family of methodologies •  1994: DSDM •  1995: Scrum •  1996: Rational Unified Process framework •  1997: Feature Driven Development •  1999: Extreme Programming Explained •  2001: Agile Manifesto is born •  2003: Lean Software Development •  2005: PM Declaration of Interdependence •  2007: Kanban-based software engineering •  2008: Lean Startup •  2009: Scrumban •  20xx: Something new !?! (hopefully!)
  30. 30. Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Working software is the primary measure of progress. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Continuous attention to technical excellence and good design enhances agility. Business people and developers must work together daily throughout the project. Simplicity--the art of maximizing the amount of work not done--is essential. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self- organizing teams. The most efficient and effective method of conveying information to and within a development team is face-to- face conversation. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  31. 31. Waterfall vs. Agile h-p://     By  doing  them  con=nuously:     •  Quality  improves  because   tes=ng  starts  from  day   one.   •  Visibility  improves   because  you  are  1/2  way   through  the  project  when   you  have  built  1/2  the   features.   •  Risk  is  reduced  because   you  are  ge[ng  feedback   early,  and   •  Customers  are  happy   because  they  can  make   changes  without  paying   exorbitant  costs.    
  32. 32. h-p://­‐content/uploads/2009/06/agile_waterfall-­‐792810.png    
  33. 33. Waterfall vs Agile – Risk of Change h-ps://­‐vs-­‐itera=ve-­‐flow.jpg    
  34. 34. Waterfall vs Agile - mindset h-p://­‐to-­‐six-­‐sigma/design-­‐for-­‐six-­‐sigma-­‐dfss/doing-­‐some-­‐soBware-­‐six-­‐sigma-­‐and-­‐agile-­‐ %E2%90%98mythbus=ng%E2%90%99/    
  35. 35. Schneider Culture Model h-p://­‐culture-­‐and-­‐agile    
  36. 36. Agile Culture h-p://­‐content/uploads/2010/07/Agile-­‐Culture-­‐Quad-­‐diagram-­‐results2.png    
  37. 37. Agile Development Value Proposition h-p://  
  38. 38. Role of Management h-p://www.thoughtworks-­‐    
  39. 39. Agile ROI h-p://­‐performance-­‐tes=ng-­‐process-­‐-­‐-­‐whitepaper    
  40. 40. Feedback Loops
  41. 41. agile lifecycle – big picture
  42. 42. feedback loop in agile lifecycles
  43. 43. test-code-refactor loop
  44. 44. from daily builds to the project
  45. 45. Scrum
  46. 46. Recap... Economies of software development continue to evolve & impact s/w development Waterfall was (perhaps) the best we had back then, even if it was bad! Agile reflects contemprary thinking in process, people and tools Fundamental tenet is continuous feedback and improvement Agile thinking is more important than specific methods and mechanics Focus on getting the right talent and let them self-organize
  47. 47. Questions