Transcript Agile * so what*s that all about then?

Presenter: David Bryant
[email protected]
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.
[email protected]