presenter: david bryant [email protected]
TRANSCRIPT
Presenter: David Bryant
Agile – so what’s that all about then?
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 FoundationsEnvironments - 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
PIDHigh-level RequirementsIT Strategy
Process Improvements
Daily Scrum
Daily adjustments
Release Planning Sprint Planning
Candidate Release
Accepted Candidate Release
UATDemo
Product owner
Scrum master
Delivery team
Backlog management
Planning poker
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 3
Number of projects with Product Owner owning backlog 2
Number of projects with Product Backlog as single source of reqs 3
Number of projects with continuous release planning 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!
The
ITD
evel
opm
ent
Fram
ewor
k
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 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!
Project: NCMP Release: Set Up & Configuration
Sprint:9 of 12Sprint End Date: 9/4/2013Manager: Richard Walls
Story Points RAG As an LA User I want to select a collection year to work on and see the data for that year5 Capacity 420As a Local Authority user I want to suppress warnings as part of the pupil upload preview5 RAG Scope 337As an LA Super User I want to view the users for my Local Authority 5 Of which are Must Haves 337As an LA user I want to view Postcode outcomes as part of the data quality dashboard8 Contingency 83
As a Local Authority user I want to drill down from the Data Quality dashboard to see the pupils that have a blank child postcode8As a Local Authority user I want to be able to view and edit the data to be loaded into the system8 Planned Velocity 60 Discovered Requirements, etc. 64As a LA Super User I want to add a new (standard) user to my Local Authority 8 Additional Velocity 0 Additional (extra work) 0
As an IC user I want to add a super user(s) to the LA 5 Actual Velocity 39 Change to baseline 0As an LA Super User I want to manage the roles of a user for my Local Authority
8 Variance from plan 21 Total 64
Started/Not Complete 16
Not Started 5 Planned Done 332Actual Done 271Difference 61Three sprint average 28
60 Remaining Capacity 100Outstanding 130
Story Points Remaining Contingency -30
0
Severity Thresho ActualCritical 0 3
0 Major 3 16
Minor & Cosmetic 10 16
Story Points Total 13 35
As a LA Super User I want to add a new (standard) user to my Local Authority 8As an LA Super User I want to manage the roles of a user for my Local 8 Metric Target Actual
Unit test coverage 70% 84%
Acceptance test 95% 100%% automated acct
testsn/a 84%
Total Not Completed 16 RAG
Story PointsAs an IC user I want to add a super user(s) to the LA 5
RAG
Total Not Started 5
SPRINT
PLANNED SPRINT BACKLOG
SPRINT VELOCITY
RELEASE
RELEASE SUMMARY
NOT STARTED
CODE QUALITY METRICS
END OF SPRINT QUALITY
unit test coverage metric based on statement coverage.
Summary
Summary
STARTED / NOT COMPLETED
DEFECT METRICSSummary
Defect review meeting organised as thresholds have been broken. 13 of the defects reported have been accepted by the business.
Amber Continue to monitor. Rosie able to make the demo but not the user group.
BUSINESS COLLABORATION
TECHNICAL ARCHITECTURE
Green Review to organised as part of finalising R1.
Summary
SPRINT OBJECTIVE Complete online measurement elaboration and commence on R1 Set Up & Configuration
GREEN Elaboration tasks completed
Capacity
Baseline Plan
Scope of work change
Plan v Actual Velocity
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 hitti ng plan.
Development is now focused on completing R1 - Set Up & Configuration. This is p
ADDED DURING SPRINT
REMOVED DURING SPRINT
Summary
Velocity increased to 39.Higher than expected carry over from two remaining elobartions stories impacted on overall total. Non-grid related stories proving more straightforward as hoped.
00.10.20.30.40.50.60.70.80.9
1
Day0
Day1
Day2
Day3
Day4
Day5
Day6
Day7
Day8
Day9
Day10
Day11
Day12
Day13
Day14
Day15
Work
Rem
ain
ing
Days Remaining
Sprint Burndown
07 9 7
1216
0 1
38
8
12
16
0
20
2
3
0
5
10
15
20
25
30
35
40
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10
DefectsHigh Medium Low
337 346 349 362404
475423 401 401
0
0
50
100
150
200
250
300
350
400
450
500
Sprint 1(originallyplanned)
Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10
ScopeCould Have Should Have Must Have
0
50
100
150
200
250
300
350
400
450
500
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.
Individuals and interactions
Working software
Customer collaboration
Responding to change
Processes and tools
Comprehensive documentation
Contract negotiation
Following a plan
Over
We value
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 agile 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).
