Roger Garrini Directing Agile Change Successful change - good culture and governance matter APM Governance Specific Interest Group Conference London, 06 Oct 2016

1. Guidance to the governance of
Agile Project Management
Directing Agile Change

2. Why we need a Guide for Governance
of Agile Project Management
 Growingly popular topic in P3M
 Guide produced in response to requests
 Mythology about Agile scares the Board
 Help to explain the change in mind set needed

3. Who is it for?
 Those involved in governance of all change initiatives
 All Boards
– Organisation, Society, Programme and Project
 Influencers of the Board
– E.g. assurers, portfolio managers
 Sponsors
 Stage gate reviewers
 Programme and Project Managers

4.  Iterative Delivery
 Collaborative Behaviour
 Decisions at the work face
 New measures of progress
Agile - The Essential Difference
It’s a different mindset

5.  Discipline is still required (business case, requirements,
configuration, etc.)
 A Fad? - No
 Agile is not the only way
 Not just for software
 Agile only works for small projects
 Need to adjust existing governance processes
The Myths
More listed in guide

6. Some Principles
 Waterfall vs Agile - how to decide
 Directing Change is a valid basis for PM
Governance
 Incremental delivery
 Collaboration
 Just Enough Definition
 Learn as you go

7. Core Principles of Agile
Faster development and Change
Constant focus on the
goal
Collaborative working
Flexibility
Delegated decision
making
Value people more
than process
High Level
 Satisfy the customer - Produce outcomes that
result in benefits – incrementally / regularly in order of
priority
 Value driven and time box where possible
 Clear roles and responsibilities
 Enough definition to get started
 Embrace changing requirements with
robust change control
 Sustainable environment for success
 Empower the team to make rapid decisions
 Collaborative behaviours based on Trust
and quality communications
 Simple keep it simple
 Reflect, learn and adjust at regular intervals
 ‘Fail early’ if results disappoint

8. Key Roles and Techniques
Key Roles (major transformation)
 Business (Programme) Sponsor
 Business Visionary (or Product owner)
 Programme Manager
 Technical Co-ordinator or Business Architect
 Project Manager or Scrum Master
 Business Change owner / lead
 Agile Coach
 Business Process Analysts
Tools / Techniques
 DSDM Atern
 SCRUM
 Lean
 KanBan
 MoSCow
 Timeboxing

9. When to Consider Agile

10. Traditional Factors Agile
Tends to be top-down Leadership Tends to be bottom-up
Centralised Control De-centralised
Hierarchical Decision making Delegated and team based
Learnings captured at end.
Intolerance to mistakes
Learning Continuous improvement and learning
through testing / using. Tolerance of
mistakes where lessons learnt
On Outputs at each stage Focus during project
delivery
On incremental delivery of Outcomes and
prioritised Value / Benefits at each release
date (time box)
Some staff part time alongside other
projects
Resourcing Dedicated staff in close knit teams
Directed Team operation Self-organising and collaborative. Rigorous
Engagement
Driven by standard business meeting
timetable
Business Control Driven by project need
Scope and functionality tends to be
fixed
Objectives Time and / or cost are fixed
Dealt within project deliverable via
change control
Major Changes to
outputs
Dealt with outside current release –
changed functionality included in
subsequent releases
Assumed to be predictable – narrow
range of options desired
End Outcome Evolving – range of outcomes allowed
Progress to time, cost, quality Performance
measurement
Delivery of prioritised benefits at each
release
Guided by agreed TOR Strategic Guidance Focussed by the vision
Governance differences

11.  Leadership not Direction
 New Behaviour is paramount to improve
Organisational Culture
 Agile Training is essential
– Board, PM, Sponsor and team
 The team is driving and making decisions
 Thinking not management rote
Some Hints and Tips

12. Behaviour & Culture
 Board
– Support strongly, stay back, set clear objectives
– Empower
 Project Sponsor / Product Owner
– Engage, embrace, enjoy (and dedicate time as part of
team)
 Project Manager / Delivery Lead
– Delegate, collaborate, remove blockages
– Build and empower the team

13. The Lists in the Guide
 Not a check list!! Comply or explain?
– To your own satisfaction, this is Guidance not a
Recipe
 Your choices matter
– As a Board
– As a Sponsor
– As Project Manager
– As an independent reviewer

14. Communicat
e for Buy-in
Empower
Action
Create Short-
term Wins
64 5
Don’t Let
Up
Make it
Stick
7 8
Increase
Urgency
Build the
Guiding Team
Getthe
Right
Vision
2 31
“Eight Steps of Change”
5 Kotter, John P. and Cohen, Dan S. The Heart of Change. Boston: Harvard Business School Press
Engaging and enabling
the whole organisation
Creating a
climate for change
Implementing
and sustaining
change
Treat Agile like any other major
transformation of the business

15.  Paperback: 246x189mm, 2016
Publisher: APM
Author: APM Governance Specific Interest Group
ISBN 978-1-903494-60-8
Publication date: September 2016
Price: £15.00
Discount: 10% off for APM members
APM members should contact Turpin Distribution on
+44 (0)1767 604951 to receive their 10% discount
Details

16.  Paperback: 246x189mm, 2016
Publisher: APM
Author: APM Governance
Specific Interest Group
ISBN 978-1-903494-60-8
Publication date: September
2016
Price: £15.00
Discount: 10% off for APM
members
APM members should contact
Turpin Distribution on +44
(0)1767 604951 to receive their
10% discount
 via APM Website
Where to get it

17. Manifesto for Agile
Software Development
We are uncovering better ways of developing software by doing it and helping
others do it.
Through this work we have come to value:
 Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
 That is, while there is value in the items on
the right, we value the items on the left more.

18. We follow these principles:
 Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
 Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
 Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
 Business people and developers must work
together daily throughout the project.
 Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
 The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Principles behind the Agile Manifesto
(1-6 of 12)

19. Principles behind the Agile Manifesto
(7-12 of 12)
 Working software is the primary measure of progress.
 Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
 Continuous attention to technical excellence
and good design enhances agility.
 Simplicity--the art of maximising the amount
of work not done--is essential.
 The best architectures, requirements, and designs
emerge from self-organising teams.
 At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.

20. This presentation was delivered
at an APM event
To find out more about
upcoming events please visit our
website www.apm.org.uk/events