pete measey, agile project governance

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

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)

APM - Agile

36

© RADTAC 2013