1

2

Uitnodiging BPUG sessie en Nieuwjaarsborrel 6 januari 2016

PRINCE2 Agile Hoe 'agile' kun je je project maken?

Tijdens deze Nieuwjaarssessie krijg je inzicht in het nieuwe PRINCE2 Agile raamwerk.

Henny Portman neemt je mee in de opbouw van PRINCE2 Agile en componenten als Lean start-up, Scrum, Kanban, het Cynefin raamwerk

en het blended model van PRINCE2 en Agile. Daarnaast staat hij stil bij de 5 gedragscomponenten, de vaste en flexibele projectcontrole-

aspecten (tijd, geld, scope, kwaliteit, risico’s en baten) en de achterliggende doelstellingen.

Om vast te kunnen stellen hoe agile een project ingericht kan worden maakt deze methodiek gebruik van het assessmenttool de ‘Agilometer’.

De officiële manual beschrijft helaas alleen de randvoorwaarden van het hoogste niveau (5) waarop Agile zo maximaal mogelijk ingezet kan

worden. Hoe werkt het op de ontbrekende vier niveaus?

Tijdens een interactief workshopdeel werken we gezamenlijk de ontbrekende levels van deze Agilometer uit. We bepalen de definities van de

verschillende aspecten en beschrijven per level het bijbehorende gedrag om zo de ‘agility’ van de randvoorwaarden toetsbaar en inzichtelijk te

maken.

Spreker:

Henny Portman is verantwoordelijk voor methoden, technieken, standaards en opleidingen binnen het PM(O) gebied van NN Group. Hij heeft

PMO’s opgezet, ingericht en laten samenwerken binnen (Oost-) Europa en Azië. Daarnaast is hij een gepassioneerd PMO consultant, trainer,

auteur en blogger. Naast zijn werk binnen NN Group is Henny tevens partner bij Hedeman Consulting.

Biography: Henny Portman

• Joined ING in 1981 • Tiel Utrecht Verzekeringen: Developer/Analyst/Head System Development • Consultancy ING Fatum Paramaribo, Suriname • ING Investment Management Nederland: Head IT • ING Investment Management Europe: PMO Head • ING Insurance Central Europe: Regional PMO head • ING Insurance STO: Global PMO Head • I build hub and spoke PMO’s in Europe and Asia

Now: • PMO Consultant for NN Group • Partner Hedeman Consulting • APMG certified MoP, MSP, PRINCE2, P3O trainer • Blogger • Author of PM articles and books

https://hennyportman.wordpress.com/ https://www.linkedin.com/in/hennyportman

4

Agenda

• PRINCE2 Agile fact sheet

• AgilePM – PRINCE2 Agile

• What is in PRINCE2 Agile

• Frameworks

• Behaviours

• Cynefin model

• Six control aspects

• Agilometer workshop

• End

5

factsheet

• Launch date: June 24th 2015

• Initial launch in English only

• Course 2 – 3 days

• Qualification at Practitioner level only

• Prerequisite is a registered PRINCE2 Practitioner certificate

• Exam is 2½ hours OTE (5 questions 50 marks)

• Manual released on June 16th 2015

• No relation between PRINCE2 Professional and PRINCE2 Agile

6

AgilePM – PRINCE2 Agile

AgilePM

• DSDM

• No pre-requisite

• Foundation + Practitioner

• Separate vocabulary

• No integration with other agile

frameworks

• No behavioural aspects

PRINCE2 Agile

• Axelos

• Registered PRINCE2 Practitioner

• Practitioner level only

• PRINCE2 vocabulary

• Integration with Scrum, Kanban,

Cynefin and Lean Start-up.

• Included behavioural aspects

7

What is in PRINCE2 Agile?

• Agile Behaviours

• Agile Frameworks

• Agile Focus Areas

• Agile Techniques

• Agile Concepts

8

Title Calibri - 42 bold 238 - 127 - 000

Subtitle Calibri - 42 bold 234 - 101 - 013

Second subtitle Calibri - 42 bold 230 - 068 - 021

8

Colours PRINCE2 Agile: Blending of the philosophies, driven by the Agilometer and Cynefin framework

Based on PRINCE2 2009 version

Behaviour

Collaboration Self-organisation Transparency Rich communication Exploration

Scrum

Lean startup

Kanban

Cynefin Framework

9

PRINCE2 is already enabled for agile

PRINCE2 has the name to be waterfall method, but is in origin very agile:

• 1e priority is the added value for the client

• Focus on deliverables and not on activities

• Formal split between management and delivery

• Specify as late as possible

• Priority features (with MoSCoW)

• Frequent review deliverables throughout the project

• Install a change authority

• Implement minor changes informal

• Phased delivery

• Project manager facilitates

• Learn from experience

Scrum by Jeff Sutherland, Ken Schwaber

30 days Sprint

Sprint Planning meeting

24 hours

Daily Scrum (15 minutes)

Sprint Review meeting

Sprint Retrospective

Product

Backlog

Increment

Sprint

Backlog

Sprint Backlog

