© lamri 2004 moving to risk driven/iterative development graham dick copyright 2003

© Lamri 2004

Moving to Risk Driven/Iterative DevelopmentGraham Dick

Copyright 2003

© Lamri 2004

Agenda

• Traditional and Iterative Processes• Observed Issues in Moving to Iterative Software

Development Process• A pragmatic approach to Risk Driven Iterative

Process (RUP)

Copyright 2003

Traditional and Iterative Processes

© Lamri 2004

Traditional Lifecycle (Waterfall)

time

FreezeRequirements

Freeze Design

Code Functionality

Integrate Rollout

RequirementsCapture

Analysis &Design

Implement &Module Test

Integrate &Test

Deploy

Characteristics: • Document Driven• Work Products carried from phase to phase• Subsequent work products build from and trace back to previous onesFreeze

Works well when:• Requirements / technology well understood and stable• Simple, easy to use process• Mid-course changes are rare or tightly controlled

© Lamri 2004

Problems with Traditional• Delays discovery of errors (blip of uncertainty)

– Integration happens at tail of process – big bang– Often results in unplanned rework

• Inflexible– Very difficult to deliver an intermediate release – nothing

system tested until the end!

• Does not respond well to changes in Requirements

– The approach does not lend itself to the management of change

– Leads to a false sense of security in the early plans and estimates

• Progress measured by completion of artefacts

R

D

I

T

D

© Lamri 2004

Iterative Lifecycle

RequirementsCapture

Analysis &Design

Inception Elaboration Construction Transition

Analysis &Design

Integrate &Test

Deploy

RequirementsCapture

Analysis &Design


Integrate &Test

Deploy


Integrate &Test

Deploy

Scope Risk Functionality Rollout

Should webuild it?

Can webuild it?

Did webuild it?

Did wedeliver it?

time

© Lamri 2004

And so to Risk

© Lamri 2004

Iterative Lifecycle Benefits

Early iterations focus on risk

Later iterations focus on functionality

Iterations provide feedback loop on process

performance

Test and regression test each iteration

Iterations provide vehicle to

accommodate change

Issues flushed early

Incremental integration

Narrow the two horse race

Copyright 2003

Observed Issues in Moving to an Iterative Process

© Lamri 2004

Common Mistakes

Confuse Phases with Stages

Non-functional Requirements collected late

Stakeholders are not briefed on the Iterative characteristics

Different Resource Profile

Iterations are closed without executable code

Attempt to complete artefacts when first

addressed

Traditional team structure is preserved

Throw out all existing

practices

Rollout not linked to a problem/needs

Believe RUP covers all processes

Don’t procure support for rollout

Use RUP in its entirety – and

add to itProcess Developed

in Ivory Tower

© Lamri 2004

Common Mistakes

Confuse Phases with Stages

© Lamri 2004

Phases are not Stages

PHASE

RequirementsCapture

Analysis &Design


Integrate &Test

Inception Elaboration Construction Transition

MILESTONE Should webuild it?

Can webuild it?

Did webuild it?

Did wedeliver it?

FOCUS Scope Risk Functionality Rollout

© Lamri 2004

Common Mistakes

Iterations are closed without executable code

© Lamri 2004

What’s an Iteration really?

Iteration 1

R

DC

T

D

R

DC

T

D

R

DC

T

D

time

Iteration 2 Iteration 3

• It’s a complete waterfall – BUT– Applied only to a selected subset of

requirements

• following the objectives – of the phase containing it

• Apply the waterfall iteratively– To incrementally build the system

© Lamri 2004

Common MistakesNon-functional Requirements

collected late

© Lamri 2004

Treat non-functionals as first class citizens

• Often get left to the end– Everyone focuses on the functionality

• But– Non-functionals can have critical architectural significance

• Design for performance• Mega-data• Distribution• Reliability• Security

• Treat as first class citizens– Non-functionals and risk drive content of elaboration

– Map to risk and deliver in elaboration as appropriate

© Lamri 2004

Common Mistakes

Attempt to complete artefacts when first

addressed

© Lamri 2004

Build artefacts like the product - Incrementally

• Build artefacts in line with the product– Builds the product in an incremental manner - iteration by iteration

– Build the artefact set incrementally – iteration by iteration

Iteration 1

R

DC

T

D

R

DC

T

D

R

DC

T

D

time

Iteration 2 Iteration 3

© Lamri 2004

Common Mistakes

Use RUP in its entirety – and

add to it

© Lamri 2004

Don’t Adopt all of RUP

One of the largest and most successful implementations of RUP reduced the number of pages from 2500 to 300

© Lamri 2004

Common Mistakes

