Introducing Agile Processes into a Waterfall Organisation

Chris Cooper-Bland, Senior Architect @ Endava Ltd

Agenda

What is Agile Refresher What makes Organisations Waterfall? Introducing Change

Change the process Change the Organisation

What works Summary and Q&A

How many of your organisations are using agile currently? How many are planning to?
2

Delivering business value is hard

Of the work executed: Many (possibly most) organisations lose as much as 45% of their total revenues due to costs associated with low quality

Six Sigma

Some 75 percent of most large-scale J2EE projects fail by missing both time and budget projections

Mark Driver, Gartner

64% of features actually delivered are either rarely or never used

Jim Johnson, Standish Group

3

Brief History of Development Methodologies

Methodologies
AGILE e.g. XP (Kent Beck)

WATERFALL (Royce) Requirements, design implementation, verification & maintenance Waterfall

RUP (Rational) user Incremental, driven, low process RAD Object oriented, (James Martin) iterative, time-boxed, user driven RUP Prototyping, iterative, time-boxed, user driven RAD SPIRAL MODEL (Barry Boehm) V-MODEL (Anon) Iterative Spiral Model Aligns testing to Waterfall development V-Model

1960

1970

1980

85

91

98 99

Agile Misconceptions?

Agile means:

letting the programming team do whatever they need to with no project management, and no architecture, allowing a solution to emerge, the programmers will do all the testing necessary with Unit Tests

What is Agile?

http://www.agilemanifesto.org/
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Management can tend to value the things on the 6 right over the things on the left

Agile project management SCRUM

Team-Level Planning
Every 24hrs

Daily Scrum Meeting: 15 minutes

Each teams member answers 3 questions: 1) What did I do since last meeting? 2) What obstacles are in my way? 3) What will I do before next meeting?

Every Iteration 4-6 weeks

Prioritised Iteration Requirements Scope

Working Software Delivered

Requirements Requirements Requirements Requirements

Prioritised Requirements & Features Backlog Applying Agile: 7 Continuous integration; continuously monitored progress

Agile - XP explained (1)

The Values Communication Simplicity Feedback Courage Respect

(added in the latest version)

Agile - XP explained (2)

1. 2.

3.

Test First Programming Test First without code The Planning Game - Business Stories - Customer decides, Prog. Implements Small, Frequent Releases
- Release early and release often

7.

8. 9. 10.

4.

5.

6.

Always use the Simplest design that adds business value System Metaphor - Programmers define a handful of classes and patterns that shape the core business problem and solution - Like a primitive Architecture On-site Customer - Customer has authority to define functionality - encourages face-to-face dialogue

11.

12.

Refactoring Restructuring code without changing its functionality - Mainly Simplification Pair Programming Collective Code Ownership Coding Standards - Everyone should use the same coding styles. Continuous Integration - At least a few times a day - All unit tests must pass prior to integration - All functional tests must pass afterwards Forty Hour Week ! - Tired programmers write poor code and make more mistakes

Water Fall Organisations

Accounting system annual accounts, monthly returns Legal and regulatory controls Shareholders 3 year plans, annual plans Interface with other organisations SLAs Reward System, annual event not immediate
10

Random Example

11

From Northern Constabulary

Approach to Change

Models to introduce change into the organisation

Incremental approach Step change Thin threads

Scope of change island or wholesale Prerequisites for change Blockers & enablers - timing

Key influencers Other changes Disasters

12

What to change Best Practices

Most Useful

Collaborative working Iterative projects Visual Modelling Risk based prioritisation Requirements Management Change Management Configuration Management Tools Traceability
13

Least Useful

Factors for Success

Choose the right project

Size Importance visibility

Get buy-in of senior management Communicate to all Use experienced people Dont trust blindly
effort = people * environment *size
- Walker Royce
14

(process)

Common sense no silver bullets

Changing the process Integrating the method

Advantages

Single place to look Easy alignment People already understand parts May lead to confusion External staff dont know it Overlaps and/or gaps
15

Disadvantages

Customising the method

Industry Level Industry Standards.
ISO 12207,SW-CMM)
(e.g.

Standard Method specification

Industry Methods development

(e.g. Iterative, Agile)

Project Assurance
(monitoring adherence to process and feedback for Software process improvement)

Organisations Software Engineering group

Macro-level tailoring

Organisational Level

Organisational Tailoring of Method

Micro-level tailoring

Project Level

Project defined process documented in some form

16

Changing the organisation

People Team rewards Celebrate success Leadership management must ask the right questions Communication, brown bags etc. Understand perceptions of success, what does finished mean? Quality/stage gates Senior Management control Estimating and budgeting Real options Portfolio planning Structure of the organisation
17

Estimating

This will prove problematic Identify an approach early, keep reviewing it Ideal model is to use a model calibrated with the actuals captured from your organisation, but . Use model with someone else's metrics Use Industry model

CoComo II Function point analysis

Guess Planning game is usually too late to help

18

The Budgeting Problem

The Cone of Uncertainty

Source McConnell 1998

19

Addressing it
Convince management to make a fixed investment to establish costs

Source McConnell 1998

20

Application Project Portfolios

Senior management must give authority and control to IT Use a portfolio management approach

Programme portfolio management

Define portfolio segments Apportion available budget Revalidate at stage gates, for balance and progress
21

Proven proof of Concepts

Stage gate 3

Stage gate 2 Stage gate 1

Real Options a way of thinking

Based on commodity options right but not an obligation to buy at a point in the future Investment is continued only in favourable conditions, use probability models to predict future likelihood of return Can hedge different investments Allows management to be in control Share holders like it
22

Structure Skunk Works

Lockhead Martin needed to develop secret projects, outside formal control Formed in June 1943 Burbank CA 14 rules to ensure efficiency similar to XP principles Now seen as technique for introducing change but
23

Structure - Radical Changes

Change the company structure of the organisation

XP

No Change
Agility required

Create new spin-off company Joint venture Acquisition

Waterfall Bureaucracy Dynamic

Change the internal structure

New ventures department New project teams

24

Existing Structure

Dont do this if you want to fail

Use integrated teams Sort out the development environment early Choose tools carefully Enterprise architecture is important for large/long lived systems One person needs to own the process vision with support from many Use partners experienced in the method
25

What Works Well

Configuration and change management, continuous integration Selling the method

Books, presentations etc.

Immersion for the project Briefings for the rest of the company

Make them want it too

26

Summary

The organisation will have to change too More you have to change the harder it is

27

Resources

Craig Larmans books http://www.bcs-spa.org/ http://www.dsdm.org/ http://www.realoptions.com/

28

Conclusion & Questions

Contact Details
Chris Cooper-Bland Senior Architect Chris.cooperbland@endava.com

29