Introducing Agile Processes into a

Waterfall Organisation

Chris Cooper-Bland, Senior Architect @ Endava Ltd

2

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?

3

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

4

Brief History of Development Methodologies

WATERFALL (Royce)

Requirements, designimplementation, verification & maintenance

1960 85 91

Methodologies

19801970

V-MODEL (Anon)

Aligns testing toWaterfall development

SPIRAL MODEL (Barry Boehm)

Iterative

RAD(James Martin)

Prototyping, iterative, time-boxed, user driven

RUP (Rational)

Object oriented, iterative, time-boxed, user driven

AGILE e.g. XP(Kent Beck)

Incremental, user driven, low process

98 99

Waterfall V-Model

Spiral Model

RAD

RUP

5

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…”

6

What is Agile? http://www.agilemanifesto.org/

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

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.

7

Working Software Delivered

RequirementsPrioritised Requirements & Features “Backlog”Requirements

RequirementsRequirements

Requirements

Prioritised Iteration Scope

Daily Scrum Meeting: 15 minutesEach 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?

Team-Level Planning Every 24hrs

Every Iteration4-6 weeks

Applying Agile:Continuous integration; continuously monitored progress

Agile project management - SCRUM

8

Agile - XP explained (1)The Values Communication Simplicity Feedback Courage Respect (added in the latest version)

9

Agile - XP explained (2)1. Test First Programming

Test First without code2. The Planning Game

- Business Stories- Customer decides, Prog. Implements

3. Small, Frequent Releases- Release early and release often

4. Always use the Simplest design that adds business value

5. System Metaphor- Programmers define a handful of classes and patterns that shape the core business problem and solution- Like a primitive Architecture

6. On-site Customer- Customer has authority to define functionality- encourages face-to-face dialogue

7. Refactoring Restructuring code without changing its functionality- Mainly Simplification

8. Pair Programming9. Collective Code Ownership10. Coding Standards

- Everyone should use the same coding styles.

11. Continuous Integration- At least a few times a day- All unit tests must pass prior to integration- All functional tests must pass afterwards

12. Forty Hour Week !- Tired programmers write poor code and make more mistakes

10

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

11

Random Example

From Northern Constabulary

12

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

13

What to change – Best Practices

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

Most Useful

Least Useful

14

Factors for Success

Choose the right project Size Importance visibility

Get buy-in of senior management

Communicate to all Use experienced people Don’t trust blindly

effort = people * environment *size(process)

- Walker Royce

Common sense – no silver bullets

15

Changing the process - Integrating the method

Advantages Single place to look Easy alignment People already understand parts

Disadvantages May lead to confusion External staff don’t know it Overlaps and/or gaps

16

Customising the method

Project defined process documented in some form

Organisational Tailoring of Method

Organisation’s Software Engineering group

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

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

Industry Methods development (e.g. Iterative, Agile)

Standard Method specification

Industry Level

OrganisationalLevel

ProjectLevel

Macro-level tailoring

Micro-level tailoring

17

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

18

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

19

The Budgeting Problem

Source McConnell 1998

The Cone of Uncertainty

20

Addressing itConvince management to make a fixed investment to establish costs

Source McConnell 1998

21

Application Project Portfolios

Senior management must give authority and control to IT

Use a portfolio management approach Define portfolio

segments Apportion available

budget Revalidate at stage

gates, for balance and progress

22

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

23

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 …

24

Structure - Radical Changes

Change the company structure of the organisation Create new spin-off

company Joint venture Acquisition

Change the internal structure New ventures

department New project teams

Existing Structure

Bureaucracy Dynamic

Agility required

Waterfall

XPNo Change

25

Don’t 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

26

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…

27

Summary

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

28

Resources

Craig Larman’s books http://www.bcs-spa.org/ http://www.dsdm.org/ http://www.real-

options.com/

29

Conclusion & Questions

Contact DetailsChris Cooper-Bland

Senior Architect

Chris.cooper-bland@endava.com