Sprint Goal To Do Doing Done

I

t

e

m

#

1

I

t

e

m

#

2

I

t

e

m

#

3

I

t

e

m

#

4

I

t

e

m

#

5

T

1

.

1 T

1

.

1

T

1

.

5

T

2

.

7

T

3

.

1

T

2

.

1

<tekst>

11

Colours

Title Calibri - 30 bold 238 - 127 - 000

Subtitle Calibri - 26 bold 234 - 101 - 013

Heading Calibri - 18 bold 238 - 127 - 000

Plain text Calibri - 18 000 - 000 - 000

Highlighted text Calibri - 18 bold 230 - 068 - 021

11

Vision +

decom-

position

Create

Leaps

of faith

Build

quantitative

financial model

Build

MVP

Tuning

the

engine ?

Build Measure Learn

Pivot

Persevere

Pivot: • Zoom-in • Zoom-out • Customer segment • Customer need • Platform • Business architecture • Value capture • Engine of growth • Channel • Technology

Lean startup

Genchi gembutsu Value hypothesis Growth hypothesis

Begin the process of learning, not end it

Establish

the baseline

Accountable metrics: • Actionable • Accessable • Auditable Vanity metrics: • Useless

Cohort analysis

Inovation accounting

(3 learning milestones)

• Concierge • Smoke test • Video • Wizard of Oz testing • Split test • Early prototype When in doubt: simplify

(not necessarily the smallest product imaginable)

Accelerate

BATCH: Small batches versus the large batch death spiral ENGINE of GROWTH: Sticky, viral, paid ADAPT: The wisdom of the five whys. The curse of the five blames INNOVATE: Portfolio thinking Based on THE LEAN STARTUP, by Eric Ries

Henny Portman, July 2015

If you can’t fail, you can’t learn

Kanban by David Anderson

Input Queue

Analysis In Progr Done

Dev Ready

Development In Progr Done

Test Ready

Test Release Ready …

Change Req 60% (=12)

Maintenance 10% (=2)

Prod Defect 30% (=6)

5 4 3 4 2 2 =20 total

Waste bin

13

The 5 Behaviours in PRINCE2 Agile

• Collaboration •Go together •Show respect •Take ownership

• Rich communication •Never write when you can talk

• Exploration •Seek feedback •Fail fast

• Self-organization •Trust the expert •Empower team •But not self-directing

• Transparency •Needs clarity, openness and trust

14

Cynefin A welsh word for a place where a being feels it ought to live. It is where nature around you feels right and welcoming.

15

Cynefin framework

Unknowable unknowns Known knowns

Known unknowns

Complicated

Simple Chaotic

Complex probe – sense - respond

C

E E

E E

E E

C C

C C C

C

C

C

E

E

E

E

E

C E

C

E

C E

sense – analyse - respond

act – sense - respond

sense – categorize - respond

good practice

best practice

Cynefin framework by David Snowden

novel practice

emergent practice Unknown unknowns

16

Cynefin framework

Unknowable unknowns Known knowns

Known unknowns

Complicated

Simple Chaotic

Complex probe – sense - respond

C

E E

E E

E E

C C

C C C

C

C

C

E

E

E

E

E

C E

C

E

C E

sense – analyse - respond

act – sense - respond

sense – categorize - respond

good practice

best practice

Cynefin framework by David Snowden

novel practice

Unknown unknowns

BAU

PRINCE2 Agile

PRINCE2 Agile

???

17

The six control aspects

Time Cost

Scope Quality criteria

Benefits Risk

18

The six control aspects

Time Cost

Scope Quality criteria

Benefits Risk Traditional (waterfall) project

19

The six control aspects

Time Cost

Scope Quality criteria

Benefits Risk PRINCE2 Agile project

22

Title Calibri - 42 bold 238 - 127 - 000

Subtitle Calibri - 42 bold 234 - 101 - 013

Second subtitle Calibri - 42 bold 230 - 068 - 021

22

Colours

PRINCE2

PRINCE2

Agile

PRINCE2 Thinking

cascades down

Project direction

Project management

Product delivery

Agile Thinking rises up ✓

Area of strengh ✓ Blending of the philosophies

✓

✓ Agilometer

Suitability sliders

Flexibility on what is delivered

Level of collaboration

Ease of communication

Ability to work iteratively and deliver incrementally

Advantageous environmental conditions

Acceptance of agile 1 2 3 4 5

1. Flexibility on what is delivered Low High

Definition level 5: Stakeholders are very comfortable with the fact that change is inevitable and needs to happen in order to converge on an accurate product. They are also very comfortable with the role they need to play in prioritization the work, and they understand that the scope of the work and the quality criteria are being flexed in order to protect the level of quality and the deadline for what is being

delivered.

Example behaviours: • Stakeholders are ‘change

friendly’ • It is acceptable that the detail

will change; however, significant changes need to be controlled.

• Everything is prioritized, using techniques such as MoSCoW.

• It is understood by all that flexing what is being delivered will protect deadlines and quality, and specifically that this will prevent quality-checking and testing from being squeezed.

