This document discusses agile project governance and assurance. It begins with introductions to the author and their experience. It then discusses lessons learned from 15 years of agile experience. Some key topics covered include what agile is and why do it, when to use agile, agile assurance, delivery assurance through measuring team agility, transformation assurance through measuring improvement, emergent documentation, visual boards, retrospectives, agile across the value chain, agile vs conventional approaches, roles and responsibilities, quality assurance and testing in agile, the roles of customers, teams and stakeholders, and final thoughts on the importance of transformation expertise.

1. Agile Project Governance
What business performance looks like with poor IT performance
1

2. 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
© RADTAC 2013
2

3. What we’ve learned from 15 years……
© RADTAC 2013
3

4. What is ‘Agile’, Why do it ?
What is Agile
Why do Agile
© RADTAC 2013
4

5. Why Agile ?
Standish Group Chaos Report

6. What is Agile - Iterations / Sprints

7. When to use Agile ?

8. What is Agile – Project Context

9. Agile Assurance
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?
© RADTAC 2013
9

10. Assurance
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
© RADTAC 2013

11. Agile Stakeholder Assurance – Delivery !
© RADTAC 2013

12. Delivery Assurance - Measure Team ‘Agility’
© Copyright RADTAC 2010
12
© RADTAC 2013

13. Transformation Assurance - Measure the improvement
Value
Predictability
Net Promoter
Score
Running Tested
Features
Velocity /
Throughput
Increment
Burndown
Quality
Escaped
Defects
Productivity / Flow
Cycle Time
&
Work in
Progress
Technical
Debt
© RADTAC 2013

14. Transformation Assurance - Measure the ‘Change Wave’
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)
© RADTAC 2013

15. Emergent Documentation
What is documentation?
• Design documentation
• Code documentation
• User documentation
• Support documentation
• Operational documentation
How does it emerge?
© RADTAC 2013

16. Are we on Track – Visual Boards
© RADTAC 2013

17. Right Product ? Show and Tells
© RADTAC 2013

18. Right Approach - Retrospectives
© RADTAC 2013

19. Agile Across the Value Chain
What happens when supply-chain implement agile when the
client’s expectations’ or commitments’ don’t ‘fit’ the agile
model?
© RADTAC 2013
19

20. Waterfall Value Chain
Arch
Analysis
Design
Front
End
Build
Back
End
Build
Test
Customer
Features
Wanted
Something
Delivered
(eventually)
= Process or product or
signoff point
© RADTAC 2013

21. Agile Value Chain – wide as possible
Product
Backlog
Arch
Skills
Focus on
Highest
Priority
Features
Wanted/
Analyst
Skills
Highest
Priority
Feature/s
Wanted
Highest
Priority
Feature/s
Agreed
Product
Owner
Design
Skills
Test
Skills
Coding
Skills
Highest
Priority
Feature/s
Delivered
(immediately)
© RADTAC 2013

22. Agile vs Conventional ‘Waterfall’
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?
© RADTAC 2013
22

23. Business and Developers Work Together
Team size 7 plus or minus 2

24. Face-to-face Communications

25. Deliver Working Systems Frequently and collaboratively

26. Satisfy the Customer with
Continuous Delivery of Value

27. Legal / Safety; Roles and responsibilities
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
© RADTAC 2013
27

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

29. The Role of the Customer
Hold the product vision
Prioritise work
Communicate with the business
stakeholders
Assist with issues
Approve the work

30. The Role of the Team
Decide how to do work
Decide who does the work
Estimate the work
Do the work

31. The Role of the Stakeholders
Provide governance
Provide finance
Provide support
Provide blockers!

32. Final Thoughts…..
© RADTAC 2013
32

33. 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”
© RADTAC 2013
33

34. Support from experts is required
Would you re-platform a technical capability without
technical experts ?
How about not employing transformation experts when
the ‘platforms’ are human beings ?
Transformation experts involved
C
A
P
A
B
I
L
I
T
Y
Kanban transformation
– transformation experts involved
Not supported – long, painful, costly transformation
Not supported – failed change
TIME
© RADTAC 2013

35. Start with Visualising - WHY
“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
© RADTAC 2013

36. APM - Agile
Peter Measey – RADTAC CEO
peter.measey@radtac.co.uk
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)
© RADTAC 2013
36