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 Product Backlog Customer feedback / issues Demo feedback/ Actual Velocity Release Release Backlog Sprint Retrospective PID High-level Requirements IT Strategy Process Improvements Daily Scrum Daily adjustments Release Planning Sprint Planning Candidate Release Accepted Candidate Release UAT Demo Product owner Scrum master Delivery team Backlog management Planning poker
Measuring progress, summer 2012: The following scores indicate IT Development-centric maturity. Number of projects using agile7/7 Number of projects with iteration cycles7 Number of projects with Test Driven Development6 Number of projects using User Stories6 Number of projects with continuous integration7 Number of projects with acceptance testing within iteration5 The following scores indicate that a wider adoption of agile methods is being achieved. Number of projects with Product Owner sourced from business3 Number of projects with Product Owner owning backlog2 Number of projects with Product Backlog as single source of reqs3 Number of projects with continuous release planning4
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 a gile is… Great – how many problems?
Our use of a gile 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!
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) a gile 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 5Value / 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!
So wait a minute… It’s not all about a gile. 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 Working software Customer collaboration Responding to change Processes and tools Comprehensive documentation Contract negotiationFollowing 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 face- to-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… Forget a 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