Presenter: David Bryant DavidmBryant@hscic.gov.uk What am I? Head of IT Development for the HSCIC An architect – sometimes Delivery focused An agile advocate What am I not? An agile evangelist or guru What am I going to talk about? A brief history of my team, the readers digest version. A few observations about maturity and progress. He might be happy but… So where do you start? Well there are some things that are just a good idea… Forget agile for a moment and think of best practice approaches to development, or anything for that matter… Get some visibility and set some standards… Some Foundations Environments - SDLC CI – daily build TDD Quality Assurance Visibility So we had… Some good foundations and good practice. SDLC – reflected in process and environments Kanban – process, prioritisation, visibility. Mingle – electronic tracking and reporting. So when PROMS came along we knew what to do. SCRUM in a nutshell Process Improvements Daily adjustments Retrospective Product Backlog Release Backlog PID High-level Requirements IT Strategy Release Planning Demo Sprint Planning Sprint Demo feedback/ Actual Velocity Customer feedback / issues Product owner Scrum master Delivery team Backlog management Planning poker Accepted Candidate Release Candidate Release Daily Scrum UAT Release So, are we agile now? Measuring progress, summer 2012: The following scores indicate IT Development-centric maturity. Number of projects using agile 7/7 Number of projects with iteration cycles 7 Number of projects with Test Driven Development 6 Number of projects using User Stories 6 Number of projects with continuous integration 7 Number of projects with acceptance testing within iteration 5 The following scores indicate that a wider adoption of agile methods is being achieved. Number of projects with Product Owner sourced from business Number of projects with Product Owner owning backlog Number of projects with Product Backlog as single source of reqs Number of projects with continuous release planning 3 2 3 4 So that’s pretty good then isn’t it? At least so I thought…. What you don’t know can hurt you. The problem with BA’s is… The problem with requirements is… The problem with PM’s is… The problem with the business is… The problem with the ops team is… The problem with the decision making process is… The problem with agile is… Great – how many problems? Our use of agile did not create these problems… They were already there! So… I knew agile cannot exist in a silo, it won’t wither and die but neither will it thrive. The Design Authority is the answer!! I will get the organisation to make everyone agile! My first response… But what I learned is… “They” think agile is a methodology “They” think SCRUM IS agile “They” think it’s a choice between agile and waterfall “They” just don’t get it! And most importantly…. If your whole message about agile development is about tactical development practices then the best that you can expect from the business is benign disregard. (Valtech. Adopting Agile in the organisation) So whose responsibility is it? ….and what next? Is it my job/responsibility to make the organisation agile? Or do I settle for what I can achieve in my sphere of influence? Agility is a continuum not a destination. It is not a binary state. …and also… …I have come to understand that it applies to me and my understanding as much as it does to the team and the organisation. So what are we doing about the problems? BA’s Engaging with BA’s and getting them embedded with delivery teams. Work with them closely so as to avoid silo mentality and change how they express requirements (not solutions). Requirements Goes hand in hand with above. Ownership of requirements sits with the business/customer not with BA’s PM’s Getting buy in from Programme Delivery, joint ownership of delivery framework. Ensure that PM are engaged and express milestones in terms of goals not tasks. Track versus sprint goals and release goals. Business Express benefits of engagement to ensure that what is required is what is delivered. Op’s Assist with demand management. Develop auto deployment and move towards continuous delivery. Interventions by ops team minimised. Decision making process This is the hard one! Firstly, avoid the waterfall vs. agile debate. Express delivery approach in terms of best practice engineering methods not as a choice between “methodologies” (ideologies) agile Stop “selling“ agile. Start selling successful delivery. Stop trying to make the organisation agile. Just be agile. So back to maturity… CMMI view. Level 1 Chaotic / Ad Hoc, undocumented, not repeatable, uncontrolled change Where we started Level 2 Reactive / Managed Repeatable, some repeatable processes possible consistently. Introduction of lean/kanban, agreed toolsets, development agreement, SDLC Level 3 Proactive / Defined, standard processes established, delivered consistently. Maybe some degree of improvement. Introduction of Scrum, creation of development framework and QA strategy, standardisation across teams. Level 4 Service / Quantitatively Managed, use of process metrics for control of the process. Ability to adjust and adapt process to project without loss of quality. Introduction of dashboards, standardisation across teams, governance around dashboards and portfolio reporting. Starting to tailor and adapt ITDF. Level 5 changes. Value / Optimising, focus on continual process improvement through incremental and innovative Depends on your measure or definition but I think we are starting to stand on a solid 3 and areas of development into 4. Next steps; develop dashboards further, portfolio reporting. continuous improvement in every aspect of what we do…. Spreading the word! Project: NCMP Release: Set Up & Configuration Sprint:9 of 12 Sprint End Date: 9/4/2013 Manager: Richard Walls SPRINT RELEASE PLANNED SPRINT BACKLOG SPRINT OBJECTIVE RELEASE SUMMARY Story Points Complete online measurement elaboration and commence on R1 Set Up & As an LA User I want to select a collection year to work on and see the data for that5 year Configuration As a Local Authority user I want to suppress warnings as part of the pupil upload preview 5 RAG Summary As an LA Super User I want to view the users for my Local Authority 5 GREEN Elaboration tasks completed As an LA user I want to view Postcode outcomes as part of the data quality dashboard 8 8 As a Local Authority user I want to drill down from the Data Quality dashboard to see the pupils that have a blank child postcode SPRINT VELOCITY As a Local Authority user I want to be able to view and edit the data to be loaded into 8 the system Planned Velocity 60 Velocity increased to 39. As a LA Super User I want to add a new (standard) user to my Local Authority 8 Additional Velocity 0 Higher than expected carry over from two remaining elobartions stories impacted on As an IC user I want to add a super user(s) to the LA 5 Actual Velocity 39 overall total. As an LA Super User I want to manage the roles of a user for my Local 8 Variance from plan 21 Non-grid related stories proving more Authority straightforward as hoped. Started/Not Complete 16 Not Started 5 Work Remaining ADDED DURING SPRINT Story Points 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 Days Remaining Severity Critical 0 Plan v Actual Velocity 332 271 61 28 100 130 -30 450 400 Major Points 8 8 Total Metric Unit test coverage Acceptance test % automated acct tests 16 RAG Green NOT STARTED 250 DEFECT METRICS Actual Summary 3 Defect review meeting organised as thresholds have 3 16 been broken. 13 of the defects 10 16 reported have been accepted by 13 35 the business. CODE QUALITY METRICS Target Actual Summary 70% 84% unit test coverage metric based on statement coverage. 95% 100% Thresho 0 Minor & Cosmetic STARTED / NOT COMPLETED Story As an IC user I want to add a super user(s) to the LA Change to baseline Total 300 END OF SPRINT QUALITY Total Not Completed 64 0 Development is now focused on completing R1 - Set Up & Configuration. This is p 0 64 350 REMOVED DURING SPRINT As a LA Super User I want to add a new (standard) user to my Local Authority As an LA Super User I want to manage the roles of a user for my Local Discovered Requirements, etc. Additional (extra work) RAG GREEN Velocity improved in Sprint 9 and with measurement related functionality behind the team (for now); and the team at full complement, we should now see the team hitting plan. 500 Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Story 420 337 337 83 Planned Done Actual Done Difference Three sprint average Capacity Remaining Capacity Outstanding Remaining Contingency Sprint Burndown 60 Baseline Plan Capacity Scope Of which are Must Haves Contingency Scope of work change n/a 200 150 100 50 0 84% Scope TECHNICAL ARCHITECTURE Summary Review to organised as part of finalising R1. Could Have Should Have Must Have 500 450 400 Points 5 350 0 300 RAG Amber BUSINESS COLLABORATION Summary Continue to monitor. Rosie able to make the demo but not the user group. 250 475 200 150 337 346 349 362 Sprint 1 (or iginally planned) Sprint 2 Sprint 3 Sprint 4 404 423 401 401 Sprint 7 Sprint 8 Sprint 9 100 50 0 Total Not Started De fe cts 5 High Medium Low 40 35 30 25 20 15 10 5 0 3 2 2 0 Sprint 1 Sprint 2 Sprint 3 1 Sprint 4 8 3 7 0 8 9 7 Sprint 5 Sprint 6 Sprint 7 16 12 12 Sprint 8 16 Sprint 9 Sprint 10 Sprint 5 Sprint 6 Sprint 10 So wait a minute… It’s not all about agile. It’s more about the on-going process of improvement in you, your teams and your organisation. It’s like the word/process/principle/method a “ gile” has been taken over. …and the goals have been forgotten. Individuals and interactions Processes and tools Working software Comprehensive documentation Customer collaboration Contract negotiation Responding to change Following a plan 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is faceto-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity — the art of maximizing the amount of work not done — is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. Those things just make sense and to come full circle from what I said at the start… a Forget gile for a moment and think of best practice approaches to development… If you have a process that allows for and encourages continuous improvement in the business value that is provided by your team and you are delivering working software that meets the needs of your customers and users, on time, to a measurable level of quality, then you ARE agile (probably). Thank you for listening… now it’s your turn. DavidmBryant@hscic.gov.uk