The document discusses using agile methodologies in highly regulated environments. It outlines the constraints of traditional waterfall approaches and how they often lead to failed projects. Agile principles and practices like frequent delivery, adapting to change, and face-to-face collaboration are presented as alternatives. A case study shows how an organization in a regulated domain integrated agile practices like daily standups and testing within their waterfall governance processes, delivering on time and on budget while meeting regulatory requirements. The document argues that agile can satisfy regulators' needs for accountability and quality when adapted appropriately for an organization's constraints.

1. Agile in Highly Regulated Environments
Alastair Brown
Head of Delivery

2. Agenda
Regulation
What is it?
The Need for.
Methodology Choices
Methodologies
Waterfall features
Agile Engineering
The Manifesto
The Principals
Benefits
Project
Programme
Business
The Case Study
Overview
The Agile Toolbox
Integration with the waterfall governance processes
Constraints
The Outcomes
Regulation requirements and the Agile outcomes.
Questions

3. Regulation
Highly Regulated Environments
Serial process
Gated entry and exit
Documentation, review and signoff
Governance Hierarchy
Micro management and a plan way into the future
Highly resistant to change

4. The Need for Regulation
Why do we Regulate?
• Perception that regulation…
Demonstrates due diligence and best practice
Deliver increased quality
Reliable outcomes
Show accountability

5. Choices
Constraints on choice of methodology
Customer mandate to satisfy process constraints
Software releases to support Legislation
Regulators or industry authority requirements
Adversity to risk
Scale of the problem
Criticality of the solution

6. Agenda
Regulation
What is it?
The Need for.
Methodology Choices
Methodologies
Waterfall features
Agile Engineering
The Manifesto
The Principals
Benefits
Project
Programme
Business
The Case Study
Overview
The Agile Toolbox
Integration with the waterfall governance processes
Constraints
The Outcomes
Regulation requirements and the Agile outcomes.
Questions

7. Waterfall Features
Actual use of Requested features on Traditional Software Projects
Wasted development
Often / Always 20%
Exceeded cost / schedule Never 45%
Often / Always
Sometimes
Rarely
Never
Sometimes 16%
Under deliver features Rarely 19%
Source: Johnsen 2002
Lack of flexibility
Requirements Change by Project Size
50
45
40
Requirements Change %
35
30
25 Requirements Change %
20
15
10
5
0
0 10 100 1000 10000 100000 1000000
Source: Jones97 Project Size in Function Points

8. Leading to…
Projects that Fail
Source: The CHAOS report -
Proportion of Projects Failing
Standish Group
60
50
40
Suceeded
%
30 Failed
Challenged
20
10
0
1998 2000 2002 2004 2006
Year

9. Agile Project Methodology
Agile software engineering methodologies have
been proven to deliver to cost time and budget
A benchmark of 29 Agile development projects against a database of 7,500
primarily traditional development projects found the Agile projects were:-
• 37 percent faster delivering their software to market
• 16 percent more productive
• Able to maintain normal defect counts despite significant schedule compression
Source: QSMA May 2008

11. Agile Principals
Focus only on delivery of software that adds business value
Welcome changing requirements – and know the impact of that change
Deliver working software frequently and regularly
Enable and ensure constant and consistent face-to-face interaction
between Business people and Developers
Build performant motivated teams, provide the tools and remove
impediments
Progress measured by working, delivered, accepted software
Ensure and enable sustainable development pace and quality
Provide consistent technical excellence and quality
Simplicity
Self organisation
Inspect, learn and adapt

12. Agenda
Regulation
What is it?
The Need for.
Methodology Choices
Methodologies
Waterfall features
Agile Engineering
The Manifesto
The Principals
Benefits
Project
Programme
Business
The Case Study
Overview
The Agile Toolbox
Integration with the waterfall governance processes
Constraints
The Outcomes
Regulation requirements and the Agile outcomes.
Questions

