Making Agile Work For Large ProjectsMark Drysdale
AgendaTraditional DeliveryWhat is AgileScrumCase Study – Company XHistoryPilotRollout2
The Risks of Software Development	Delivering too little, too lateDiscovering functional needs late in the projectBuilding the right things wrongBuilding more than you needAdding complexity which leads to non-maintainabilityPoor quality softwareSoftware buggySoftware not maintainable
Industry Statistics
Agile is … the MethodsAGILELean ThinkingQueuing TheoryTheory of ConstraintseXtreme Programming (1996)Scrum (2001)DSDM (1995)Feature Driven Development (1997)Crystal (mid 1990s)Kanban (2008 ish)AUP/OpenUPLean Software Development (2003)
Contrasting Waterfall with AgileAnalysisDesignCodeTestDeployWaterfallTimeAnalysisAnalysisAnalysisAnalysisDesignAnalysisArchitectureReleasableReleasableReleasableDeployDesignDesignDesignCodeCodeCodeCodeAgileTestTestTestTest
The Scrum ProcessDaily ScrumMeeting24hoursSprint reviewSprintBacklog tasksexpandedby teamSprint PlanningSprintBacklogPotentially ShippableProduct IncrementProduct BacklogAnyone can contribute itemsPrioritized by Product Owner
Company XCompany X spent £100 million on tech refresh and consolidation80 legacy system consolidated to 1All other major projects suspended for 4 yearsWas it a Success?It has enabled Company X to take the next step...But...2 years late500+ defects in LiveBacklog of over 200 Change RequestsBusiness has had to accept over 150 manual work aroundsNew CTOPreviously experience with Scrum at …Dictated that 4 Project would be run as Scrum in first yearCommercial in Confidence8Why Change?
Company X – PilotCommercial in Confidence9Ideal Agile Project Candidate Checklist
Company X Pilot – Providers OnlineFirst major web initiativeJava based CMSJava Struts portlets.Netwebservices.Net backendOracle Database12 Month projects£2.2 million budgetTeam of 22Java and .Net teams had never worked togetherTesters from 3 suppliersProject in total had 6 different suppliersOnly 3 Company X permanent membersDisengaged Product OwnerCommercial in Confidence10What????
Company X Pilot – Providers OnlineCo-located everyone!Moved out to another buildingCreated our own build serversOwn code branchImplemented CI for JavaManual daily builds for .NetCreated our own System Test Environments2 Scrum teamsCross functionalScrum Master3 Java2 .Net1 Html1 Business Analyst2 Manual testers1 Automation TesterCommercial in Confidence11First Steps
Company X Pilot – Providers OnlineComplete UAT 2 weeks earlyOrder of magnitude less defects discovered in UATDelivered on time and under budget£1.9 millionCommercial in Confidence12What a Success!
Resolves conflicts
Identifies cross-team dependencies
Escalate dependencies
Coordinate technical issues
Aids integrationBusiness FocusProjectManagerTechnicalCoordinatorScrum of ScrumsTeam Rep.Team Rep.Solution FocusTeam Rep.Management FocusCompany X Rollout – Scaling ScrumScrumMasterProductOwnerScrumMasterProductOwnerScrumMasterProductOwnerScrumTeamScrumTeamScrumTeamFocus on business aspects
Resolves backlog dependencies and conflicts
Enables prioritisation across teams
Shields teams from conflicting change
Ensures single visionProductOwnerProductOwnerProduct Owner GroupProductOwnerProductOwner
Company X Rollout Technical EnablersMigrated from MKS to Microsoft TFS

