Agile intro stldodn2009
Download as PPTX, PDF1 like827 views
The document provides an overview of agile methodologies, tracing their evolution from the less adaptable waterfall model to agile's focus on iterative development and responsiveness to change. It highlights the advantages of agile, such as increased productivity, decreased failure rates, and enhanced collaboration, while also addressing common misconceptions and challenges businesses may face in adopting agile practices. The text emphasizes the importance of customer feedback, team ownership of code, and the need for new metrics to measure success in an agile environment.
Agile intro stldodn2009
- 1. Basic StretchesAn introduction to AgilityBrian BlanchardInterim CIO / Executive ConsultantLagovent / Lagovent VenturesEmail: Brian@devrevival.comBlog: www.devrevival.comBio: www.brian-blanchard.com
- 3. Quick History LessonWhere did agile come from?
- 4. History Lesson (pre-1970)Wild West for fortune 500 companiesOur forefathers are Geeks NerdsChallenged cultural normsDidn’t merge with the business - Impossible to manageInconsistent completion ratesThey failed regularly: 80 – 90% Failure rateNext ->
- 5. History Lesson (1970 – Today)Waterfall:Serial method of software management created by Winston RoyceGoal: Mold dev. into a manufacturing modelProduce consistent, manageable outputsControl the geeksCreate development assembly lines Outcome:Major increases in productivityFailure dropped to 70% failure!!!Fatal FlawDoes not handle change wellNext ->
- 6. History Lesson (1999 – Future)Agile:Roots in Japanese models for efficiencyLean, Kanban, Kaizan, etc…Iterative methods in production took root in ITGoalTreat dev. like a Product Development/R&D unitAllow developers to lead developmentAccept that IT is as much art as it is scienceDemonstrate that the future of IT is found in its ability to drive changeOutcomeIncreased productivity Failure rate decreased to 24% in many studies.More manageable code basesAverage Agile codebase is 20 - 40% smaller than similar waterfall productsIncrease in developer retentionEngaged development teams are happierIncreased business value30 – 50 % reduction in time to market200% increase in innovation & tech. capabilityNext ->
- 7. Comparison to WaterfallHandling failure in an Agile world
- 8. Reason for Waterfall FailureMoore’s Law: The number of transistors on a chip doubles every 24 monthsUniversal Law: ChangeAssumptionsFacts (Moore’s Law & Universal Law)Requirements are perfectTech. is stable, mature, well knownAll new or unknown challenges are solved before dev. begins.Repetition of a known process.Application development aims to hit a fixed targetCustomer demand growsTech. capabilities growNew platforms create new challenges & opportunities throughout dev. cyclesDev. strive to automate anything repetitiousApplication development is a moving target based on market demand and growthNext ->
- 9. Agile ManifestoWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to valueIndividuals and interactionsWorking software Customer collaborationResponding to change Processes and tools Comprehensive documentationContract negotiation Following a plan overNext ->
- 10. Handling ChangeAgileChange is goodWaterfallThe team failedCentral belief:Common project risksPoor/changed ConclusionsApp doesn’t meet needPlans are incorrect/changedTakes too long – cost too muchProcess FailureScope creep, comm. failures, etc…Repeat Process FailureContinued process issuesDevelopment FailurePoor quality, doesn’t work as expected, doesn’t work at all.More analysisCreate more plansAdd processesMore meetingsBuy tools Manage processesTerminate24% of waterfall projects are terminatedInvolve the customer
- 11. Change the plan
- 12. Feedback loop
- 14. More feedback
- 15. Continue to change slowly
- 17. Become responsive to changeNext ->
- 18. What is Agile?
- 19. What is Agile?Change: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 AsimovAgile is a conceptual framework that supports & is defined by several methodologies. All of which exist to steer change.Common attributes:Embrace change throughout the development cycleIterative or incremental development - TimeboxingFocus is placed on creating working productsProduct creation is driven by the customerWork is completed by collaborative, self-organized teamsGeneral focus:Producing business value rapidlyLean thinking to remove waste and improve the journeyNext ->
- 20. What is Agile? – Agile MethodologiesScrumPrioritized backlogDaily standup meetingsDemo after each iterationCorrect the process through lessons learnedXPCommunication, simplicity, feedback, and courageRequires TDD, refactoring, pair programming, continuous integration, open workspaces, and automated acceptance tests LeanMove closer to customerShorter cyclesEliminate wasteDecisions are made at the last responsible momentEmpower the teambuild in integrity Next ->
- 21. Agile Myths & Misconceptions
- 22. Agile Myths & MisconceptionsAgile means no structure & no managementAgile’s structure is well defined and easily managedAgile means no disciplineAgile developers must be more disciplined to succeedAgile is ad-hoc, we have no planAgile does not support development without planningAgile does infuse flexibility into the planAgile creates degraded code bases that are destined for collapseIn Agile, quality is a way of life not an after thoughtCode ownership throughout the team creates higher quality codeNext ->
- 23. Agile Myths & MisconceptionsAgile is all about paired developmentSome methodologies employ paired dev. techniques to improve quality, but that does not summarize AgileAgile is a cult / religionAgile is a proven methodology supported by more than statistics collective for more than a century. All of which demonstrate consistent, improvement metrics.Employing Agile or other lean management methodologies should be done as a part of a planned, calculated strategy to improve productivity and sustainability.Next ->
- 25. Agile Advantages – Iterative Release CyclesSmaller batchesHigher qualityIncreased feedbackEase of adjustmentIncreased customer satisfactionFrequent releasesReduced time to marketRegular regression testingBetter team collaborationAvoids release based conflicts Gauge true value fasterCompatible with Moore’s Law and Universal Laws of ChangeNext ->
- 26. Agile Advantages – Increased business valueSupports IT’s shift from old model People/Process/Technology to Value/People/ProcessIncrease innovation Business leaders (Product Managers) guess what customers needActive customers know what they needReduce IT investmentIterative releases allow business to test theories and adjust investmentsFocus on customer need reduces excessive featuresNext ->
- 27. Agile Advantages – Increased qualityLess Code / Less Defects:Industry average: 15 – 50 defects per 1,000 lines of codeAgile creates more features with less codeCode ownershipResponsible owners write better codeCost of change curveNext ->
- 28. Agile Advantages – Delayed technical decisionsAbsolutes are often falseUncertainty is acceptableEmergence is goodAbsolutes generate wasteDelayed technical decisionsDecisions based on absolutes are often poor decisionsAvoid technical lock-inCreates additional optionsMitigates riskReduces complexityReduces management responsibilitiesSteer technical improvementRather than controlling & planningNext ->
- 29. Agile Advantages – Increased visibilityStakeholders are peers in the teamUnnecessary decisions are advertedNecessary decisions are made fasterIterative releasesClear examples of work completed / eliminates guest-imated completion timesVisible examples of customer adoption during developmentCreate check points to certify completionStakeholders can steer the ship Rather than planning the courseNext ->
- 30. Agile ShortcomingWhy isn’t Agile everywhere
- 31. Agile Shortcomings – Lack of expertiseLack of expertise / Self proclaimed expertsYou wouldn’t build a plane without consulting an expertWhy would you rebuild your organization without an expertForrester 2008 Agile Survey33% using some form of Agile10% of “Agile” IT teams consider themselves “true practitioners”35% using a waterfall approachOrganizations are more interested in optimizing their processes than defining or understanding them in the first place.New EDS ad.“We build planes in the sky”Next ->
- 32. Agile Shortcomings – Corporate resistanceAgile methodologies change the way business is conductedAgile requires a fusion of IT and Business practicesValue / People / Process model“Customers” must be active in the development processAt some point the Agile approach will appear to failPeople will resist AgileChange without proper executive support/understanding will be quickly terminatedNext ->
- 33. Agile Shortcomings – Scalability concernsEnterprise Agile is a difficult conceptImplementing a new methodology in the enterprise takes timeEx: IBM converted 25,000 developers to AgileChallenges:5 year completion (2002 – 2007)Several $million invested in the methodology conversionHigh degree of risk involved in this conversionRequired support from several teamsExecutive sponsorsArchitecture committeeAgile coachesTrust from business leadersFinal resultNet return of $4 per $1 invested400% ROI in 7 yearsROI continues to growNext ->
- 34. Life as an AgilistWhat can I expect?
- 35. Life as an agilistWhat can I expect?Before an Iteration: Iteration Planning:No specs / just user stories (feature requests)Discuss the stories with the customer or productIteration planning can last a few hoursBuild a planMay include UML, white boarding, defining unit or functional tests, etc…Plans / Estimations:You will make some decisions w/ little informationYou may have to give rough estimatesThey will be wrong. It’s ok.You may have to learn a new way to estimate.Next ->
- 36. Life as an agilistWhat can I expect?During an Iteration: Accountability: Meet with the team at least once a day5 minute standup meetings: What was completed today? What roadblocks need to be resolved?The team: Delivers code in rapid cycles. Possibly once a week. Get’R’Done mentality.Open to discussion (often working in “bullpens”)Development:Working features not partial tasksQuality is a way of life.Responsible code ownershipNext ->
- 37. Life as an agilistWhat can I expect?After an Iteration: Review:Show the customerRelease the productNew ideasConcernsThe journey:Development is a journey not a destinationShare lessons learnedHelp the team improveImprove the processNext ->
- 38. Advanced Discussions / ComparisonsConcepts that challenge traditional thinking
- 39. Internal customersBusiness leaders/product managers Guess the needs of usersGuesses may lead to adoptionGuesses will bloat the application and increase complexityRequested features may produce revenueExternal/True customersActual system usersUnderstand their own needsClear needs will lead to innovationKnown needs will streamline the applicationNecessary features will produce revenue immediatelyAdvanced Discussions – Who’s the customerNext ->
- 40. Specs / Requirements10 or more pages Attempt to answer every question that could be asked about a feature.Very detailedExtensive technical detailsLimit creative inputServes internal customersUser Stories3 – 5 sentencesAttempt to explain the basic need at the highest levelOnly high level detailNo technical detailsMaximize creative inputServes True customersAdvanced Discussions – What are user stories?Sample User Story: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.Next ->
- 41. Common misconceptions: We know our users… We know our product…No one can do it better than us…We are always right… We are good at writing codeFact:Your users needs change frequentlyThe market’s impression of your product changes dailyRight now, someone is building a new product that does it betterYou are likely wrongEvery team can improveAdvanced Discussions – Feedback loopsSolution:
- 43. Applaud team member feedback
- 44. Openly accepting and encouraging feedback avoids the internal group think that kills products
- 45. Encourage feedback about the product & processes at the end of each iteration.
- 46. Work quickly to incorporate feedbackNext ->
- 47. Advanced Discussions – TestingAgile development does not allow for the quality control cycles seen in a typical waterfall development. It requires new methods for managing product quality.Old models: Testers are often second class citizensTesters write all testsTesting occurs in the last 10% of a projectDefects caught downstream are costly and time consumingOnly critical defects are addressed before releaseAgile models:Testers are always apart of the teamDevelopers and testers partner to complete testing. I.E. TDD, Unit tests, & Test repositoriesTesting occurs prior to the completion of each iterationDefects caught early can be resolved quickly and easilyI.E. Continuous integration & daily meetingsAll defects are accounted for prior to releaseNext ->
- 48. Advanced Discussions – EstimationEstimates created by a group of direct contributors are more accurate than those from business leaders or IT managers.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.Size Estimation techniques: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.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…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.Next ->
- 49. Advanced Discussions – MetricsTo truly accept agile methodologies, you must accept that development does not adhere to old business models. It requires a new management model & new metrics.Key metrics: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…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.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.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.Next ->
- 50. Advanced Discussions – Collective Code OwnershipIn an agile environment, the team owns the code. Effective Agile developers must let go of ego and share their code. Agile ownership rules:Anyone can make necessary changes anywhereEveryone is responsible for fixing problems they findBe a responsible owner of the codeRe-factor dirty code Follow coding standards Apply naming conventionsIf you do not know the code base, partner with the product expertIf the product expert does not exist, or is unavailable:Assume prior developers followed the rules of responsible code ownershipUnit test everything you write – No ExceptionsNext ->
- 51. Questions & Answers Basic StretchesAn introduction to AgilityBrian BlanchardInterim CIO / Executive ConsultantLagovent / Lagovent VenturesEmail: Brian@devrevival.comBlog: www.devrevival.comBio: www.brian-blanchard.com