13. Project Benefits of Agile
Enables, encourages, and in fact demands, frequent and regular
detailed planning rather than a plan derived when the Cone Of
Uncertainty is wide” (Relies on planning, rather than following a plan)
Exposes impediments earlier
Increases discipline and rigour
Increases estimating accuracy
Regular and frequent demonstration of software to ensure a consistent
and evolutionary understanding between the delivery team and the
business users ensuring “no surprises in UAT” (Zero defects).
A proven structure to apply meaningful metrics that meet the
benefit/burden balance

14. Programme Benefits of Agile
Improved organised interaction of project teams with
each other and other stakeholders
Improved visibility of programme conflicts to the
project teams
Identifies an empowered customer representative to
improve influence of stakeholders.
Addresses the failings in Time and Cost overruns and
Quality issues that are inherent within Waterfall

15. Business Benefits of Agile
Quicker / Increased ROI
Increased Net Cumulative Cash Flow
Predictable and measurable pace
Predictable deliverables and outcomes, aligned
with Business needs and benefits
Established, consistent and continual quality
Visible quantifiable progress

16. Agenda
Regulation
What is it?
The Need for.
Methodology Choices
Methodologies
Waterfall features
Agile Engineering
The Manifesto
The Principals
Benefits
Project
Programme
Business
The Case Study
Overview
The Agile Toolbox
Integration with the waterfall governance processes
Constraints
The Outcomes
Regulation requirements and the Agile outcomes.
Questions

17. The Case Study
Large scale software release of three projects
Public sector, social security domain
Systems Integrator with CMMI Level 5 rating
History of budget and schedule overrun
Software to support change to legislation
A track record of requirements ambiguity and poor
definition
Customer mandate to follow a waterfall QMS process

18. The Agile Toolbox
Roles Other
Product Owner Impediment
Scrum Master Sprint
Scrum Team Velocity
Unit Test
Artefacts Retrospectives
Release burn down chart Demonstration
Product backlog
Sprint backlog

19. Integration with the Waterfall
Sprint and release burn down - RAG and morning
prayers, schedule reviews, change board get
improved visibility.
Daily Standups – Fed the risk review board
Unit Testing – became the “sign off” artefact for the
sprint.
Demonstration – Made UAT self fulfilling
Product Owner – fulfilled the communication plan

20. Burn Down

21. Automated Unit Test Coverage

22. What was constrained
Continuous Integration
UAT
Deployment
Documents to satisfy governance process

23. The Outcome
Risk of schedule overrun identified very early enabling
mitigation
Highest quality, lowest defect rates, for many years
Simplest UAT testing seen for many years
Work continues on satisfying the formal process
Project delivered successfully, to budget and time, meeting
the legislative date.
Subsequent release embracing agile methods, with less
duplication
Team trained and coached became enthusiastic evangelists

24. Regulator aspirations / Agile Outcomes
Demonstrates due diligence and best practice
Deliver increased quality
Reliable outcomes
Show accountability

25. and Agile Characteristics
Level 1 - Ad hoc (Chaotic)
Typically undocumented process
Unrepeatable often relying on heroics
State of dynamic change in an uncontrolled and reactive manner
Level 2 – Managed Repeatable
Some processes are repeatable, possibly with consistent results
Limited rigour, although processes usually maintained during times of stress
Level 3 - Defined
Defined and documented standard processes established
Delivering consistency across the organisation
Some degree of improvement
Level 4 – Quantitatively Managed
Use of process metrics allows for control of the process
Ability to adjust and adapt the process to particular projects without
measurable losses of quality or deviations from specifications
Level 5 - Optimising
Focus on continually improving process performance through both incremental
and innovative technological changes and improvements

26. Where to start
Understand your current position and aspirations;
plan and action your first next step, then Inspect
and Adapt
Be as Agile as you are (currently) able; within your
(any) current constraints
Be pragmatic; utilise any interventions to deliver
outcomes
Do not assume that your constraints prevent the
implementation of Agile practices; do not prepare
the Barrel for the Waterfall

27. Agile in Highly Regulated Environments
Questions?
Alastair Brown
Head of Delivery

28. Waterfall financial profile

29. Waterfall financial profile
Max Break
Working Even
Capital Point?

30. Agile financial profile

31. Agile financial profile
Max
Working Break
Capital Even
Point

32. Agile financial profile
Max
Working Break
Capital Even
Point