why do we need agile

Download Why do we need Agile

Post on 11-Jan-2016

28 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Why do we need Agile. Part 1 What is Agile anyways?. What is Agile anyways?. Agile is a response to change Characterized by quickness and ease of movement; Nimble. Change. Things change Requirements change Needs change Priorities change Technology changes Fashion changes - PowerPoint PPT Presentation

TRANSCRIPT

  • Why do we need Agile

  • Part 1

    What is Agile anyways?

  • What is Agile anyways?Agile is a response to change

    Characterized by quickness and ease of movement; Nimble

  • ChangeThings changeRequirements changeNeeds changePriorities changeTechnology changesFashion changes

    The question really becomes: How do we deal with change?

  • What is the Cost of Change?Building a house

    In DefinitionIn Design$In Development$$In ReleaseIn Test$$$

  • How does Cost of Change affect Software?$$$$$$$$$$Agile system cost profilePrescriptive Approach

  • Traditional methodology doesnt work anymoreTraditional Methods are presumptuousAssume all aspects can be defined prior to the start of workWaterfall methods assume that:Requirements are stableTechnology is well known to the team and mature in its implementationThere will be no surprises, no changes, no deviationsEveryone on the team will have a consistent skill levelProduct Management has patienceSenior Management has patienceCustomers have patience

    Traditional methods force up-front design and therefore specificationUp front design can not accommodate changeEnforces specific organizational structuresEscalation can not affect Product Development

  • Why Traditional Methods dont work anymoreThings changeRequirements changeNeeds changePriorities changeTechnology changesPeople changeEscalation happens

    The question is no longer How do we deal with change?But ratherHow do we deal with change when it happens?How do we minimize impact and cost?

  • Traditional methods induce failuresProvides false comfort in a planPlanning can not define realityPlanning can not control reality, regardless on how detailed it isContingency planning is done to accommodate changeRisk mitigationUncertainty begets uncertaintyOrganizations typically require more layers of plans as the degree of uncertainty increasesPlanners attempt to substitute definition for value propositionPMBOK recommends 28% of an effort should be dedicated to planning, prior to any design or development

  • Traditional methods induce failuresIf 1/4 of a projects lifespan happens prior to any engineering work being accomplishedIt is easier to cancel No real commitment from management has been madeIt is harder to determine value The Return on Investment is longerIt is impossible to leapfrog the competitionEven if the project is successful, the business suffers

  • The RealizationWaterfall no longer solves our problemsTraditional methodologies were good at managing the knownBut they are terrible at managing the unknownTo succeed we have to adaptReality rules. Period.Despite my best laid plans

  • Enter AgilistsIndustry leaders discovered similarities between their methodologiesXP (eXtreme Programming) Kent BeckScrum Ken SchwaberLean Software Development Mary PoppendieckCrystal family Alistair CockburnFeature Driven Development Peter Coad

    They met in 2001 and decided to name the family of methodologies AgileThey also created the Agile Manifesto, and defining Values and Principles

    www.agilemanifesto.orgIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

  • Popular flavors of AgileExtreme ProgrammingDefined by its PracticesScrum Defined by its management frameworkLean Software DevelopmentDefined by its approach to continuous improvement and quest to remove wasteful practicesOthers: DSDM, FDD, Crystal

  • Agile is not Agile is not:Just a collection of practicesA silver bulletA check list of things to do on every project

    While there are common practices and principles It does need to be applied and tailored to each situationbut start by the book, tailor each iterationIt is not right for every projectIs not a one size fits all

  • What is Agile?Agile software development is:Continuous reflection and learningRemoving inefficiencies and wasteBuilding a collaborative team environmentWorking together to find better ways of delivering

  • Part 2

    How do we use Agile

  • OverviewKey imperatives determining project value:Increase in business profitabilityManaging business riskDefined requirementsSuccessful projects create maximum business value.Projects succeed by meeting business need:Involve the business throughoutFirst release shouldnt be a surprise for usersRegular feedback + accurate status reportingClosed loop, flexible, responsive: enabling changeDefer decision-making Dont try and decide everything up-frontKey imperatives determining project value:Increase in business profitabilityManaging business riskDefined requirementsSuccessful projects create maximum business value.Projects succeed by meeting business need:Involve the business throughoutFirst release shouldnt be a surprise for usersRegular feedback + accurate status reportingClosed loop, flexible, responsive: enabling changeDefer decision-making (latest responsible moment)Dont try and decide everything up-front

  • Business ownershipExecutive support & user involvement - critical factors in project successAlign with business needs + stakeholder goalsWorkshops capture business requirements in stories written in users languageEach story represents a unit of business valueCollaborative iteration planning delivers high priority stories first Continuous business involvementShort regular iterations of working code give tangible evidence of progressIterations allow business to assess requirements, provide feedback, request changeContinuous integration improves forecasting accuracy and status reporting Business can discard/modify requirements at any timeBusiness retains GO/NO GO decision at any timeImprove relationship between IT and businessSuccessful projects lead to successful relationships

  • Managing riskImproved visibility throughout the project life-cycle Early validation of business caseAccuracy in forecasting and status reportingPrioritization of business needImproved quality + productivityImproved quality and efficiency of codeTest Directed Development ensures requirements are metCost effectivenessResponsiveness to change at reduced costElimination of wasteIterations allow for frequent feedback to validate requirements

  • Reduced cost of changeClients can change their minds:Collaborative iteration planning allows stories to be discarded or modified at any timeDetailed analysis/design carried out for current iteration onlyFuture stories have negligible sunk costsFrequent iterations/feedback leads to early identification of required change Reduced cost of change to completed storiesContinuing with Agile throughout life-cycle reduces Total Cost of Operation significantly

  • Eliminating waste - LeanOnly software that is actually being used has the opportunity to deliver valueNo unnecessary analysis/design:Detailed analysis/design for stories in current iteration onlyUnderstand just enough to produce high quality, working softwareNo unnecessary software:Business can change/discard stories at any time Stories are units of business value No software embellishment:Only software required to pass test is developedDocumentation fit for purpose: Only produce documentation needed to produce codeUnless for specific business need [legal, knowledge transfer etc.]

  • Planning versus ExecutionContinuous ImprovementPlanningExecution

  • User StoryA user story is a basic unit of work in an agile projectDescribes a desired piece of business functionalitySmall enough to be implemented in an iterationUsually completed in a couple of days (1,3 or 5 days)A good user story is the simplest statement about the system that:The customer cares aboutTest cases can be written to verifyCan be reasonably estimatedCan be reasonably prioritized

    One story

  • An IterationAn iteration is a collection of stories the team commits to delivering in a fixed period of time Typically 2-4 weeksEvery iteration, the team commits to delivering the stories chosen by the customer10 15 Stories

  • A ReleaseA release is a collection of user stories describing the first release of the systemTypically 3 4 months in duration

    50 - 100 Stories

  • Velocity How fast are we going?Velocity is the measure of how many stories the team typically completes during an iterationVelocity is a unit of effortHow many story points did we get done last iteration Measure using Yesterdays WeatherWe dont guess how much we will get doneWe measure

  • Backlogs, Releases and Sprints

  • Anatomy of an IterationIteration Kick-Off Meeting(fixed date)Domain Experts/Analysts Explain story cardsQA Review test scripts and story cardsDevelopers Define and estimate tasksIteration PlanningDomain Experts/Analysts/QA Prepare iteration narratives & test scriptsDevelopers Review story cards/testsIteration Close Meeting(fixed date)Everyone Review, report and refine processIteration Planning MeetingIteration N-1Iteration NIteration N+1

  • Reference LibraryPlanning Extreme ProgrammingKent Beck, Martin FowlerLean Software DevelopmentMary PoppendieckAgile Project Management with ScrumKen SchwaberUser Stories AppliedMike CohnLessons Learned in Software TestingCem Kaner, et al.Extreme Programming Explained v2Kent BeckTest Driven DevelopmentKent BeckRefactoringMartin Fowler, et al.

    Internal forces cause business to changeInternal forces cause business to changeDynamic Systems Development Method (DSDM)Industry standard RAD methodology (1994)Feature Driven Development - Peter CoadCrystal Family - Alistair Cockburn

    NB. Collaborative Focus manifests as Collective Ownership and Pair