Introduction To Agile


Published on

Vineet's presentation on "Introduction to Agile" at the at the Intro to Agile workshop on 28th June 2008

Published in: Technology, News & Politics

Introduction To Agile

  1. 1. Introduction to Agile
  2. 2. Who am I? <ul><li>Software Practitioner & Evangelist </li></ul><ul><ul><li>13 years of building software and learning </li></ul></ul><ul><li>Certified Scrum Master </li></ul><ul><li>Lead Impetus Labs, Consulting and Research </li></ul><ul><li>I am available for </li></ul><ul><ul><li>Speaking on Technology & Agile </li></ul></ul><ul><ul><li>Help & Support your Agile journey </li></ul></ul><ul><ul><li>(e) [email_address] </li></ul></ul><ul><ul><li>(m) 931 310 2111 </li></ul></ul>
  3. 3. Agenda <ul><li>Introduction to Agile </li></ul><ul><ul><li>Lets begin by having fun.. </li></ul></ul><ul><ul><li>History of evolution </li></ul></ul><ul><ul><li>What is Agile? </li></ul></ul><ul><ul><li>What Agile is NOT </li></ul></ul><ul><ul><ul><li>Common myths and misconceptions </li></ul></ul></ul>
  4. 4. Lets Have Some Fun … <ul><li>Need a few volunteers </li></ul><ul><li>Clearing the Obstacle Course – Strategy 1 </li></ul><ul><li>Our volunteers will be working in a team </li></ul><ul><li>1 Manager and other workers </li></ul><ul><li>Worker cannot do anything on his own, he has to verbatim follow the instructions of the Manager </li></ul><ul><li>Goal of the team is to clear the obstacle course </li></ul><ul><li>Please observe them as they go through different the obstacle course </li></ul><ul><ul><li>Productivity (Individual & Overall) </li></ul></ul><ul><ul><li>Happiness </li></ul></ul><ul><ul><li>Ability to react to impediments </li></ul></ul>
  5. 5. Lets Have Some Fun … <ul><li>Clearing the Obstacle Course – Strategy 2 </li></ul><ul><li>Our volunteers will be own their own </li></ul><ul><li>Goal of the volunteers is to clear the obstacle course </li></ul><ul><li>Please observe them as they go through the obstacle course </li></ul><ul><ul><li>Productivity (Individual & Overall) </li></ul></ul><ul><ul><li>Happiness </li></ul></ul><ul><ul><li>Ability to react to impediments </li></ul></ul>
  6. 6. Evolution <ul><li>Agile is evolutionary not revolutionary </li></ul><ul><li>The context of developing software is changing </li></ul><ul><ul><li>Technology driven business innovation </li></ul></ul><ul><ul><li>Dynamic Market conditions </li></ul></ul><ul><ul><ul><li>Time to Market </li></ul></ul></ul><ul><ul><ul><li>Requirement Stability </li></ul></ul></ul><ul><li>What does it mean for software development? </li></ul><ul><ul><li>You cant win a 20-20 game with a test match strategy </li></ul></ul>
  7. 7. Some facts … <ul><li>1995 : The CHAOS Report ** </li></ul><ul><li>Type 1 : Project Success </li></ul><ul><ul><li>On time on budget, all features are delivered ( 16.2% ) </li></ul></ul><ul><li>Type 2 : Project Challenged </li></ul><ul><ul><li>Completed and operational but over budget, fewer features than specified (52.7%) </li></ul></ul><ul><li>Type 3 : Project Impaired </li></ul><ul><ul><li>Cancelled at some stage (31.1%) </li></ul></ul><ul><li>**Tom Clancy 1995 | The Standish Group International </li></ul>
  8. 8. Some facts … <ul><li>Traditional Processes were not helping </li></ul><ul><li>Customers unhappy </li></ul><ul><li>Requirement Changes are dealt through risk avoidance strategy </li></ul><ul><ul><li>i.e resist requirement change </li></ul></ul><ul><ul><li>Eliminating change means business failure </li></ul></ul><ul><li>So ? </li></ul><ul><ul><li>These led to evolutions in the way we approach software development </li></ul></ul>
  9. 9. Introducing Agile <ul><li>The BRAVE new way of developing software </li></ul><ul><li>Don’t avoid risk, take it as unavoidable and accept it </li></ul><ul><li>Requirement Changes are dealt through risk acceptance strategy </li></ul>
  10. 10. Agile Manifesto <ul><li>“ We are uncovering better ways of developing software by doing it and helping others do it. </li></ul><ul><li>Through this work we have come to value: </li></ul><ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul><ul><li>“ That is, while there is value in the items on the right, we value the items on the left more.” </li></ul>
  11. 11. Waterfall Manifesto
  12. 12. Waterfall Manifesto
  13. 13. Principles Behind Agile Manifesto <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software </li></ul><ul><li>Welcome changing requirements , even late in development. Agile processes harness change for the customer's competitive advantage </li></ul><ul><li>Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale </li></ul>
  14. 14. Principles Behind Agile Manifesto <ul><li>Business people and developers must work together daily throughout the project </li></ul><ul><li>Build projects around motivated individuals . Give them the environment and support they need, and trust them to get the job done </li></ul><ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation </li></ul><ul><li>Working software is the primary measure of progress </li></ul>
  15. 15. Principles Behind Agile Manifesto <ul><li>Agile processes promote sustainable development . The sponsors, developers, and users should be able to maintain a constant pace indefinitely </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility </li></ul><ul><li>Simplicity- -the art of maximizing the amount of work not done--is essential. </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
  16. 16. So, What is Agile? <ul><li>Simply Stating … It a way of developing software that follows the Agile Principles </li></ul><ul><li>There are a number of agile software development methods; most attempt to </li></ul><ul><ul><li>minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks </li></ul></ul><ul><ul><li>Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation </li></ul></ul>
  17. 17. So, What is Agile?
  18. 18. Myths & Misconceptions <ul><li>Agile methods are sometimes characterized as being at the opposite end of the spectrum from &quot;plan-driven&quot; or &quot;disciplined&quot; methodologies </li></ul><ul><ul><li>This distinction is misleading, as it implies that agile methods are &quot;unplanned&quot; or &quot;undisciplined“ </li></ul></ul><ul><ul><li>A more accurate distinction is to say that methods exist on a continuum from &quot;adaptive&quot; to &quot;predictive” </li></ul></ul><ul><ul><li>Adaptive methods focus on adapting quickly to changing realities </li></ul></ul><ul><ul><ul><li>When the needs of a project change, an adaptive team changes as well </li></ul></ul></ul><ul><ul><ul><li>An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date </li></ul></ul></ul><ul><ul><ul><li>An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. </li></ul></ul></ul>
  19. 19. Myths & Misconceptions <ul><ul><li>Predictive methods, in contrast, focus on planning the future in detail </li></ul></ul><ul><ul><ul><li>A predictive team can report exactly what features and tasks are planned for the entire length of the development process </li></ul></ul></ul><ul><ul><ul><li>Predictive teams have difficulty changing direction </li></ul></ul></ul><ul><ul><ul><li>The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently </li></ul></ul></ul><ul><ul><ul><li>Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered </li></ul></ul></ul>
  20. 20. Myths & Misconceptions <ul><li>Agile methods v/s CMM/CMMi </li></ul><ul><ul><li>CMM/CMMi is NOT a method or a process model </li></ul></ul><ul><ul><ul><li>It is a reference process benchmark </li></ul></ul></ul><ul><ul><li>CMM/CMMi don’t prescribe what process (for developing software that is) to use </li></ul></ul><ul><ul><li>Agile Software Development process can be benchmarked on CMM/CMMi models </li></ul></ul><ul><ul><ul><li>Initial, Managed, Defined, Quantitively Managed & Optimizing </li></ul></ul></ul>
  21. 21. Myths & Misconceptions <ul><li>Agile __________ </li></ul><ul><li>Is a silver bullet </li></ul><ul><li>Will solve my resource issues </li></ul><ul><li>Has no planning/ documentation/architecture/ <insert pet peeve> </li></ul><ul><li>Is a license to hack </li></ul><ul><li>Creates quality issues </li></ul><ul><li>Is undisciplined </li></ul><ul><li>Doesn’t build on my previous experience / expertise </li></ul><ul><li>Is not proven </li></ul><ul><li>Is not being used by industry leaders </li></ul>
  22. 22. Thank You Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.