Agile – so what’s that all about then?

1. Agile – so what’s that all about then? Presenter: David Bryant DavidmBryant@hscic.gov.uk

2. 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

3. What am I going to talk about? A brief history of my team, the readers digest version. A few observations about maturity and progress.

4. He might be happy but…

5. 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

8. So we had… Some good foundationsand 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.

9. Process Improvements Daily adjustments Retrospective Product Backlog Accepted Candidate Release PID High-level Requirements IT Strategy Release Backlog Candidate Release Daily Scrum Release UAT Demo Release Planning Sprint Planning Sprint Demo feedback/ Actual Velocity Customer feedback / issues SCRUM in a nutshell Product owner Scrum master Delivery team Backlog management Planning poker

10. So, are we agile now?

11. 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 3 Number of projects with Product Owner owning backlog 2 Number of projects with Product Backlog as single source of reqs3 Number of projects with continuous release planning 4

12. So that’s pretty good then isn’t it? At least so I thought…. What you don’t know can hurt you.

13. 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?

14. Our use of agile did not create these problems… They were already there!

15. 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!

16. The IT Development Framework

18. My first response…

19. 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….

20. 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)

21. 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?

22. 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.

23. 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.

24. So back to maturity… CMMI view. Level 1 Chaotic / Ad Hoc, undocumented, not repeatable, uncontrolled change Where we started Level 2Reactive / 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 Value/ Optimising, focus on continual process improvement through incremental and innovative changes. 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!

26. 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 “agile” has been taken over. …and the goals have been forgotten.

27. We value Over

28. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity — the art of maximizing the amount of work not done — is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

29. Those things just make sense and to come full circle from what I said at the start… Forget agile for a moment and think of best practice approaches to development…

30. 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).

31. Thank you for listening… now it’s your turn. DavidmBryant@hscic.gov.uk