Throw out all existing

practices

© Lamri 2004

Don’t throw the baby out with the bathwater

You currently do most of the disciplines, so retain what you do well

How you govern projects is specific to your organisation

© Lamri 2004

Common Mistakes

Believe RUP covers all processes

© Lamri 2004

RUP doesn’t cover everything

RequirementsManagement

ProjectPlanning

Project Monitoring &

Control

SupplierAgreement

Management

Measurement&

AnalysisProcess &

ProductQuality

Assurance

ConfigurationManagement

TechnicalSolution

RequirementsDevelopment

ProductIntegration

Validation RiskManagement

Verification

IntegratedProject

Management

OrganisationalProcessFocus

OrganisationProcess

Definition

OrganisationalTraining Organisational

EnvironmentFor

Integration

DecisionAnalysis &ResolutionIntegrated

Teaming

IntegratedSupplier

Management

CMMISM

CMMICMMISM

Addressed byRUP

PartiallyAddressed

NotAddressed

CMMI L3 Process Areas

RUP provides approx 50% coverage to CMMI Level 3

© Lamri 2004

Common Mistakes

Process Developed in Ivory Tower

© Lamri 2004

Ivory Tower Process Development• Symptoms include:-

– Long time crafting process, procuring tools, writing html

– When rollout finally occurs• Organisation has moved on• Process elements not

applicable• Organisation rapidly loses

confidence

• To Mitigate– Treat the rollout as a project– Attack risk

• Do a bit, test a bit – deploy early and often to real live projects

– Assess the current organisation• Enables proper focus on areas of weakness

– Ensure that process engineers are involved in the process rollout

© Lamri 2004

Common Mistakes

Install and Train& it will happen

© Lamri 2004

RUP will not just happen with an Installation and Training

• Putting the tools and the RUP HTML pages on people’s desktops does not mean people will use it– There is a lot of RUP to get lost in– RUP uses a different terminology to your current terminology– People will not be able to immediately apply what they know to a

project

• Ensure that you can measure the effectiveness of training and mentoring– Most expensive part of the RUP rollout– Requires measuring competence before any learning and at regular

points during the learning programme

© Lamri 2004

The change is significant

COBOLProgrammer

J2EESoftwareEngineer

RUPRational Tools

UMLJava

WebSphere

Functional DecompositionCOBOL

Functional Requirements SpecificationSingle Development Environment

Object OrientedJava

Use Case SurveyMulti-Vendor Environment

© Lamri 2004

Common Mistakes

Don’t procure support for rollout

© Lamri 2004

Get advice from those who know!

• Ensure support is qualified (e.g. Rational Certified)• Ensure that your process rollout partner is engaged

with your organisation at the right level• Check the background of your chosen consultants -

seek references• Assure that consultants do not become delivery

resources for project teams• If you can’t or won’t take advice why pay for it?

© Lamri 2004

Common Mistakes

Traditional team structure is preserved

© Lamri 2004

To Iterate – Address your structure

• Software Development is a team sport• Doing iterations demands a nimble structure• Traditional organisational structures

– Want to ‘finish’ artefacts before handing them on

– Tend to work in isolation

– Number of handoff points in the organisational structure dictates the minimum size of the iteration

© Lamri 2004

Common Mistakes

Different Resource Profile

© Lamri 2004

Resources required to a different beat• Inception

– Small team focus• Requirements• Project Management• Architecture

• Elaboration

– Small team focus• Requirements• Project Management• Architecture• Small build• Small test

• Construction

– Large team focus• Much less - requirements,

architecture• Much more - build, test

© Lamri 2004

Common MistakesStakeholders are not briefed

on the Iterative characteristics

© Lamri 2004

RUP impacts stakeholders too

Finance observes different project profile– Resources

• Only need a small more skilled team in Inception/Elaboration

• Defer the ‘Mongolian hoard’ of contractors until Construction

– Different spending profile – all required for elaboration• Build environments, Deployment/Test environments

• Software licenses

– Principle measure of progress changes from artefact completion to

• Risks mitigated

Sponsor observes issues peak earlier

– Can look like project out of control– May be forced into supplier issue

resolution far earlier than ‘normal’– Principle measure of progress

changes from artefact completion to• Risks mitigated

• End Users observe differences– Delivered documents different

• Different names

• Different layouts etc

– Required earlier• As elaboration uncovers requirements issues

– Required more often– Require education on the need for elaboration iterations – Confronted with early issue Peaks

• Can cause great discomfort

© Lamri 2004

Where is the pain?

• To change process the project team – Need re-orientation– Need an incentive to facilitate this

• Successful process improvement drives from

