Introducing Agile Projects Colin Evans February 2016

Transcription

1 Introducing Agile Projects Colin Evans February 2016

2 Agenda What is an agile project? Why has agile become popular? A crash course in agile. Some of the issues with agile? Discussion Some potential solutions How do you audit an agile project? 2

3 What is an agile project? 2 types of agile project - A project which is very flexible and responsive to change - A software development project using an agile development methodology, e.g. Scrum We are looking at the second type.. 3

4 Why has agile become popular? Waterfall methodology standard approach: Sequential Requirements => Design => Build => Test => Implement => Maintain Some examples of issues: - Poor record of delivery time and cost overruns. - Users not good at defining requirements. - Inflexible e.g. hard to build in new requirements at a later stage. - Users and developers work in silos users not involved until late on and lack engagement. - Often a lack of transparency over the real progress made long period before anything is delivered. - Underestimate the amount of testing required, especially integration. Data migration is often considered too late. 4

5 Why has agile become popular? Agile methodology : Iterative approach, not sequential Response to issues: - Regular delivery typically every 3 to 4 weeks. - Don t need to define all the requirements up front. - Very flexible designed to enable additional requirements. - Users and developers work together. - Very transparent progress monitoring. - Test as you go along so don t wait until the end. - Use real data to test as part of the on-going testing. 5

6 A crash course in agile The original idea of agile is to give the power back to the development team a reaction to the inflexibility of waterfall Some terminology: - Roles - Scrum team; Scrum master/delivery manager; product owner/service manager. - Process User stories; Sprint; Sprint planning meeting; Sprint backlog; Backlog grooming; Daily scrum/stand-up. - Review and monitoring Task board; Burn down chart; Sprint review meeting; Sprint retrospective. The whole team tends to be co-located constant communication/interaction. Team individuals are accountable and responsible e.g. they choose their own work and do their own estimating. 6

7 Some of the issues with pure agile Hard for a very large complex development. A lot of the exemplars are for front end processing. Agile can struggle with high volume back end processing. No overall project plan. Don t know how much it is going to cost/how long it is going to take. How does it fit with business cases and external approvals? How does it fit with project governance? - Who is the SRO? SRO vs product owner/service manager. - How does the project board fit in? - What are the roles and responsibilities of project board members in an agile environment? How do you manage a programme (or portfolio) of agile projects? 7

8 Some more issues with real life agile In a business critical development, the Board is not kept suitably engaged and informed. Business users believe that they can develop business requirements as the project progresses, rather than prioritising key requirements from the start, so there is a lack of engagement. There is a lack of very experienced delivery managers/leaders in the market place. Use of inappropriate contracts to take on external suppliers. A lack of clarity on the agile approach which is going to be adopted. Ineffective project reporting, which isn t aligned to agile. Ineffective project escalation when things start going wrong. An imbalance in terms of workload for individuals on the team. Team feels isolated from the rest of the organisation. 8

9 DISCUSSION Experience around the room with agile What issues did you encounter? How did you audit the project? 9

10 Some potential solutions Public Sector Government projects: - Government Digital Service (GDS) has invested in a service design manual which provides detailed advice on delivering digital services using an agile approach ( Worth a read even if you aren t a public sector organisation Includes guidance on governance and assurance processes. 10

11 Some potential solutions (continued) Put a governance wrapper around agile. Do more planning and design work up front to provide an overall plan and to support approvals and business cases. Project board meetings = sprint review meeting but timing doesn t always work. Can use scrum artifacts for the project highlight report, e.g. burn down chart, to minimise duplication. Project board members need to get their hands dirty with the process to be effective. Have a more senior SRO working closely with the full time product owner/service manager. Need more structure/communication when you have a programme or portfolio e.g. dependencies aren t so easy to identify. Need to actively involve the team in peer activities/training etc. 11

12 Some potential solutions (continued) Focus on ensuring the Board is suitably engaged and informed. Business users engaged early. Prioritise key requirements from the start. Invest in experienced delivery managers/leaders. Use appropriate contracts to take on external suppliers. Ensure clarity on the agile approach which is going to be adopted. Align project reporting with the adopted agile approach. Clarify project escalation arrangements, including for suppliers. Use retrospectives to think about optimising workload across the team. 12

13 How do you audit an agile project? Need to be clear on the objectives of the audit is it e.g. - a process review (following agile methodology); - project assurance; - readiness for go-live; - part of a broader programme/portfolio review. Need to understand what is there is this pure agile or a variant on a theme? Assess the extent of evidence at an early stage. Talk to the project team and audit sponsor about evidence issues early. Is there alternative work you can do to get comfort? Even in a pure agile environment there is audit evidence, e.g. burn down charts; user stories; product backlog; system documentation but closeness of the team often means meetings etc are more informal. 13

14 Any other questions.. This publication has been prepared for general guidance on matters of interest only, and does not constitute professional advice. You should not act upon the information contained in this publication without obtaining specific professional advice. No representation or warranty (express or implied) is given as to the accuracy or completeness of the information contained in this publication, and, to the extent permitted by law, PricewaterhouseCoopers LLP, its members, employees and agents do not accept or assume any liability, responsibility or duty of care for any consequences of you or anyone else acting, or refraining to act, in reliance on the information contained in this publication or for any decision based on it PricewaterhouseCoopers LLP. All rights reserved. In this document, refers to PricewaterhouseCoopers LLP (a limited liability partnership in the United Kingdom) which is a member firm of PricewaterhouseCoopers International Limited, each member firm of which is a separate legal entity.