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.

Agile intro stldodn2009


Published on

Basic introduction to Agile Methodology from the 2009 Saint Louis Day of Dot Net. Supplement to 2010 STLDODN Presentation for newcomers to the agile methodology

Published in: Technology
  • Be the first to comment

Agile intro stldodn2009

  1. 1. Basic Stretches<br />An introduction to Agility<br />Brian Blanchard<br />Interim CIO / Executive Consultant<br />Lagovent / Lagovent Ventures<br />Email:<br />Blog:<br />Bio:<br />
  2. 2. Agenda<br />Next -><br />
  3. 3. Quick History Lesson<br />Where did agile come from?<br />
  4. 4. History Lesson (pre-1970)<br />Wild West for fortune 500 companies<br />Our forefathers are Geeks Nerds<br />Challenged cultural norms<br />Didn’t merge with the business - Impossible to manage<br />Inconsistent completion rates<br />They failed regularly: <br />80 – 90% Failure rate<br />Next -><br />
  5. 5. History Lesson (1970 – Today)<br />Waterfall:<br />Serial method of software management created by <br /> Winston Royce<br />Goal: <br />Mold dev. into a manufacturing model<br />Produce consistent, manageable outputs<br />Control the geeks<br />Create development assembly lines <br />Outcome:<br />Major increases in productivity<br />Failure dropped to 70% failure!!!<br />Fatal Flaw<br />Does not handle change well<br />Next -><br />
  6. 6. History Lesson (1999 – Future)<br />Agile:<br />Roots in Japanese models for efficiency<br />Lean, Kanban, Kaizan, etc…<br />Iterative methods in production took root in IT<br />Goal<br />Treat dev. like a Product Development/R&D unit<br />Allow developers to lead development<br />Accept that IT is as much art as it is science<br />Demonstrate that the future of IT is found in its ability to drive change<br />Outcome<br />Increased productivity <br />Failure rate decreased to 24% in many studies.<br />More manageable code bases<br />Average Agile codebase is 20 - 40% smaller than similar waterfall products<br />Increase in developer retention<br />Engaged development teams are happier<br />Increased business value<br />30 – 50 % reduction in time to market<br />200% increase in innovation & tech. capability<br />Next -><br />
  7. 7. Comparison to Waterfall<br />Handling failure in an Agile world<br />
  8. 8. Reason for Waterfall Failure<br />Moore’s Law: The number of transistors on a chip doubles every 24 months<br />Universal Law: Change<br />Assumptions<br />Facts (Moore’s Law & Universal Law)<br />Requirements are perfect<br />Tech. is stable, mature, well known<br />All new or unknown challenges are solved before dev. begins.<br />Repetition of a known process.<br />Application development aims to hit a fixed target<br />Customer demand grows<br />Tech. capabilities grow<br />New platforms create new challenges & opportunities throughout dev. cycles<br />Dev. strive to automate anything repetitious<br />Application development is a moving target based on market demand and growth<br />Next -><br />
  9. 9. Agile Manifesto<br />We are uncovering better ways of developing software by doing it and helping <br />others do it. Through this work we have come to value<br />Individuals and interactions<br />Working software <br />Customer collaboration<br />Responding to change <br />Processes and tools <br />Comprehensive documentation<br />Contract negotiation <br />Following a plan <br />over<br />Next -><br />
  10. 10. Handling Change<br />Agile<br />Change is good<br />Waterfall<br />The team failed<br />Central belief:<br />Common project risks<br />Poor/changed Conclusions<br />App doesn’t meet need<br />Plans are incorrect/changed<br />Takes too long – cost too much<br />Process Failure<br />Scope creep, comm. failures, etc…<br />Repeat Process Failure<br />Continued process issues<br />Development Failure<br />Poor quality, doesn’t work as expected, doesn’t work at all.<br />More analysis<br />Create more plans<br />Add processes<br />More meetings<br />Buy tools <br />Manage processes<br />Terminate<br />24% of waterfall projects are terminated<br /><ul><li>Involve the customer
  11. 11. Change the plan
  12. 12. Feedback loop
  13. 13. Embrace improvement
  14. 14. More feedback
  15. 15. Continue to change slowly
  16. 16. Embrace failure early
  17. 17. Become responsive to change</li></ul>Next -><br />
  18. 18. What is Agile?<br />
  19. 19. What is Agile?<br />Change:<br />It is change, continuing change, inevitable change that is the dominant factor in society today. No sensible decision can be made without taking it into account. …Isaac Asimov<br />Agile is a conceptual framework that supports & is defined by several methodologies. All of which exist to steer change.<br />Common attributes:<br />Embrace change throughout the development cycle<br />Iterative or incremental development - Timeboxing<br />Focus is placed on creating working products<br />Product creation is driven by the customer<br />Work is completed by collaborative, self-organized teams<br />General focus:<br />Producing business value rapidly<br />Lean thinking to remove waste and improve the journey<br />Next -><br />
  20. 20. What is Agile? – Agile Methodologies<br />Scrum<br />Prioritized backlog<br />Daily standup meetings<br />Demo after each iteration<br />Correct the process through lessons learned<br />XP<br />Communication, simplicity, feedback, and courage<br />Requires TDD, refactoring, pair programming, continuous integration, open workspaces, and automated acceptance tests <br />Lean<br />Move closer to customer<br />Shorter cycles<br />Eliminate waste<br />Decisions are made at the last responsible moment<br />Empower the team<br />build in integrity <br />Next -><br />
  21. 21. Agile Myths & Misconceptions<br />
  22. 22. Agile Myths & Misconceptions<br />Agile means no structure & no management<br />Agile’s structure is well defined and easily managed<br />Agile means no discipline<br />Agile developers must be more disciplined to succeed<br />Agile is ad-hoc, we have no plan<br />Agile does not support development without planning<br />Agile does infuse flexibility into the plan<br />Agile creates degraded code bases that are destined for collapse<br />In Agile, quality is a way of life not an after thought<br />Code ownership throughout the team creates higher quality code<br />Next -><br />
  23. 23. Agile Myths & Misconceptions<br />Agile is all about paired development<br />Some methodologies employ paired dev. techniques to improve quality, but that does not summarize Agile<br />Agile is a cult / religion<br />Agile is a proven methodology supported by more than statistics collective for more than a century. All of which demonstrate consistent, improvement metrics.<br />Employing Agile or other lean management methodologies should be done as a part of a planned, calculated strategy to improve productivity and sustainability.<br />Next -><br />
  24. 24. Agile Advantages<br />Why Agile<br />
  25. 25. Agile Advantages – Iterative Release Cycles<br />Smaller batches<br />Higher quality<br />Increased feedback<br />Ease of adjustment<br />Increased customer satisfaction<br />Frequent releases<br />Reduced time to market<br />Regular regression testing<br />Better team collaboration<br />Avoids release based conflicts <br />Gauge true value faster<br />Compatible with Moore’s Law and Universal Laws of Change<br />Next -><br />
  26. 26. Agile Advantages – Increased business value<br />Supports IT’s shift from old model People/Process/Technology to Value/People/Process<br />Increase innovation <br />Business leaders (Product Managers) guess what customers need<br />Active customers know what they need<br />Reduce IT investment<br />Iterative releases allow business to test theories and adjust investments<br />Focus on customer need reduces excessive features<br />Next -><br />
  27. 27. Agile Advantages – Increased quality<br />Less Code / Less Defects:<br />Industry average: 15 – 50 defects per 1,000 lines of code<br />Agile creates more features with less code<br />Code ownership<br />Responsible owners write better code<br />Cost of change curve<br />Next -><br />
  28. 28. Agile Advantages – Delayed technical decisions<br />Absolutes are often false<br />Uncertainty is acceptable<br />Emergence is good<br />Absolutes generate waste<br />Delayed technical decisions<br />Decisions based on absolutes are often poor decisions<br />Avoid technical lock-in<br />Creates additional options<br />Mitigates risk<br />Reduces complexity<br />Reduces management responsibilities<br />Steer technical improvement<br />Rather than controlling & planning<br />Next -><br />
  29. 29. Agile Advantages – Increased visibility<br />Stakeholders are peers in the team<br />Unnecessary decisions are adverted<br />Necessary decisions are made faster<br />Iterative releases<br />Clear examples of work completed / eliminates guest-imated completion times<br />Visible examples of customer adoption during development<br />Create check points to certify completion<br />Stakeholders can steer the ship <br />Rather than planning the course<br />Next -><br />
  30. 30. Agile Shortcoming<br />Why isn’t Agile everywhere<br />
  31. 31. Agile Shortcomings – Lack of expertise<br />Lack of expertise / Self proclaimed experts<br />You wouldn’t build a plane without consulting an expert<br />Why would you rebuild your organization without an expert<br />Forrester 2008 Agile Survey<br />33% using some form of Agile<br />10% of “Agile” IT teams consider themselves “true practitioners”<br />35% using a waterfall approach<br />Organizations are more interested in optimizing their processes than defining or understanding them in the first place.<br />New EDS ad.<br />“We build planes in the sky”<br />Next -><br />
  32. 32. Agile Shortcomings – Corporate resistance<br />Agile methodologies change the way business is conducted<br />Agile requires a fusion of IT and Business practices<br />Value / People / Process model<br />“Customers” must be active in the development process<br />At some point the Agile approach will appear to fail<br />People will resist Agile<br />Change without proper executive support/understanding will be quickly terminated<br />Next -><br />
  33. 33. Agile Shortcomings – Scalability concerns<br />Enterprise Agile is a difficult concept<br />Implementing a new methodology in the enterprise takes time<br />Ex: IBM converted 25,000 developers to Agile<br />Challenges:<br />5 year completion (2002 – 2007)<br />Several $million invested in the methodology conversion<br />High degree of risk involved in this conversion<br />Required support from several teams<br />Executive sponsors<br />Architecture committee<br />Agile coaches<br />Trust from business leaders<br />Final result<br />Net return of $4 per $1 invested<br />400% ROI in 7 years<br />ROI continues to grow<br />Next -><br />
  34. 34. Life as an Agilist<br />What can I expect?<br />
  35. 35. Life as an agilistWhat can I expect?<br />Before an Iteration: <br />Iteration Planning:<br />No specs / just user stories (feature requests)<br />Discuss the stories with the customer or product<br />Iteration planning can last a few hours<br />Build a plan<br />May include UML, white boarding, defining unit or functional tests, etc…<br />Plans / Estimations:<br />You will make some decisions w/ little information<br />You may have to give rough estimates<br />They will be wrong. It’s ok.<br />You may have to learn a new way to estimate.<br />Next -><br />
  36. 36. Life as an agilistWhat can I expect?<br />During an Iteration: <br />Accountability: <br />Meet with the team at least once a day<br />5 minute standup meetings: <br />What was completed today? <br />What roadblocks need to be resolved?<br />The team: <br />Delivers code in rapid cycles. <br />Possibly once a week. <br />Get’R’Done mentality.<br />Open to discussion (often working in “bullpens”)<br />Development:<br />Working features not partial tasks<br />Quality is a way of life.<br />Responsible code ownership<br />Next -><br />
  37. 37. Life as an agilistWhat can I expect?<br />After an Iteration: <br />Review:<br />Show the customer<br />Release the product<br />New ideas<br />Concerns<br />The journey:<br />Development is a journey not a destination<br />Share lessons learned<br />Help the team improve<br />Improve the process<br />Next -><br />
  38. 38. Advanced Discussions / Comparisons<br />Concepts that challenge traditional thinking<br />
  39. 39. Internal customers<br />Business leaders/product managers <br />Guess the needs of users<br />Guesses may lead to adoption<br />Guesses will bloat the application and increase complexity<br />Requested features may produce revenue<br />External/True customers<br />Actual system users<br />Understand their own needs<br />Clear needs will lead to innovation<br />Known needs will streamline the application<br />Necessary features will produce revenue immediately<br />Advanced Discussions – Who’s the customer<br />Next -><br />
  40. 40. Specs / Requirements<br />10 or more pages <br />Attempt to answer every question that could be asked about a feature.<br />Very detailed<br />Extensive technical details<br />Limit creative input<br />Serves internal customers<br />User Stories<br />3 – 5 sentences<br />Attempt to explain the basic need at the highest level<br />Only high level detail<br />No technical details<br />Maximize creative input<br />Serves True customers<br />Advanced Discussions – What are user stories?<br />Sample User Story:<br />Search for products. The user wants to view a list of products. The application asks the user to select attributes of a product (price, color, etc…). After the user specifies the search criteria, the application displays a list of products that match the desired attributes.<br />Next -><br />
  41. 41. Common misconceptions: <br />We know our users… <br />We know our product…<br />No one can do it better than us…<br />We are always right… <br />We are good at writing code<br />Fact:<br />Your users needs change frequently<br />The market’s impression of your product changes daily<br />Right now, someone is building a new product that does it better<br />You are likely wrong<br />Every team can improve<br />Advanced Discussions – Feedback loops<br /><ul><li>Solution:
  42. 42. Embrace customer feedback
  43. 43. Applaud team member feedback
  44. 44. Openly accepting and encouraging feedback avoids the internal group think that kills products
  45. 45. Encourage feedback about the product & processes at the end of each iteration.
  46. 46. Work quickly to incorporate feedback</li></ul>Next -><br />
  47. 47. Advanced Discussions – Testing<br />Agile development does not allow for the quality control cycles seen in a typical waterfall development. It requires new methods for managing product quality.<br />Old models: <br />Testers are often second class citizens<br />Testers write all tests<br />Testing occurs in the last 10% of a project<br />Defects caught downstream are costly and time consuming<br />Only critical defects are addressed before release<br />Agile models:<br />Testers are always apart of the team<br />Developers and testers partner to complete testing. <br />I.E. TDD, Unit tests, & Test repositories<br />Testing occurs prior to the completion of each iteration<br />Defects caught early can be resolved quickly and easily<br />I.E. Continuous integration & daily meetings<br />All defects are accounted for prior to release<br />Next -><br />
  48. 48. Advanced Discussions – Estimation<br />Estimates created by a group of direct contributors are more accurate than those from business leaders or IT managers.<br />In Agile, you do not estimate time. Instead you estimate the size, complexity, or risk of a story. Overtime, a consistent velocity is established. The velocity per sprint will allow the scrum master to estimate time.<br />Size Estimation techniques:<br />Story points: Estimates are based on risk and complexity not time. The more complex or risky a request is, the more story points it will consume.<br />Power of Two: Team members assign each user story a point value between 1 and 8. 2 is twice as complex or risky than 1. 4 is twice as risky as 2. 6 is twice as risky as 4. Etc…<br />Scrum poker: The scrum team “votes” on the story points each user story will require. If the vote is not unanimous, the scrum master may decide to use the highest estimate. Some scrum masters will ask team members to discuss the story, followed by a revote. Usually in either scenario, the highest point value is used as the estimate.<br />Next -><br />
  49. 49. Advanced Discussions – Metrics<br />To truly accept agile methodologies, you must accept that development does not adhere to old business models. It requires a new management model & new metrics.<br />Key metrics:<br />Earned value: A measurement of the value created for the business by a given feature, iteration, project, and/or product. Monitoring this metric at each level, after each iteration helps to correct misconceptions regarding adoption, revenue, usability, market presence, etc…<br />Velocity: The amount of software a team can create in a given iteration. This is not an estimate of time, it is a gauge of forward motion. It is used to determine if the team can truly meet the commitments made during each iteration. It is also used to set iteration and release expectations.<br />Burn Down: The measurement of the features completed over time. Demonstrates the amount of software created against the amount requested. Used to monitor development capacity.<br />Burn Up: The measurement of features requested over time. Demonstrates the growth of the applications scope over time. In a waterfall project this is the dreaded “Scope Creep”. In Agile projects, this is applauded innovation. Used to monitor product growth.<br />Next -><br />
  50. 50. Advanced Discussions – Collective Code Ownership<br />In an agile environment, the team owns the code. <br />Effective Agile developers must let go of ego and share their code. <br />Agile ownership rules:<br />Anyone can make necessary changes anywhere<br />Everyone is responsible for fixing problems they find<br />Be a responsible owner of the code<br />Re-factor dirty code <br />Follow coding standards <br />Apply naming conventions<br />If you do not know the code base, partner with the product expert<br />If the product expert does not exist, or is unavailable:<br />Assume prior developers followed the rules of responsible code ownership<br />Unit test everything you write – No Exceptions<br />Next -><br />
  51. 51. Questions & Answers <br />Basic Stretches<br />An introduction to Agility<br />Brian Blanchard<br />Interim CIO / Executive Consultant<br />Lagovent / Lagovent Ventures<br />Email:<br />Blog:<br />Bio:<br />