Upload
lucia-garcia
View
237
Download
2
Embed Size (px)
Citation preview
Outline
Agile: Delivering value – early and often
Governance and Ownership
GDS – Governance Principles and Guidelines
Presentation by: Name here
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
Customer Collaboration over contract negotiation
Individuals and Interactions over processes and tools
Responding to Changeover following a plan
Working Softwareover full documentation
Agile Manifesto – delivering value
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
“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
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
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
Don’t slow down delivery
Be available when needed
Remove impediments to delivery teams
Protect the team – help them to handle
external pressures
Key differencesTraditional 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
Decisions when they are needed, at
the right level
Empower the team
Handle change through continuous
iteration
Timebox boundaries
Showcase – stakeholder management
Review – assurance and decision making
Retrospective – continuous improvement
Planning – decision making
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
Solution
Developer(s)
Solution
Tester(s)
Business
Ambassad
or
Business
Advisor
Business
Analyst
Project
Manager
Business
Sponsor
Team
Leader
Technical
CoordinatorBusiness
Visionary
Technical
Advisor
User
Agile Team
Roles
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
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
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
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
Deployment
Feasibility
Foundations
Delivery
DSDM has more frequent control points than
traditional projects
Discovery
Inception
Alpha Beta Service
Standard
Live
Sprint Reviews
Service Standard
Digital by default
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
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
TestCo-ordination
Resourcing“Communities of Practice”
ArchitectureIntegrationInterfaces
Coach /Facilitator /
Culture
BusinessDesign
Authority
PortfolioFacilitator
Agile Portfolios
/
Programmes
UX Design
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
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
Practices
• Facilitated workshops
• MoSCoW
• Iterative Development
• Modelling
• Timeboxing
Presentation by: Name here
Must
Should
Could
Won’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
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
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