View
793
Download
0
Embed Size (px)
DESCRIPTION
Assurance of agile projects conference, 27th November 2013
Citation preview
What business performance looks like with poor IT performance
1
Agile Project Governance
Introductions
Peter Measey – RADTAC CEO
BCS Agile Committee
Certified Scrum Trainer
PMI-Agile Certified Practitioner
DSDM Certified Trainer
APMG Certified Lean
Prince2 Practitioner
Ex DSDM Board Director
Public & Private sector experience
30 years mainly Information Technology
Agile specialist since 1994
Worldwide Agile trainer and consultant
2
© RADTAC 2013
What we’ve learned from 15 years……
3
© RADTAC 2013
What is ‘Agile’, Why do it ?
4
© RADTAC 2013
What is Agile
Why do Agile
Standish Group Chaos Report
2002
Cutter Consortium 2007
Why Agile ?
What is Agile - Iterations / Sprints
When to use Agile ?
What is Agile – Project Context
Agile Assurance
9
© RADTAC 2013
In terms of providing assurance to stakeholders in an agile
environment how does our approach have to change?
The role of assurance in agile environments is definitely NOT
business-as-usual, so what is it?
Most ‘Agile’ fails because it isn’t agile
WAgile
FrAgile
SNAgile
Method fundamentalism can be an issue
‘Pragmatic Agile’
Is Agile doing any good
The point of Agile isn’t perfect Agile, the point of
Agile is excellent delivery governed effectively
10
Assurance
© RADTAC 2013
Agile Stakeholder Assurance – Delivery !
© RADTAC 2013
12 © Copyright RADTAC 2010
Delivery Assurance - Measure Team ‘Agility’
© RADTAC 2013
Transformation Assurance - Measure the improvement
Value Predictability
Quality Productivity / Flow
Net Promoter
Score
Running Tested
Features Increment
Burndown
Velocity /
Throughput
Escaped
Defects
Technical
Debt
Cycle Time
&
Work in
Progress
© RADTAC 2013
The Shallow Wave
Individual teams adopt their own way of working
The way of working is compatible with existing method of programme and project management
Not a sustainable change outside of the team, when members depart the way of working is likely to collapse
Has little Enterprise benefit, in fact is unlikely to deliver any benefit as it sits in isolation surrounded by
Constraints
The Breaking Wave
‘All senior team on Board, ‘gung-ho’ , flavour’ of the month
It is a managed and ‘driven’ adoption.
Small project teams at layer 3 embrace ideas
Layer 2, ‘The Frozen Middle’ not engaged, wave crests, breaks and collapses, senior team ‘walk away’
Layer 3 get beaten up by layer 2 for being so ‘stupid’ – don’t do it again
The Sustainable Wave
Change comes from in all layers in a vertical slice through the organisation
The change is ‘Led’ through adoption and demonstrable behaviour
Company starts small and acts fast to expand
Scalable growth horizontally across the whole enterprise – horizontal stripe
‘T’ Shaped People – ‘T’ Shaped Organisation
Horizontal Stripes are where most people would recognise Agile implementations – IT Teams and departments
Vertical Slice is where true change is required to effect sustainable Transformation
Why Most Transformation is unsuccessful (60-70% fail – McKinsey - Inconvenient Truth About Change Mang’t
http://bit.ly/16HRxlZ)
Transformation Assurance - Measure the ‘Change Wave’
© RADTAC 2013
What is documentation?
• Design documentation
• Code documentation
• User documentation
• Support documentation
• Operational documentation
How does it emerge?
Emergent Documentation
© RADTAC 2013
Are we on Track – Visual Boards
© RADTAC 2013
Right Product ? Show and Tells
© RADTAC 2013
Right Approach - Retrospectives
© RADTAC 2013
Agile Across the Value Chain
19
© RADTAC 2013
What happens when supply-chain implement agile when the
client’s expectations’ or commitments’ don’t ‘fit’ the agile
model?
Arch Test Back
End
Build
Front
End
Build
Design Analysis
Customer
Features
Wanted
Something
Delivered
(eventually)
= Process or product or
signoff point
Waterfall Value Chain
© RADTAC 2013
Arch
Skills
Highest
Priority
Feature/s
Wanted
Analyst
Skills
Design
Skills
Coding
Skills
Test
Skills
Product
Owner
Highest
Priority
Feature/s
Delivered
(immediately)
Focus on
Highest
Priority
Features
Wanted/ Highest
Priority
Feature/s
Agreed
Product
Backlog
Agile Value Chain – wide as possible
© RADTAC 2013
Agile vs Conventional ‘Waterfall’
22
© RADTAC 2013
Should we be shifting our attention to smaller teams
incrementally delivering quality products instead of the
conventional lifecycle methodology?
Will assurance in an agile world mean: face-to-face
conversations, better collaborations between acceptance
(testers) and developers, developers and designers, suppliers
and end-users?
Does integrated assurance in an agile world mean that we have
to re-think the definition of ‘integration’ to one that stems back
to basics where clients and delivery teams communicate and
collaborate?
Business and Developers Work Together
Team size 7 plus or minus 2
Face-to-face Communications
Deliver Working Systems Frequently and collaboratively
Satisfy the Customer with
Continuous Delivery of Value
Legal / Safety; Roles and responsibilities
27
© RADTAC 2013
What about legalities and/or safety-critical issues when
delivering with agile – how does assurance play its part?
Where we have to redefine roles and responsibilities
Agile Quality Assurance and
Testing Quality Assurance
Regular delivery of a working product
Agile testing
Acceptance criteria
TDD, ATDD, BDD
Automated testing
Continuous integration, build and deploy
User Acceptance
Hold the product vision
Prioritise work
Communicate with the business
stakeholders
Assist with issues
Approve the work
The Role of the Customer
Decide how to do work
Decide who does the work
Estimate the work
Do the work
The Role of the Team
Provide governance
Provide finance
Provide support
Provide blockers!
The Role of the Stakeholders
Final Thoughts…..
32
© RADTAC 2013
This most important thing you could learn ?
Recognising that while Agile may be/seem easy…..
TRANSFORMATION ISN’T !!
Many organisations flounder with Agile
Especially when attempting to scale - they become ‘burn victims’
So then they get help - after wasting much time, effort and money
… and people!
… and so the perception then is that “Agile failed”
33
© RADTAC 2013
C
A
P
A
B
I
L
I
T
Y
TIME
Kanban transformation
– transformation experts involved
Not supported – long, painful, costly transformation
Not supported – failed change
Transformation experts involved
Support from experts is required
© RADTAC 2013
Would you re-platform a technical capability without
technical experts ?
How about not employing transformation experts when
the ‘platforms’ are human beings ?
“the definition of insanity is doing the same thing
over and over again and expecting different results”
And then measuring the same results (repeated
failure) over and over again !
35
Start with Visualising - WHY
© RADTAC 2013
Peter Measey – RADTAC CEO
Office: +44 (0) 203 6385040
Mobile: +44 (0) 7970 435290'
Web: http://radtac.co.uk
Majority of slides from BCS Agile Foundation Certification
Course (BCS syllabus and course created by RADTAC)
APM - Agile
36
© RADTAC 2013