a practical agile approach for a non agile environment

By Murray Robinsonwww.linkedin.com/in/murrayrobinson

Copyright 2009-2010, Murray J Robinson

1

A practical Agile approach for a non Agile environment

http://www.linkedin.com/in/murrayrobinson

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;


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;


4

You can tailor Agile methods to work in a traditional process heavy environment!



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



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



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.



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.


9

How did we do it?



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



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



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



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



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



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



16

Iteration plan



17

The Feature Log

17

A feature is a business requirement or story that can be delivered in one iteration



18

Feature Log in Quality Centre



19

A single feature



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



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.



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



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



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

a practical agile approach for a non agile environment

Documents

murray robinson

murray j robinson

development team

project team copyright

agile environment

experienced agile team

end copyright

little agile capability