Hugh Ivory, Managing Partner - Agilesphere, member of DSDM Consortium
1. Governance for Agile Service Delivery
Hugh Ivory, Managing Partner
Hugh.ivory@agilesphere.eu
2. Outline
Agile: Delivering value – early and often
Governance and Ownership
GDS – Governance Principles and Guidelines
Presentation by: Name here
3. DSDM Consortium -
• The mission of DSDM Consortium is to develop and promote a
high standard of practice and learning for successful Agile
projects
• More than 35,000 AgilePM® exams have been taken globally
since 2011
• There are over 160 Training Providers offering AgilePM®
• The DSDM Agile Project Framework and AgilePM® have been
translated into various different languages
Presentation by: Name here
4. Customer Collaboration
over contract negotiation
Individuals and Interactions
over processes and tools
Responding to Change
over following a plan
Working Software
over full documentation
Agile Manifesto – delivering value
7. Legal and other common sense controls that need
to be in place…it’s other people’s money that we
are spending
Good governance can help with timely decision
making, continuous improvement and appropriate
stakeholder engagement
Key issue: how to govern while maximising agility /
minimising bureaucracy
Governance
8. “Regardless of what we discover, we
understand and truly believe that everyone
did the best job they could, given what
they knew at the time, their skills and
abilities, the resources available, and the
situation at hand”
Core Assumption
9. So what’s different?
Lighter weight and incremental approvals
Team structures aligned to products and
services rather than disciplines or functions
Shorter more frequent governance forums
Greater empowerment of teams and individuals
Different ways to conduct assurance and audit
New terminology and artefacts
10. Governance principles
Don't slow down delivery
Decisions when they’re needed, at the right level
Do it with the right people
Go see for yourself
Only do it if it adds value
Trust and verify
https://www.gov.uk/service-manual/agile-delivery/governance-
principles-for-agile-service-delivery
11. Don’t slow down delivery
Be available when needed
Remove impediments to delivery teams
Protect the team – help them to handle
external pressures
12. Key differences
Traditional projects
– Change is the exception
– Small number of large sign-offs
– Hierarchical control
– Perceived certainty
Agile projects
– Change built in
– Small sign-offs every 2 weeks
– Delegated control, peer discipline
– Transparency
Seed the team, give them what they need, protect
them
13. Decisions when they are needed, at
the right level
Empower the team
Handle change through continuous
iteration
14. Timebox boundaries
Showcase – stakeholder management
Review – assurance and decision making
Retrospective – continuous improvement
Planning – decision making
15. Do it with the right people
Ensure that everyone involved is capable,
motivated and empowered
Create an environment where everyone is
open and honest about what they do
17. Go see for yourself
Visit delivery teams to see the value
Talk face-to-face
Go see the thing
18. Minimum Viable Reporting
Agree what when how to report
Use the stuff that the team are producing
Some key “reports”
Show and tell
Team wall
A3 dashboard report
Burndown / up
Roadmap
• Financial
20. Only do it if it adds value
Keep business (user) needs at the forefront
Set out clear vision and measures of success
Deliver value early and continuously
21. Foundations: Discovery
At the beginning of a project
– Everything is uncertain
– Analysis delivers very little RoI
– Over analysis is wasteful
– Some framing of the project is essential
– Don’t want to spend big to prove feasibility
22. Foundations: Discovery
Run as an agile project
c. 6 weeks (3 x 2 week sprints)
Frame core elements of project
– Vision
– High level business case
– High level requirements
– Initial project budget for e.g. first 3 months
25. Trust and verify
Build simple supportive governance
which trusts individuals and teams and
allows them to focus on delivery
Speak to the team regularly to support,
steer and assure
29. Structures - Scaling Agile
Keep team structure - minimise dependencies between
teams
• Constantly look out for artificial dependencies
• Mock interfaces early to define / minimise dependency and
maintain assiduously
• Increase team size rather than split artificially
• Keep multiple Agile teams as independent as possible
• Manage multiple Agile teams more like a traditional portfolio
Primary governance at project level not portfolio to ensure
transparency
31. Project teams – leading delivery
Self-contained i.e. all roles specifically
including daily user / business input
Co-located focused on their specific
deliveries
Delegated control over day to day priorities /
activities
Testing and delivery of their scope
Governance at the individual team level
32. Programme Team – supporting
Holding the vision for how it all fits together
Overall scope prioritisation
Release management
Standards and integration e.g. UX, testing, development
Resourcing, recruitment, training and coaching
Broader stakeholder communication
Cross project dependencies / issues
Removing impediments
Foundations for new projects / significant new releases
36. Must
Should
Could
Wo
n’t
Presentation by: Name here
Practices MoSCoW Prioritisation
Must
Should
Could
Won’t*
Minimum Useable SubseT
Work arounds difficult/costly
Work arounds easy/cheap
Out of Scope this time around
Guaranteed
Expected
Bonus
Maybe next time
Cannot be de-scoped without causing the project to fail
De-scoped as a last resort to keep the project on track
Can be de-scoped without causing significant problems
* Won’t have this time
38. Presentation by: Name here
Managing Risk - Factors for Success
Embrace the DSDM Approach
Build an Effective Team
Empowered
Stable
Skills and Knowledge
Business Engagement – Active and Ongoing
Active commitment of the Business Roles
A supportive Commercial Relationship
Iterative Development, Integrated Testing, Incremental Deployment
Transparency
39. Presentation by: Name here
Managing Risk - Project Approach Questionnaire
Purpose
• To assess how the Atern approach should be
applied
• To help identify potential areas of risk, based on
the Instrumental Success Factors
When?
• Feasibility
• Then reassess in Foundations
