An Agile PRINCE?
Successful project delivery with PRINCE2® and Agile
Guy Hancock in an AP nutshell
Project Manager / Business Analyst / Product Designer & Owner / Service
Designer / Techie (dev)
I like PRINCE2® – a lot - an advocate not evangelist
1. Product Based planning
2. Plan-to-plan (see iiBA BABOK too)
3. Emphasis on business case
To date: no drawbacks using or leveraging PRINCE2®
Worked with applied purist Agile: Business PM / Product Owner / BA
•
NOT an Agile expert or evangelist
•
Frequently implemented Agile tools and techniques as hybrid
Overview
•
•
No detailed knowledge of PRINCE2® or Agile required
PRINCE2® or Agile will not be covered in detail
Re the byline: Successful project delivery with PRINCE2® and Agile
•
•
Not a formula to deliver projects successfully
See logical PRINCE2® & Agile intersects (realise the benefits of both)
Assumptions:
•
•
You have some project management and iterative development
concept knowledge
You are not an evangelist who’ll lynch me for criticising Agile 
Agile and PRINCE2®
RED corner – Agile
Blue corner – PRINCE2
Once an “Us versus them” heated philosophical or dogmatic battle for
hearts and minds.
I believe:
•
Rational minds have prevailed and hybrids evolved because of experience,
thought and pragmatism (PRINCE2 / Agile method)
•
Not the result of poor knowledge or skill sets
Is it a project?
You could say a project is….
“A temporary organisation structure that consumes
resources, time and money to deliver a new product or
service to realise business benefits*”
*Seize opportunities, counter threats
•
Projects need project management (the temporary manager).
•
Agile is not project management.
•
Support & maintenance capability / pipelines are not projects
Project delivery success
Completed within the constraints of Time, Cost, Quality (P2)
Agile : Why not sacrifice some ‘arbitrary goals’ until the requisite quality is
achieved?
•
Because there are more than one important stakeholder in a project.
•
Spending over a certain amount of money or time may delay benefits or diminish
metrics such as NPV removing justification for the expenditure
PRINCE2®
•
Planning to deliver a fit-for-purpose solution at the time to realise benefits
•
Monitor the business case to respond to internal and external forces
PRINCE2® myths
PRINCE2® is NOT waterfall or PMP!!!!
•
PRINCE2® says do just enough to plan / estimate to within accepted
tolerances.
•
PMP Says 70% of cost should be planning
•
PMP how-to’s HR | financial mgmt. etc. in detail.
•
PRINCE2® does not say how, it says what, when, why.
•
PRINCE2® describes product descriptions in detail (templates etc.), not how to
get the information.
•
PMP really wants those requirements up front!
Agile pro’s & con’s
AGAINST
FOR
•
Agile iterations provide clear time boxed
•
geek t-shirt, FussBall)
chunking of work
•
Teams develop discipline to deliver usable
•
have to do boring stuff – like doco!!!
machine).
Self-organised teams deliver real
productivity and problem solving benefits
(collective intelligence).
•
Sprints make regular checkpoints
•
Release, with full review, is something done
•
Perfect approach for system
•
Business does not owe workers a high
entertainment workplace – sometimes you just
value with regularity (cadence / sausage
•
It may become all about the vibe! (the thongs,
•
A project is about more than the user, broader
benefit myopia
•
Team feels under pressure to constantly show
evidence of customer visible work (interface)
•
Team focuses only on product owners wishes
•
Don’t bring in the Product Owner until the
foundation work is done.
enhancements / maintenance
•
80/20 or Occam’s Razor
It is growing up (SAFe) but creating waves
•
Technical debt & deferring decisions
in the community
•
Flaky software
•
Slow to evolve in response to failings
The Agile PRINCE2® approach
As in Lean….
“Act as fast as possible but slow as necessary”
Be pragmatic. Please!!!
•
Don’t be a slave to an approach
•
Use Agile where it makes sense and adds real value
•
Use PRINCE2® where Agile needs rigour or control
Don’t be precious about terminology
•
You don’t need to call it Agile to be agile
•
Use tools and techniques that suit the team and the work
•
Is your management style compatible
Are you an unknowing victim?
Your vendors may have been using Agile or iterative development with your projects already
Product Break Down (PBS)
Identifying components of specialist
products is done in the Product
Breakdown Structure (PBS).
“Yes, it’s an
upside down WBS!”
Authentication
My HR
Software
Training
Training
material
Communications
Newsletter
User Interface
design
Logistics
Email
Front-end
Application
PRINCE2® uses constraints and product based planning
Agile uses Themes, Epics, Stories
Database
Agile eligible components
My HR
Software
What could
benefit from or is compatible
with
Training
Communications
Agile?
1.
Authentication
User Interface
design
Where specifics unknown but risk is low
Training
2.
3.
(superficial work)
Newsletter
Where
>
material
Where build requires close feedback loop with a
Logistics
stakeholder
Front-end
4.
Application
Database
SV is small
Email
Where work can be chunked into logical, interindependent components
5.
Where a vendor is doing the work
Epics / Specialist products
My HR
PRINCE2® says do just enough to plan /
estimate to within accepted tolerances.
Software
Authentication
Training
Training
material
Newsletter
Make 1st level
decomposition into
epics Email
User Interface
design
Manage
employee
Front-end
Manage
system users
Application
Control theme
Database
Logistics
Epics:
Are groups of related stories that
deliver chunks of meaningful value.
* Stories too granular to exist alone
Prince2® Framework
We
are
here
PRINCE2® delivery*
*Delivery of specialist products that solve the business problem, not plans or
project artefacts
Agile process
Problem statement
Vision
Often 3 sprints
The work package
•
The products acceptance criteria (the what) defined up front (test
driven development)
• Specialist products are defined in terms of fitnessfor-purpose
•
PRINCE2® explicitly assigns responsibility for how the work package is
executed to the one accepting the work package (technical PM /
Scrum Master / Iteration manager / team lead etc.)
Agile focus (Manage Product delivery)
Define next
release backlog
at Stage
Boundaries
Work Package
[WP]
Accept | execute | deliver
Plan next
stage (SB)
Epics:
Epics:
Retain the Agile focus on development
and delivery, not backlog negotiation
Quality & non-functional requirements are
constraints, not readily negotiated
Questions