THE BACKGROUND A TREND TOWARDS AGILE AND LEAN US National Defense - - PowerPoint PPT Presentation

Susan Atkinson gallenalliance Solicitors

CIPS Financial Services Purchasing Forum London Wednesday 20th April 2011

CONTRACT MODELS FOR AGILE AND LEAN

THE BACKGROUND

A TREND TOWARDS AGILE AND LEAN

• US National Defense Authorization Act 2009
• UK Government has changed its IT strategy:
• ‘System Error: Fixing the Flaws in Government IT’ published by

the Institute for Government (IfG), February 2011

• ‘Government ICT Strategy’ published by the Cabinet Office,

March 2011

• The Project Management Institute (PMI) is currently

developing an Agile certification

WHY AGILE AND LEAN?

• Traditional waterfall projects:
• CHAOS Report, 2009: 44% projects were challenged and 24%

projects failed

• Standish Group Study, 2002: 64% of software features are typically

never or rarely used

• Schedule over-runs, cost over-runs, inflexibility
• Agile and lean projects:
• VersionOne State of Agile Survey, 2010: An improvement or

significant improvement in the ability to manage changing priorities (87% of respondents) and in the time to market (70% of respondents)

• Shine Survey, 2003: Improved productivity (88% of organisations),

improved quality (84% of organisations), and higher business satisfaction (83% of organisations)

THE ISSUE

THE NATURE OF SOFTWARE DEVELOPMENT

• Analogies with the construction industry and the

manufacturing industry are flawed

• A problem-solving exercise, or the codification of

knowledge, requiring information flow:

• Information flow between the customer and the supplier leads

to perceived integrity of design

• Information flow between the various skill sets of the supplier

leads to conceptual integrity of design

• A vision gradually refined by a process of decision-making

THE CONE OF UNCERTAINTY

Entry into contract

SCRUM ACKNOWLEDGES THAT ...

Regulatory environment Competitive environment

Technology

Customer expectations Corporate strategy

IKIWISI ‘Yes but’

Integration with legacy systems

Codifying knowledge & intelligence

The customer DISCOVERS what it wants The vendor DISCOVERS how to build it Many things CHANGE along the way

Multiple stakeholders

• Visibility – those aspects of the process that affect the
• utcome must be visible to those controlling the process
• Inspection – frequent inspection to detect unacceptable

variances in the process

• Adaptation - if the process moves outside acceptable

limits, the process must be adapted to bring it back within acceptable limits

SCRUM - EMPIRICAL PROCESS CONTROL

• Split the work
• Split the time
• Split the organisation

HOW TO ACHIEVE EMPIRICAL PROCESS CONTROL

ITERATIVE AND INCREMENTAL DEVELOPMENT

ITERATION 1

R E V I E W R T ’ I V E

DESIGN BUILD

TEST

ITERATION 2

P L A N R E V I E W R T ’ I V E

DESIGN BUILD

TEST

ITERATION 3

P L A N R E V I E W R T ’ I V E

DESIGN BUILD

TEST P L A N INCREMENTAL DEVELOPMENT OF SOFTWARE

Solution Backlog

• 7 +/- 2 members
• Self-organising and cross-functional
• Comprises members of the customer and vendor
• The product owner – from the customer - responsible

for:

• the solution backlog
• communicating the wishes of all the stakeholders to the team

THE TEAM

BENEFITS OF AGILE AND LEAN

ITERATIVE DEVELOPMENT SELF-ORGANISING TEAM INCREMENTAL DEVELOPMENT Increased feedback Adaptive planning Earlier delivery Small packages of work Fully working product Continuous integration Less work in progress Knowledge creation Flexibility Less bottlenecks Knowledge creation Increases flow Meets customer’s needs Bugs identified at outset Less waste Faster delivery Better design Better ROI Fewer features Less waste Concurrent software development More robust design Early testing & validation Points of synchronisation Improves quality, productivity and morale Fewer hand-offs More value More value Less risk More value More value Less risk Less risk Greater integration across teams Faster delivery Less risk Better design Less waste More value More value More value Less risk

THE SOLUTION THE EVOLUTIONARY CONTRACT MODEL (ECM)

Debunking the myths!

