a practical agile approach for a non agile environment
DESCRIPTION
A practical Agile approach for a non agile environment. A real life success story applying Agile methods in a large corporate with high process and software development outsourced, offshore, with no automation.TRANSCRIPT
By Murray Robinsonwww.linkedin.com/in/murrayrobinson
Copyright 2009-2010, Murray J Robinson
1
A practical Agile approach for a non Agile environment
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
2 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
2
Agile Project Requirements
Agile implementations focusing on Scrum and Extreme Programming usually require that:
• You don’t have to follow formal PMBOK or Prince2 processes;
• You don’t need to produce much formal documentation;
• Everyone works in one room; including the Business SME’s;
• All key players including SME’s are full time;
• The project team is small – 10 to 20 people;
• The development team is in house or if outsourced can work in house or if external is an experienced Agile team;
• The development team can automate all tests;
• The development team can build and integrate continuously;
• Infrastructure groups and Interfacing systems can deliver supporting changes quickly;
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
3
What if your environment is not ideal for Agile?
• You have to follow formal PMBOK or Prince2 processes;
• Business and technical team members are in different cities, countries and time zones
• Business SME’s are only available part time
• You are required to use an outsourced, offshore software developer with little Agile capability;
• The team does not have the capability to automate all of their tests or to integrate continuously
• Infrastructure groups and Interfacing systems have very long lead times;
• Significant documentation is required for support groups and the next project team;
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
4
You can tailor Agile methods to work in a traditional process heavy environment!
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
5 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
5
A real life example
• A large company with a heavy PMBOK waterfall software development process
• Software development outsourced to a large Indian company with little Agile capability
• Very complex environment with a large number of interfacing systems
• IT had just delivered a $30M+ online transformation program that took 18 months and had 200+ people working on it at peak
• After delivery the Business asked IT to deliver substantial functional and performance enhancements to three projects with remaining budget before the end of the Financial year just 3 months away
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
6 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
6
Solution• Implement an iterative, feature driven, design and development
approach within the existing PMBOK process framework
• Define a small number of general, high level change requests to provide formal process coverage
• Develop a prioritized feature backlog with business
• Engage the vendor on a fixed time, capped cost, flexible target scope contract with deliverables defined around features
• Divide work up into 3 week iterations of analysis, build and test with 3 iterations running at the same time
• Use HP Quality Centre to manage iterations
• Use funding left over from the main program
• Update existing system documents at the end
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
7 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
7
Results
Project Time Cost Benefits Delivered
Standard Agile Standard Agile
Project 1 16 wks 8 wks $500K $450K 16 requirements deployed to production in 8 weeks
Project 2 16 wks 14 wks $400K $350K 4 features deployed after 4 weeks, 12 more deployed after 10 weeks and 16 more deployed after 14 weeks
Project 3 36 wks 8 wks $1.1M $300K 70%+ performance increase to core purchasing processes deployed to production in 8 weeks
Standard project time and cost are based on similar previous projects or based on vendor estimates before Agile applied.
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
8 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
8
Results cont
• Much lower risk because requirements are delivered every week to UAT instead of in one big bang in the last few days
• SIT and UAT pass rate increased from 50% to 90% which meant that rework dropped dramatically and the chance of a blowout reduced
• The business was able to easily introduce and re-prioritise new requirements ahead of lower priority requirements during development.
• The cost of delivering some (but not all) requirements was lower.
• Communication with offshore developers was much better and overall the team took more responsibility and was happier.
• Business, IT and the vendor worked much better together.
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
9
How did we do it?
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
10 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
10
Aim to deliver high value features rapidly
10
0123456789
10
1 2 3 4 5 6 7 8 9 1011121314151617181920
0102030405060708090100
Features
Total BusinessValue
75%
Bu
sin
ess
Va
lue
Release
Iteration
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
11 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
11
Iterative Feature Driven Approach
11
Deliver small batches of features in short, regular, overlapping iterations - Jeff Sutherland’s Scrum B approach
Design, Build &
Test
Design, Build &
Test
Design,Build &
Test
Design,Build &
Test
Release 1 Release 2
UAT & Deploy
UAT & Deploy
UAT UAT
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Analysis & Design
Analysis & Design
Analysis & Design
Analysis & Design
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
12 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
12
Tailor the standard process
Other Processes, Deliverables and Reviews
Process Phase
Tailoring explanation
Project Delivery Overview D&B A PowerPoint pack describing an iterative project management and delivery approach to key stakeholders and project team. Replaces the traditional Project Management Plan.
Iterative Project Schedule D&B An MS Project Schedule defining the projects iterative plan
Requirements captured in Quality Centre
D&B Requirements for each feature are defined in QC requirements section. Also known as user stories.
Updated Solution Architecture D&B An updated Solution Architecture will be delivered at the end of the release to provide a system description for the next project team. Client Architect to approve.
Updated System Requirements D&B An updated set of use cases will be delivered at the end of the release to provide a process description for the next project team. Client Lead analyst to approve.
Test Cases for each Requirement
D&B Test Cases captured and mapped to Requirements in QC. Approved by Test Manager.
Test Summary Report D&B A standard summary of test cases, results and outstanding defects
Updated Support Plan D&B An updated support plan will be delivered at the end of the release to provide updated information for the application support team. Approved by Application Manager.
Updated Operations Guide D&B An updated operations guide will be delivered at the end of the release to provide updated information for the application support team. Approved by Application Manager.
Deployment Run list D&B A spreadsheet defining deployment tasks, assignments, timing and contacts
Delivery Retrospective SI Captures lessons learned with input from the team.
• Use the process tailoring process to tailor out standard deliverables and tailor in agile alternatives
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
13 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
13
Use a variable scope contract
The scope of this SOW is to improve the functionality and performance of the application in production as much as possible by 30th June 2010.
Key Points:
• Fixed Budget: capped at $XXXK
• Fixed Time: Start XXXX, End XXXX; In production by 30th June.
• Fixed Resource Team: the vendor is to provide a named team of people to achieve these objectives.
• Variable Scope: the target scope is to implement CR’s XX
• Iterative feature driven design and development approach
− Scope is broken down into a series of features to be defined in detail.
− The number, scope, effort and timing for delivery of these features will be agreed jointly between the vendor and the client during the course of the project based on business priorities and remaining time and budget.
− The scope is capped within the budget and time defined above.
1313
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
14 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
14
Traditional Team Structure
Business Project
Manager
Business BA IT Project Manager
Business SME’s
IT Business Analyst
Onshore Vendor Project
Manager
Onshore Vendor
Module Lead
IT Architect IT Technical
SME
Offshore Vendor Project
Manager
Vendor Architect
Vendor Module Lead
Vendor Module Lead
Vendor Functional Test Lead
Vendor Performance
Test Lead
IT Test Manager
IT Application Manager
Developers Developers Test AnalystsPerformance Test Analysts
Simplified view that does not include Program Managers, GM’s and others
Offshore
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
15 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
15
Project Plan
ID Task Name Duration Start Finish
1 Enterprise Portal Release 2.1 38.18 days Wed 5/05/10 Fri 2/07/10
2 Dependencies 2 days Tue 18/05/10 Fri 21/05/10
3 UAT environment readiness 2 days Tue 18/05/10 Fri 21/05/10
4 Engaging R&E PSNM environment 0 days Tue 18/05/10 Tue 18/05/10
5 Validating and setting R&E data setup 2 days Tue 18/05/10 Fri 21/05/10
6 Iteration 1 17 days Wed 5/05/10 Mon 31/05/10
14 Iteration 2 18 days Wed 12/05/10 Wed 9/06/10
22 Iteration 3 18 days Thu 20/05/10 Wed 16/06/10
30 Iteration 4 19 days Thu 27/05/10 Fri 25/06/10
38 Code merge & lockdown 1 day Fri 25/06/10 Mon 28/06/10
39 Document finalisation 6 days Mon 21/06/10 Tue 29/06/10
40 List of outstanding defects after code lockdown 1 day Mon 21/06/10 Tue 22/06/10
41 Requriement Documents 6 days Mon 21/06/10 Tue 29/06/10
47 Design documents 6 days Mon 21/06/10 Tue 29/06/10
52 Other Documents 3 days Mon 21/06/10 Thu 24/06/10
56 Final regression testing 3 days Mon 28/06/10 Thu 1/07/10
57 deployment to production 0 days Fri 2/07/10 Fri 2/07/10
18/05
2/07
5 8 11 14 17 20 23 26 29 1 4 7 10 13 16 19 22 25 28 1 4 7 10 13 16 19 22 25 28 31 3May 2010 June 2010 July 2010 August 2010
Project 1
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
16 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
16
Iteration plan
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
17 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
17
The Feature Log
17
A feature is a business requirement or story that can be delivered in one iteration
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
18 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
18
Feature Log in Quality Centre
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
19 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
19
A single feature
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
20 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
20
Acceptance Test Driven Development• Use a manual Acceptance Test Driven Design and Development approach
• In the Analysis and Design phase the:
− Test analyst writes acceptance test cases.
− Business reviews and approves acceptance tests
• Acceptance Testing
− One test repeated for system, integration and user acceptance test
− Developers execute acceptance test cases in integration environment and fix any defects immediately.
− the vendor Test analyst executes acceptance test cases and developers fix problems immediately.
− Business SME executes acceptance test cases and developers fix problems immediately.
• Targeted regression test before deployment
• SIT and UAT pass rate increased from 50% to 90% which meant that rework dropped dramatically
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
21 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
21
Project Communications
Managing Team Distribution and Time Zones
• Evenings
− Offshore Vendor PM meets with their team to discuss what they did that day, what the plan is for the next day and the issues they are having
− Offshore Vendor PM writes this up and sends to onshore team
• Mornings
− PM meets with onshore Vendor PM & Tech SME lead to discuss what the combined team did yesterday, what the plan is for today, the issues and actions to resolve them
• Afternoons
− The onshore and offshore business and technical teams meet via Teleconference and Live meeting to discuss progress, requirements, design, testing and issues.
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
22 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
22
Project Communications cont
Managing Interfacing Parties
• Two to three times a week
− Managers and module leads meet with each interfacing system manager and vendor
Collaboration Tools
− Quality Centre, Email, LiveMeeting
Project Management Tools
− Quality Centre to track work, document the requirements, solution, test cases and test results
− PM produces a two page report weekly for management
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
23 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
23
Challenges• Requires Project and Test Managers, Architects and BAs to be :-
− hands on
− make fast decisions with less documentation and
− resolve issues quickly
• Need to resist requests to extend iterationa to fix extra defects or do more complex changes.
− move extra work to later iterations
• Concerns that less formal documentation and review processes will lead to low quality and problems for future projects
− Overcome by stakeholders seeing features pass in UAT
− Document requirements and design in QC
− Update other required documentation at the end
Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
24 Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
24
Challenges cont
• More code branches and deployments lead to more code merging and management which can cause delays and rework
− employ better code management software e.g. Harvest or Subversion
• Distributed team with 70% team offshore and onshore team in different cities and buildings
− Scrum facilitated through daily team teleconferences
• Vendor has limited test automation capabilities and facilities
− Do more manual testing
• Constraints due to very long delivery times from Infrastructure and Identity Management groups
− Remove requirements that depend on these groups