Alm Agile In Large Projects V2

  • 1.
    Making Agile WorkFor Large ProjectsMark Drysdale
  • 2.
    AgendaTraditional DeliveryWhat isAgileScrumCase Study – Company XHistoryPilotRollout2
  • 3.
    The Risks ofSoftware Development Delivering too little, too lateDiscovering functional needs late in the projectBuilding the right things wrongBuilding more than you needAdding complexity which leads to non-maintainabilityPoor quality softwareSoftware buggySoftware not maintainable
  • 4.
  • 5.
    Agile is …the MethodsAGILELean ThinkingQueuing TheoryTheory of ConstraintseXtreme Programming (1996)Scrum (2001)DSDM (1995)Feature Driven Development (1997)Crystal (mid 1990s)Kanban (2008 ish)AUP/OpenUPLean Software Development (2003)
  • 6.
    Contrasting Waterfall withAgileAnalysisDesignCodeTestDeployWaterfallTimeAnalysisAnalysisAnalysisAnalysisDesignAnalysisArchitectureReleasableReleasableReleasableDeployDesignDesignDesignCodeCodeCodeCodeAgileTestTestTestTest
  • 7.
    The Scrum ProcessDailyScrumMeeting24hoursSprint reviewSprintBacklog tasksexpandedby teamSprint PlanningSprintBacklogPotentially ShippableProduct IncrementProduct BacklogAnyone can contribute itemsPrioritized by Product Owner
  • 8.
    Company XCompany Xspent £100 million on tech refresh and consolidation80 legacy system consolidated to 1All other major projects suspended for 4 yearsWas it a Success?It has enabled Company X to take the next step...But...2 years late500+ defects in LiveBacklog of over 200 Change RequestsBusiness has had to accept over 150 manual work aroundsNew CTOPreviously experience with Scrum at …Dictated that 4 Project would be run as Scrum in first yearCommercial in Confidence8Why Change?
  • 9.
    Company X –PilotCommercial in Confidence9Ideal Agile Project Candidate Checklist
  • 10.
    Company X Pilot– Providers OnlineFirst major web initiativeJava based CMSJava Struts portlets.Netwebservices.Net backendOracle Database12 Month projects£2.2 million budgetTeam of 22Java and .Net teams had never worked togetherTesters from 3 suppliersProject in total had 6 different suppliersOnly 3 Company X permanent membersDisengaged Product OwnerCommercial in Confidence10What????
  • 11.
    Company X Pilot– Providers OnlineCo-located everyone!Moved out to another buildingCreated our own build serversOwn code branchImplemented CI for JavaManual daily builds for .NetCreated our own System Test Environments2 Scrum teamsCross functionalScrum Master3 Java2 .Net1 Html1 Business Analyst2 Manual testers1 Automation TesterCommercial in Confidence11First Steps
  • 12.
    Company X Pilot– Providers OnlineComplete UAT 2 weeks earlyOrder of magnitude less defects discovered in UATDelivered on time and under budget£1.9 millionCommercial in Confidence12What a Success!
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
    Aids integrationBusiness FocusProjectManagerTechnicalCoordinatorScrumof ScrumsTeam Rep.Team Rep.Solution FocusTeam Rep.Management FocusCompany X Rollout – Scaling ScrumScrumMasterProductOwnerScrumMasterProductOwnerScrumMasterProductOwnerScrumTeamScrumTeamScrumTeamFocus on business aspects
  • 18.
  • 19.
  • 20.
    Shields teams fromconflicting change
  • 21.
    Ensures single visionProductOwnerProductOwnerProductOwner GroupProductOwnerProductOwner
  • 22.
    Company X RolloutTechnical EnablersMigrated from MKS to Microsoft TFS
  • 23.
    Cut build timefrom hours to 10 min
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
    QTP Pack takes7 hours to run
  • 33.
    Multiple serversScaling ChallengesMovingfrom optimal single team poses challengesDistributed/dispersed teamsface-2-face communication compromisedplanning, retrospectives and other meetings difficulttimezone differences can introduce delaysMultiple teamsteam structure: feature/component/hybrid?communication and coordination between teamspotential for wasteful activity – hand-offs, delays etc.dependencies across teamsare distributed by default, even if only within the same buildingSprint synchronisationsoftware/system integration across teamsusually requires extra coordination and planning activity and roles
  • 34.
    Distributed Scrum -How to ramping upCell based replication
  • 35.
    Distributed Scrum -How to ramping upDistribute first team
  • 36.
    Distributed Scrum -How to ramping upDistribute second team
  • 37.
    Distributed Scrum -How to ramping upSeed third team from members of first teams
  • 38.
    Distributed Scrum -EnablersVideo conferencingFor daily stand upsPlanning RetrospectivesDigital Scrum boardsWiki and online velocity chartsScrum teams in offices/grouped desksOffshore/Onshore ExchangeContinually moving team members between locations
  • 39.
    How will yousucceed?Prioritise accuratelyProvide appropriate responses to impedimentsFocus on key practicesHave the right teamA SCRUM Master who can drive the project
  • 40.
  • 41.
  • 42.
    Pitfalls – Whatwill prevent success?Lack of commitmentFrom IT – looking for the benefits of agile without the cost of changeFrom the business – paying lip-service to the change with an inappropriate Product OwnerDriving from the wrong directionThe agile transition is a change in the relationship between IT and the businessLack of understandingRigidly applying all aspects of a methodology, even when they prove to be detrimentalAdapting agile practices to suit existing processes, teams, documents and standardsHaving unrealistic expectationsTransitioning to agile is not an overnight processIn SCRUM, the first Sprint for a new, blended team should be expected to fail

Editor's Notes

  • #13 SR3:7 weeks, 27 developers = 945 developer daysDefects raised by UAT = 420 defects Provider Online:1152 developer daysDefect raised by UAT = 150 defects
  • #22 Prioritise accuratelyTo realise value as soon as possiblePrioritise highest value items early onProduct Increments are all production-qualityProvide appropriate responses to problemsNo wasted effort on unnecessary areasDocumentation at the right level in the right placesTechnical solutions which are just good enoughFocus on key practicesQuality of the product deliverablesVisibility of the Product Backlog ItemInspect and adapt – with every SprintHave the right attitudeRealise that agile processes are people-drivenBuy-in leads to project successProject success promotes buy-in across the businessHave the right teamA Product Owner with clear vision and clear authorityFirst commitment is the projectCan answer questions quickly and definitelyBought-in to the SCRUM processA SCRUM Master who can drive the projectEnsuring the smooth working of the teamRunning workshops to drive out the Product BacklogCommunicating the processes and benefits to the wider business communityAn Architect who can drive the solutionMaking the right technology choicesMentoring team members in the development process and the solutionA committed development teamKeen to learn new technologies and approachesBought-in to the SCRUM processKnowledgeable testersWith product and domain knowledgeCommunicating effectively with the development team
  • #23 Lack of commitmentFrom IT – looking for the benefits of agile without the cost of changeProviding resources with other project commitmentsFailing to remove impediments quickly and effectivelyFrom the business – paying lip-service to the change with an inappropriate Product OwnerDriving from the wrong directionThe agile transition is a change in the relationship between IT and the businessToo often it is IT-driven, decided in advance and then presented to the businessTo the business, it’s just another IT initiative Lack of understandingRigidly applying all aspects of a methodology, even when they prove to be detrimentalAdapting agile practices to suit existing processes, teams, documents and standardsPicking and choosing agile practices without experience of their benefits and costsIn SCRUM, the project team should be hosted in one location. Co-location is an option can but can severely limit velocityTest-Driven Development in XP is a complete change in the development processHaving unrealistic expectationsEstablished agile teams to do deliver higher quality systems in less timeTransitioning to agile is not an overnight processIn SCRUM, the first Sprint for a new, blended team should be expected to fail