• Agile:
• Scrum – Agile framework for project management
• Extreme Programming (XP) – Agile software engineering

practices

• DSDM Atern – Agile project management ‘wrap’
• Evolutionary Project Management (Evo) – Agile delivery of

defined and measurable value

• Lean – the delivery of value more effectively by reducing

cycle times and removing waste in the processes

• Systems thinking – delivery of an integral system

EVOLUTIONARY CONTRACT MODEL - INFLUENCES

• Delivery of the solution
• The solution evolves
• No contractual requirements or specifications
• No change control mechanism
• No contractual acceptance tests
• Empirical process control
• Results-focused

EVOLUTIONARY CONTRACT MODEL – AN OVERVIEW

COMPARISON OF CONTRACT MODELS

The Traditional Contract Model The Evolutionary Contract Model

The requirements are specified upfront. The features of the solution evolve. Changes 'controlled' by means of the change control mechanism. Changes accommodated as part of the development process. Analysis, design, development and testing occur sequentially. Concurrent design and development. An all-or-nothing solution. The solution is broken down into features. Constituent 'modules' of software are worked on independently until integration takes place. A continuous working and stable software system. Testing used as a contractual tool. Testing forms an integral part of the development process. Success is measured by reference to conformance with the plans. Success is measured by reference to completed solution increments.

EVOLUTIONARY CONTRACT MODEL - STRUCTURE

Start-Up Phase Calibration Phase Release 1 Release 2 Release 3

DELIVERY PHASE Framework INITIAL PHASE Committed Iterations Contractual gatepost SOW SOW SOW Entry into contract

Release 4

Solution Backlog

SOW

• Vision Statement – the concept of the solution
• The Value Drivers – quantifiable measures of success
• The Roadmap – an approximate timetable for delivery of

the solution having regard to various constraints

ENTRY INTO CONTRACT - KEY SCHEDULES

• The Business Case – expands upon the Vision Statement:
• High level objectives of the solution;
• utline of the solution backlog items (SBIs);
• details of potential solutions;
• estimates of costs and timeframes
• The High Level Release Plan – expands upon the Roadmap -

segments the solution into smaller solution subsets that create value for the stakeholders

• The Solution Backlog – an evolving prioritised queue of all

items of work which may be relevant to the solution

START-UP PHASE – KEY DELIVERABLES

• Includes all items of work relevant to the solution
• May not be a document
• Solution backlog items (SBIs) are prioritised
• Dynamic
• Evolves
• Must be within the scope of the contract
• The solution owner only controls the solution backlog

THE SOLUTION BACKLOG

THE EVOLUTION OF THE PLANS

Entry into Contract End of Start- Up Phase End of Calibration Phase Release Iteration Vision Statement Business Case Solution Backlog Iteration Backlog Road Map High Level Release Plan Release Plan Iteration Plan Value Drivers Charging Model Calibration SOW Commitment to Charges

• Framework under which Releases are initiated by SOWs
• The SOWs are contractually enforceable
• Release planning
• Release review – show the solution subset to the

stakeholders to validate the solution

• Release retrospective – solution team inspects the process

THE DELIVERY PHASE

• Timeboxed – of fixed duration throughout the project
• Planning – which SBIs; decompose the SBIs into tasks to

create the iteration backlog

• The SBIs – must not be changed during the iteration
• The iteration backlog - evolves and must be kept up-to-

date at all times

• Review - show the solution increment to the stakeholders to

validate the solution

• Retrospective - solution team inspects the process – use of

metrics

• The solution increment – builds upon earlier iterations

THE ITERATIONS

• The lawyers!
• The procurement process
• Organisational impact
• Securing budgetary approval
• Involvement of the business function of the customer
• Proper implementation of Agile and Lean

CONTINUING CHALLENGES TO THE ADOPTION OF THE EVOLUTIONARY CONTRACT MODEL

ANY QUESTIONS?

• Charging models?
• Estimating?
• Measures of delivery?
• Sequential vs. concurrent design & development
• Scaling up?

Susan Atkinson gallenalliance Solicitors

23 Austin Friars London EC2N 2QP United Kingdom Tel: +44 20 7084 6392 Email: satkinson@gallenalliance.com

THANK YOU