Agile In Highly Regulated Environments

1,782
-1

Published on

Presentation from Valtech Agile Edge event London April 09. Discussion and case study on Agile software development within a public sector highly regulated waterfall type environment.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,782
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
56
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Agile In Highly Regulated Environments

  1. 1. Agile in Highly Regulated Environments Alastair Brown Head of Delivery
  2. 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. 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. 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. 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. 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. 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. 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. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. Burn Down
  20. 20. Automated Unit Test Coverage
  21. 21. What was constrained Continuous Integration UAT Deployment Documents to satisfy governance process
  22. 22. 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
  23. 23. Regulator aspirations / Agile Outcomes Demonstrates due diligence and best practice Deliver increased quality Reliable outcomes Show accountability
  24. 24. 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
  25. 25. 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
  26. 26. Agile in Highly Regulated Environments Questions? Alastair Brown Head of Delivery
  27. 27. Waterfall financial profile
  28. 28. Waterfall financial profile Max Break Working Even Capital Point?
  29. 29. Agile financial profile
  30. 30. Agile financial profile Max Working Break Capital Even Point
  31. 31. Agile financial profile Max Working Break Capital Even Point
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×