• De-scoping and prioritization will be a team exercise but is customer driven.

• Embracing change at the detail level produces more accurate products.

Definition level 4:

Example behaviours:

Definition level 3:

Example behaviours:

Definition level 2:

Example behaviours:

Definition level 1:

Example behaviours:

2. Level of collaboration Low High

Definition level 5: There is a very high level of collaboration amongst all parties involved. This is typified by a ‘one-team’ culture and excellent working relationships both internally and externally. High levels of trust exist and a desire to be helpful is prevalent.

Example behaviours: • There is a ‘one-team’ culture. • There is a partnership approach.

between the customer and the supplier.

• There is an absence of ‘silos’ and ‘turf’.

• There is an absence of ‘baggage’ associated with events from the past.

• Trust and listening epitomize the behaviour of the people involved.

• People work quickly, are helpful and look out for each other.

• There is an absence of a blame and ‘cc: email’ culture.

• There is an acceptance that mistakes will happen due to some communications being informal.

Definition level 4:

Example behaviours:

Definition level 3:

Example behaviours:

Definition level 2:

Example behaviours:

Definition level 1:

Example behaviours:

3. Ease of communication Low High

Definition level 5: Communication is very easy amongst all parties involved. The environment is ‘communication rich’ where there is a lot of face-to-face interaction, and visual information is readily available in such forms as prototypes and models. Retrieval of information is also easy in order to reference knowledge, information or data that is either historical or current.

Example behaviours: • There are high levels of visibility

and transparency (e.g. plans on walls).

• A lot of information is managed in a ‘low-tech’ and/or tactile way.

• There are high levels of co-location.

• Where there is a less than ideal situation (e.g. the term is physically dispersed), measures have been taken to reduce the impact (e.g. video-conferencing).

• There is a lot of informal communication, face-to-face and over the phone.

• There is a limited amount of formal reporting.

Definition level 4:

Example behaviours:

Definition level 3:

Example behaviours:

Definition level 2:

Example behaviours:

Definition level 1:

Example behaviours:

4. Ability to work iteratively and deliver incrementally Low High

Definition level 5: It is very easy to deliver benefit to the customer by regular partial deliveries of the final product. It is also very easy to work iteratively in the sense that products and understanding can be refined interactively by frequent delivery of formal and informal deliverables. There is a desire to learn, experiment and explore (and fail!) as well as an overarching feeling of ‘think big; start small’.

Example behaviours: • The team is happy to

experiment and be creative. • It is understood that things are

rarely right first time. • The project can be broken down

into chunks that can deliver benefits early.

• Learning and validation are seen as an on-going process.

• ‘Little and often’ is seen as a safe way of delivering and a good way of staying in control.

• Incrementalism is seen as good for ‘real’ feedback and gives confidence to the customer as they see things being delivered.

Definition level 4:

Example behaviours:

Definition level 3:

Example behaviours:

Definition level 2:

Example behaviours:

Definition level 1:

Example behaviours:

5. Advantageous environmental conditions Low High

Definition level 5: The overall working environment is very supportive of working in an agile way. Personnel are assigned full-time to their work; they are appropriately skilled; they have very efficient platforms to work from (e.g. tooling, communications). Contractual frameworks and compliance considerations are not seen as restrictive.

Example behaviours: • People are dedicated to the

project and the team is stable. • Team personnel are

experienced in their trades. • Any third parties are

comfortable with working in an agile way.

• Commercial and contractual details do not inhibit the agile way of working and delivering.

• The environment and tooling are conducive to agile.

Definition level 4:

Example behaviours:

Definition level 3:

Example behaviours:

Definition level 2:

Example behaviours:

Definition level 1:

Example behaviours:

6. Acceptance of agile Low High

Definition level 5: All stakeholders closely involved are fully aware of the behaviours, concepts and techniques of working in an agile way. They have been trained and have experience. They are not only happy to work in this way but they prefer it and understand the advantages that it brings. Peripheral stakeholders are also aware of the need to carry out their roles in an ‘agile friendly’ way.

Example behaviours: • Everyone accepts the agile

philosophy and understands the difference from a traditional way of working.

• People have been trained to an appropriate level.

• There are no blockers to using agile from peripheral areas such as procurement or quality assurance (i.e. they understand the philosophy too).

Definition level 4:

Example behaviours:

Definition level 3:

Example behaviours:

Definition level 2:

Example behaviours:

Definition level 1:

Example behaviours:

29

Workshop Agilometer

A

1 6 2

B

C

30

Results on my blog

Feedback to the group 15

Acceptance of agile

… Flexibility on

what is delivered

Level of collaboration

30

Henny Portman

Mail: h.portman@hedemanconsulting.com

Mobile: +31(0)6 21512 987

Blog: https://hennyportman.wordpress.com/

LinkedIn: https://www.linkedin.com/in/hennyportman

Hedeman Consulting B.V.

Mozartlaan 25D

1217 CM Hilversum

035 628 48 19

www.hedemanconsulting.com