– Acceptance– Belief– Commitment

• These are much easier to communicate if– The organisation’s needs are crisp and clear

© Lamri 2004

So how do we move forward?

• Seen a number of potential issues• To surmount these we require

– Process for process improvement

– Needs

– Understand the current capability

– Understand where we’re going

© Lamri 2004

Lets see what happens if we miss some ingredients?


TargetCapability

Plan= A solid foundation

Current Capability

TargetCapability

Plan= Inertia

Needs TargetCapability

Plan= Confusion


Plan= When do we stop?


TargetCapability = A pipedream

NeedsCurrent

CapabilityTarget

Capability Plan = The usual

© Lamri 2004

Rollout – First Set Goals

CapabilityProfile

EstablishCurrentCapability

SetTargetCapability

Gains Sponsorship &Business Case

So how do we do this?

© Lamri 2004

CMMI PROCESS AREAS

RequirementsManagement

ProjectPlanning

Project Monitoring

&Control

SupplierAgreement

Management

Measurement&

Analysis

Process & ProductQuality

Assurance

ConfigurationManagement

OrganisationalProcess

Performance

OrganisationalInnovation

&Deployment

TechnicalSolution

MATURITY2

MANAGED

RequirementsDevelopment

ProductIntegration

Validation RiskManagement

Verification IntegratedProject

Management

OrganisationalProcessFocus

OrganisationProcessDefinition

OrganisationalTraining

OrganisationalEnvironment

ForIntegration

DecisionAnalysis

&Resolution

IntegratedTeaming

IntegratedSupplier

Management

QuantitativeProject

Management

CasualAnalysis

&Resolution

MATURITY3

DEFINED

MATURITY4

QUANT’LYMANAGED

MATURITY5

OPTIMISING

• A framework for capability assessment

© Lamri 2004

Rolling out RUP

• In our experience there are two scenarios– Rollout to individual project

• Individual PM/Architect etc want to get benefits on THEIR project

– Rollout to whole organisation• Gain organisational benefits

– can occur from desire to improve real issues to airline magazine syndrome

© Lamri 2004

Rollout to Project

PrioritiseCapabilityGaps

Project Delivery Plan

IntegratePlan

Integrated Project Plan

CapabilityProfile

ExecutePlan


SetTargetCapability

Integrated Plan includes:- Overhead of improving the team- Process Assurance Activities- Briefing Stakeholders on Risk, etc- Educating Stakeholders with UML- Briefing Finance on project profile

Gains Sponsorship &Business Case

Improvement Plan

© Lamri 2004

Rollout to Organisation

EstablishImprovement Project

CapabilityProfile


SetTargetCapability

Improvement ProjectBusiness case, plan, PM, sponsor,

risk management etc

ProjectProject

Project

Process Assurance

Deploy Process

Verify PositiveResults

Improvement Project responsible for:- Deployment- Presence at Phase and Iteration Assessments- Process Assurance Activities- Briefing Stakeholders on Risk, etc- Educating Stakeholders with UML- Briefing Finance on project profile

© Lamri 2004

Some Tactics

• People quickly forget what they are taught– Ebinghaus (1885) showed that 90% of material taught in class

forgotten within 30 days

• Tactic– Break training down into components that can be delivered just in

time

– Tie to specific project – go out and use training immediately

• Unfamiliar project profile– Stakeholders new to RUP see different issue and resource profiles

• Tactic– Actively plan to engage with stakeholders, manage expectations

and support them

© Lamri 2004

Some Tactics

• Training alone does not create a competent practioner

• Tactic– Plan in a programme of training and mentoring

– Do this on a real project

• We forget that people do process– Send them on the training course then expect them to apply the

process on their return

• Tactic– Assess people, how competent, where are the gaps?

– Just what support do they need for their particular role?

– Design appropriate training and mentoring for individuals

– Reassess to look for desired improvement

© Lamri 2004

Some Tactics

• Don’t say you are going to do RUP– It has too many interpretations

• Tactic– Say what objectives we wish to achieve, what are the desired

benefits– Plan in marketing and selling of the improvement effort– RUP is a mechanism for achieving benefits

• Organisations find creating the improvement plan very difficult

• Tactic– Be sure to assess your current state– Define your desired state in the same terms (e.g. CMMI)– This makes it much easier to be precise about the gaps and to

communicate them to the project community

© Lamri 2004

Conclusion

• If implemented correctly RUP will improve the performance of your organisation

• Do Establish a proper foundation for rollout– Measure your current capability, define your target

• Use a recognised capability benchmark– CMMI, SPICE

© lamri 2004 moving to risk driven/iterative development graham dick copyright 2003

Documents