Post on 20-Aug-2015
© Copyright 2009 Hitachi Consulting
www.hitachiconsulting.com
Making Agile Work For Large ProjectsMark Drysdale
© Copyright 2009 Hitachi Consulting
Agenda
Traditional Delivery
What is Agile
Scrum
Case Study – Company X
History
Pilot
Rollout
2
© Copyright 2009 Hitachi Consulting
The Risks of Software Development
Delivering too little, too late
Discovering functional needs late in the project
Building the right things wrong
Building more than you needAdding complexity which leads to non-maintainability
Poor quality softwareSoftware buggySoftware not maintainable
© Copyright 2009 Hitachi Consulting
Industry Statistics
44%
32%
24%
2009 Standish Group CHAOS Report
Challenged(late, over budget)
Succeeded (on-time, on budget)
Failed (cancelled or abandoned)74%
16%
10%
Oxford University IT Project Success 2003
Challenged(late, over budget)
Succeeded (on-time, on budget)
Failed (cancelled or abandoned)
Dynamic Markets Limited 2007 Study
IT projects that failed to meet their schedules 62%
Budget overruns 49%
Higher-than-expected maintenance costs 47%
Failed to deliver expected business value and ROI 41%
Software and services projects are cancelled before completion 25%
© Copyright 2009 Hitachi Consulting
Agile is … the Methods
DSDM (1995)Scrum (2001)
Kanban (2008 ish)
Lean Software Development (2003)
Crystal (mid 1990s)Feature Driven
Development (1997)
eXtreme Programming
(1996)
AUP/OpenUP
Lean ThinkingQueuing Theory
Theory of Constraints
© Copyright 2009 Hitachi Consulting
Contrasting Waterfall with Agile
Time
Wat
erfa
ll
Agile
Ana
lysi
s
Des
ign
Cod
e
Test
Dep
loy
An
alys
isA
rchi
tect
ure
Rel
easa
ble
Rel
easa
ble
Rel
easa
ble
Dep
loy
Analysis
Design
Code
Test
Analysis
Design
Code
Test
Analysis
Design
Code
Test
Analysis
Design
Code
Test
© Copyright 2009 Hitachi Consulting
The Scrum Process
SprintBacklog
Sprint
24hours
Sprint Planning
Product BacklogAnyone can contribute itemsPrioritized by Product Owner
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
Spr
int
revi
ew
© Copyright 2009 Hitachi ConsultingCommercial in Confidence 8
Company X
Company X spent £100 million on tech refresh and consolidation80 legacy system consolidated to 1All other major projects suspended for 4 years
Was it a Success?It has enabled Company X to take the next step...But...
2 years late 500+ defects in Live Backlog of over 200 Change Requests Business has had to accept over 150 manual work arounds
New CTOPreviously experience with Scrum at …
Dictated that 4 Project would be run as Scrum in first year
Why Change?
Click to add logo
© Copyright 2009 Hitachi ConsultingCommercial in Confidence 9
Company X – Pilot
Ideal Agile Project Candidate Checklist
Click to add logo
Attribute Criteria CommentScrum Team Co-locatedProject Importance
High This would give incentive to the team to work well with the process to ensure the success of the project. A low-importance, low risk project usually becomes just a learning project.
Duration 3 - 6 months Big enough so the Delivery Phase has a couple of releases containing 2-3 iterations
Team Size 4 – 6 Developers The project should be small enough to be done by one team. This removes the multi team and cross communication challenges
Testers Experience
High Knowledgeable testers with product and domain knowledge
Product Owner Knowledgeable and committed
A Product Owner with clear vision and clear authority whose first commitment is the project and can answer questions quickly and definitely
Scrum Master Experienced Previous Agile project experience
Business Sponsor
Engaged An engaged business sponsor can help the team if it needs to push against entrenched business processes, departments, or individuals.
© Copyright 2009 Hitachi ConsultingCommercial in Confidence 10
Company X Pilot – Providers Online
First major web initiativeJava based CMSJava Struts portlets.Net webservices.Net backendOracle Database
12 Month projects
£2.2 million budget
Team of 22Java and .Net teams had never worked togetherTesters from 3 suppliersProject in total had 6 different suppliersOnly 3 Company X permanent members
Disengaged Product Owner
What????
Click to add logo
© Copyright 2009 Hitachi ConsultingCommercial in Confidence 11
Company X Pilot – Providers Online
Co-located everyone!Moved out to another building
Created our own build serversOwn code branchImplemented CI for JavaManual daily builds for .Net
Created our own System Test Environments
2 Scrum teamsCross functional
Scrum Master 3 Java 2 .Net 1 Html 1 Business Analyst 2 Manual testers 1 Automation Tester
First Steps
Click to add logo
© Copyright 2009 Hitachi ConsultingCommercial in Confidence 12
Company X Pilot – Providers Online
Complete UAT 2 weeks early
Order of magnitude less defects discovered in UAT
Delivered on time and under budget£1.9 million
What a Success!
© Copyright 2009 Hitachi Consulting
Scrum of Scrums
ScrumMasterScrumMaster
ScrumTeam
ScrumTeam
ProductOwner
ProductOwner
TechnicalCoordinator
TechnicalCoordinator
Business Focus
Solution Focus
Management Focus
Company X Rollout – Scaling Scrum
ScrumMasterScrumMaster
ScrumTeam
ScrumTeam
ProductOwner
ProductOwner ScrumMasterScrumMaster
ScrumTeam
ScrumTeam
ProductOwner
ProductOwner
Team Rep.Team Rep.
Team Rep.Team Rep.
Team Rep.Team Rep.
ProjectManager
ProjectManager
ProductOwner
ProductOwner
ProductOwner
ProductOwner
ProductOwner
ProductOwner
ProductOwner
ProductOwner
Product Owner Group
•Resolves conflicts•Identifies cross-team dependencies•Escalate dependencies•Coordinate technical issues•Aids integration
•Focus on business aspects•Resolves backlog dependencies and conflicts•Enables prioritisation across teams•Shields teams from conflicting change•Ensures single vision
© Copyright 2009 Hitachi Consulting
Company X Rollout
Migrated from MKS to Microsoft TFSCut build time from hours to 10 min
Continuous Integration10-15 builds a dayTDD
MsTestRhino Mocks
Automation of BuildNightly Builds and Deployments
Automation of Regression testsQTP Pack takes 7 hours to run
Multiple servers
Technical Enablers
© Copyright 2009 Hitachi Consulting
Scaling Challenges
Moving from optimal single team poses challengesDistributed/dispersed teams
face-2-face communication compromisedplanning, retrospectives and other meetings difficulttimezone differences can introduce delays
Multiple 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
© Copyright 2009 Hitachi Consulting
Distributed Scrum - How to ramping up
Cell based replication
© Copyright 2009 Hitachi Consulting
Distributed Scrum - How to ramping up
Distribute first team
© Copyright 2009 Hitachi Consulting
Distributed Scrum - How to ramping up
Distribute second team
© Copyright 2009 Hitachi Consulting
Distributed Scrum - How to ramping up
Seed third team from members of first teams
© Copyright 2009 Hitachi Consulting
Distributed Scrum - Enablers
Video conferencingFor daily stand upsPlanning Retrospectives
Digital Scrum boardsWiki and online velocity charts
Scrum teams in offices/grouped desks
Offshore/Onshore ExchangeContinually moving team members between locations
© Copyright 2009 Hitachi Consulting
How will you succeed?
Prioritise accurately Provide appropriate responses to impediments
Focus on key practices
Have the right team
A SCRUM Master who can drive the project
A committed development team
Knowledgeable testers
Have the right attitude
Click to add logo
© Copyright 2009 Hitachi Consulting
Pitfalls – What will 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 Owner
Driving from the wrong directionThe agile transition is a change in the relationship between IT and the business
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 standards
Having unrealistic expectationsTransitioning to agile is not an overnight processIn SCRUM, the first Sprint for a new, blended team should be expected to fail
Click to add logo