Agile In Highly Regulated Environments

Embed Size (px)

DESCRIPTION

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.

Text of Agile In Highly Regulated Environments

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

2. AgendaRegulation What is it? The Need for. Methodology ChoicesMethodologies Waterfall features Agile Engineering The Manifesto The PrincipalsBenefits Project Programme BusinessThe 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 EnvironmentsSerial processGated entry and exitDocumentation, review and signoffGovernance HierarchyMicro management and a plan way into the futureHighly resistant to change 4. The Need for RegulationWhy do we Regulate? Perception that regulation Demonstrates due diligence and best practiceDeliver increased qualityReliable outcomesShow accountability 5. Choices Constraints on choice of methodology Customer mandate to satisfy process constraintsSoftware releases to support LegislationRegulators or industry authority requirementsAdversity to riskScale of the problemCriticality of the solution 6. AgendaRegulation What is it? The Need for. Methodology ChoicesMethodologies Waterfall features Agile Engineering The Manifesto The PrincipalsBenefits Project Programme BusinessThe 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 ProjectsWasted developmentOften / Always 20% Exceeded cost / scheduleNever 45% Often / Always Sometimes Rarely Never Sometimes 16% Under deliver features Rarely 19% Source: Johnsen 2002Lack of flexibilityRequirements Change by Project Size50 45 40Requirements Change %35 30 25Requirements Change % 20 15 10 5 0 0 101001000 10000 1000001000000 Source: Jones97 Project Size in Function Points 8. Leading to Projects that Fail Source: The CHAOS report -Proportion of Projects Failing Standish Group605040 Suceeded % 30 FailedChallenged201001998 2000 200220042006Year 9. Agile Project Methodology Agile software engineering methodologies havebeen 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. Agile PrincipalsFocus 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. AgendaRegulation What is it? The Need for. Methodology ChoicesMethodologies Waterfall features Agile Engineering The Manifesto The PrincipalsBenefits Project Programme BusinessThe Case Study Overview The Agile Toolbox Integration with the waterfall governance processes Constraints The Outcomes Regulation requirements and the Agile outcomes.Questions 12. Project Benefits of AgileEnables, 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. Programme Benefits of AgileImproved 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. Business Benefits of AgileQuicker / 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. AgendaRegulation What is it? The Need for. Methodology ChoicesMethodologies Waterfall features Agile Engineering The Manifesto The PrincipalsBenefits Project Programme BusinessThe Case Study Overview The Agile Toolbox Integration with the waterfall governance processes Constraints The Outcomes Regulation requirements and the Agile outcomes.Questions 16. The Case StudyLarge 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. The Agile ToolboxRolesOtherProduct OwnerImpedimentScrum Master SprintScrum Team Velocity Unit Test Artefacts RetrospectivesRelease burn down chartDemonstrationProduct backlogSprint backlog 18. Integration with the WaterfallSprint 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. Burn Down 20. Automated Unit Test Coverage 21. What was constrainedContinuous Integration UAT Deployment Documents to satisfy governance process 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. Regulator aspirations / Agile Outcomes Demonstrates due diligence and best practice Deliver increased qualityReliable outcomesShow accountability 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. Where to startUnderstand 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. Agile in Highly Regulated EnvironmentsQuestions?Alastair Brown Head of Delivery 27. Waterfall financial profile 28. Waterfall financial profile Max Break Working Even Capital Point? 29. Agile financial profile 30. Agile financial profile Max WorkingBreak CapitalEvenPoint 31. Agile financial profile Max Working Break Capital Even Point