Vice-President of OMEC Lead Trainer in PRINCE2, MSP, P3O and … · 2014-06-04 · To agile or not to agile? © OMEC Sp. z o.o. 1 TO AGILE OR NOT TO AGILE? THAT IS THE QUESTION PRINCE2®,

To agile or not to agile? © OMEC Sp. z o.o. 1

TO AGILE OR NOT TO AGILE?

THAT IS THE QUESTION

PRINCE2®, MSP®, P3O®, MoP®, P3M3®, M_o_R®, ITIL®, MoV® are registered trade marks of AXELOS Limited The Swirl logo™ is a trade mark of AXELOS Limited

DSDM and Atern are Registered Trade Marks of Dynamic Systems Development Method Limited in the United Kingdom and other countries. The OMEC logo is a trade mark of OMEC Sp. z o.o.

Krzysztof Małus Vice-President of OMEC

Lead Trainer in PRINCE2, MSP, P3O and AgilePM

Sofia, June 05th, 2014


Common "wisdoms" about agile methods

"Mobile Supplier" - the fairy tale of a project

Agile in the organization governance

The genesis of Agile approaches

AgilePM review

Will agile save us?

AgilePM sample Foundation exam questions

In that session


COMMON "WISDOMS" ABOUT

AGILE METHODS


Agile methods

are used to manage projects ("we use Scrum to manage the

project").

are for IT projects only.

are easy to use, no special deployment is needed.

are not bureaucratic as PRINCE2.

make conflicts to traditional approaches as PRINCE2. So either

agile or PRINCE2.

are self-reliant so no another method is needed (neither to learn

nor embed).


Agile - the feeling of chaos

My agile guide

says we should

do it like this.

Your agile guide

must be wrong.

My agile guide

says we should

do it like that.

Is there any

chance to

deliver?


To agile or not to agile?

To agile or not to agile

That is a question. Whether ‘tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? Press Yes if you want to agile Press No if you do not want to agile


MOBILE SUPPLIER – THE FAIRY

TALE OF THE PROJECT


Background and reasons of fairy tale

project (1) Multiland – a kingdom in a blooming period, a very wise king, happy

citizens.

Many balls, ceremonies, royal feasts and banquets, increased

number of events and quests (everyone dreams to join).

Syndromes of insufficiency of food and drinks during royal

banquets.

The quests are getting disappointed, KPI (Key Performance

Indicators) of the kingdom are falling down.

The king wants to know the reasons, very expensive consulting

company performs the analysis (6 months of a hard work).


Background and reasons of fairy tale

project (2) VVECC (Very Very Expensive Consulting Company)

prepared a volume of analysis: "food providers are guilty

because they can’t manage to serve all the events in the

palace".

Ministry of Supply: "Our suppliers use just hand barrows so

they cannot bring much food in the narrow streets of the

kingdom".

A project idea: Mobile Supplier (agile vehicles) will resolve the

supplying projects!!!


Agile in Multiland

Great enthusiasm for the project.

How should we deliver a project? Of course by agile.

The news about the power of agile came to Multiland in the

songs of bards coming from the world.

Likely better than PRINCE2 and no effort is needed.

The king is expecting the results - so the work has been

started. Of course with the agile approach.


Uncontrolled start

No clear project organization.

No project brief.

The consultants of external company

are working in the palace but there is

no Project Initiation Documentation.

Some voices about the need to apply

the methods are just ignored.

Agile approach is supposedly self-

acting if everyone want it.


Uncontrolled delivery

Daily stand-ups meeting without the business.

No plans, reports, documentation…

But we do not need the above controls. Everybody

knows what to do, waste the time to plan… After all

this is unfailing Agile.


Uncontrolled closure

External supplier delivers the product, gets

the money and disappears.

We have scooters instead of vehicles.

Everybody is surprised.

The scooters squeaks and the wheels fall

off.

The kingdom indicators are falling down.


Who is guilty?

Suppliers or technicians?

Business? Ministers?

Maybe agile is useless?

Maybe we should have taken a chance

on PRINCE2?

Maybe coaching?

Maybe we should have bought any

planning tool?

But:

• no project documentation available

• PM and the Project Board say they

were not in their roles

• Seems no one managed the team

• There have been no collaboration, daily

stand-ups of the technicians and the

business.

The king is guilty!!!


AGILE IN THE ORGANIZATIONAL

GOVERNANCE


Strategy

Business

change

Portfolio

Programme Programme

Project Project Project Project Project

Business as

usual

Business Plan

Activities

Team 3 Team

Product

Delivery

Organizational Change Management

P3 governance in the

corporate environment

Project

P3O®

P3O®

P3O®

Strategic imperatives

Corporate vision and goals

External factors

Team 1 Team 2


Corporate governance layers

PORTFOLIO

PROGRAMME

PROJECT

TEAM

PRODUCT

DELIVERY

MoP

MSP

PRINCE2

SCRUM

AGILEPM

XP

DSDM

(ATERN)


THE GENESIS OF AGILE

APPROACHES


Waterfall - the traditional approach

Requirements

Design

Implementation

Verification

Maintenance


Problems in waterfall projects

Late delivery of products

Delayed or late ROI

The delivered solution isn’t really what the business wanted

Business constantly changes his mind

Unused features

Communication problems (team work)


Teamwork problems

PROJECT

Team 1 Team 2

Technical

team

Business/users


The team - co-operation with the customer

http://www.sealswcc.com


Agile contribution to the matrix organization

(1)

Main Board

Line 2 Line 3 Line 1 Portfolio

Board

Programme

Board

Project

Board

Team


Portfolio Board

Design Authority

Portfolio Director

Portfolio Office

Senior Executives [e.g. Programme

SROs and Corporate Functions]

Senior Responsible

Owner [e.g. CEO or

Divisional head]

Strategy Operations

Project Manager

Team Manager

Team members

Expert R

eference

Gro

up

Stakeho

lders

Senior Supplier

Project Board

Executive Senior User

Programme Board

Business Executives

Senior Responsible

Owner

Programme Manager

Business Change

Manager/s

IT and Financial Advisors

Programme Office

Project Office

Portfolio

Project

Programme

Business operations

Direct reporting line

Indirect reporting line

Agile contribution to the matrix organization (2)

©Crown Copyright 2008. All rights reserved. Material is reproduced under licence from AXELOS.

Team Manager

Team members

AGILE


Is the traditional approach always work?

Plan Project reality

©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.

Material is reproduced under licence from DSDM Consortium.


Basics - What is negotiable?



Agile approach Traditional approach


Waterfall and Agile - effects

Source: The CHAOS Manifesto – Standish Group 2011


What is Agile?

Generic Description of a style of working:

• Flexibility

• Working closely with customer throughout

• Ensuring final solution actually meets business need

• Deferring decisions about detail as late as possible

A L G I E


What is Agile?

DSDM Atern

Agile Unified Process (AUP)

Fuller Approaches

(but still agile) Lightweight Approaches

Scrum

Lean

Extreme Programming (XP)

A L G I E




What is Agile?

People and Interactions Over Processes and Tools

Working Software Over Comprehensive Documentation

Customer Collaboration Over Contract Negotiation

Responding to Change Over Following a Plan

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

That is; while there is value in the items on the right; we value the items on the left more.

(But Agile is not just about delivering software, it applies to all types of project)


AGILEPM REVIEW


AgilePM in a nutshell




AgilePM -the philosophy

Projects aligned to clearly defined

strategic goals.

Focus on early delivery of real benefits to

the business.

To be successful requires:

• Key stakeholder understanding of business

objectives

• Empowerment to the appropriate level

• Collaboration to deliver the right solution

• On time delivery, according to business

priorities

• Stakeholders willing to deliver a fit-for-purpose

solution

• Acceptance that change is inevitable. ©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.



AgilePM - the principles

1. Focus on the business need

2. Deliver on time 3. Collaborate 4. Never compromise

quality

5. Build incrementally from firm foundations

6. Develop iteratively 7. Communicate

continuously and clearly

8. Demonstrate control




1: Focus on the business need

Clearly define the scope of the solution

Understand the true business priorities

Establish a sound Business Case

Seek continuous business sponsorship and

commitment

Guarantee the Minimum Usable Subset of

features (MoSCoW prioritisation)

Every decision taken during a project should be

viewed in the light of the overriding project goal,

which is to deliver what the business needs it to

deliver, when it needs it to be delivered.


2: Deliver on time

Timebox the work

Focus on business priorities

Always meet deadlines

Delivering products on time is a very desirable outcome for

a project and is quite often the single most important

success factor. Late delivery can undermine the very

rationale for a project.


3: Collaborate

Involve the right stakeholders, at the right time, throughout

the project

Ensure that the members of the team are empowered to take

decisions on behalf of those they represent without waiting

for higher-level approval

Actively involve the business representatives

Build one-team culture

Team that work in a spirit of active cooperation and

commitment will always outperform groups of individuals

working in loose association.


4: Never compromise quality

Set the level of quality at the outset

Ensure that quality does not become a variable

Design, document and test appropriately

Build in quality by constant review

Test early and continuously

The level of quality to be delivered should be

agreed at the start. All work should be aimed at

achieving that level of quality. No more and no

less. A solution has to be 'good enough'.


5: Build incrementally from firm foundations

Strive for early delivery of business benefit where possible

Continually confirm the correct solution is being built

Formally re-assess priorities and ongoing project viability with

each delivered increment

In order to deliver real benefit early, Atern advocates

incremental delivery.


6: Develop iteratively

Do enough design up front to create strong foundations

Take an iterative approach to building all products

Build customer feedback into each iteration to converge on an effective

business solution

Accept that most detail emerges later rather than sooner

Embrace change – the right solution will not evolve without it

Be creative, experiment, learn, evolve

In order to converge on an accurate business solution

Atern uses iterative development to deliver the right

solution.


7: Communicate continuously and clearly

Run daily team stand-up sessions

Use facilitated workshops

Use rich communication techniques such as modelling and

prototyping

Present iterations of the evolving solution early and often

Keep documentation lean and timely

Manage stakeholder expectations throughout the project

Encourage informal, face to face communication at all

levels

Poor communication is often cited as the biggest single

cause of project failure.


8: Demonstrate control

Use an appropriate level of formality for tracking and

reporting

Make plans and progress visible to all

Measure progress through focus on delivery of products

rather than completed activities

Manage proactively

Evaluate continuing project viability based on the business

objectives

It is essential to be in control of a project at all times.


AgilePM - the people




AgilePM - the process




AgilePM - the products



Project Review Record

Timebox Plan

Deployment Plan

Delivery Plan

Delivery Control Pack

Timebox Review Record

Management Foundations

Outline Plan

Terms of Reference

Feasibility Assessment

Business Foundations

Prioritised Requirements List

Benefits Assessment

Solution Foundations

Evolving Solution

Solution Assurance Pack

Deployed Solution

Pre-Project Feasibility Foundations Exploration & Engineering Deployment Post-Project


AgilePM - the core practices (1)

Timeboxing - used to support the main goals of DSDM to realize

the development on time, within budget and with the desired

quality. Because time and budget are fixed, the only remaining

variables are the requirements.





MoSCoW prioritisation

• MUST

• SHOULD

• COULD

• WON'T

Prototyping - creation of prototypes of the system

under development at an early stage of the project. It

enables the early discovery of shortcomings in the

system and allows future users to ‘test-drive’ the

system. ©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.




Testing - through each iteration (not just only at the

end)

Facilitated workshop





Modelling - to visualise the diagrammatic

representation of a specific aspect of the system or

business area that is being developed

Configuration Management - to control products





Daily Stand-up - on a daily basis, the team working in

a timebox get together to understand progress,

expose and possibly resolve issues.




Prerequisites for using AgilePM

Acceptance of the Atern philosophy before starting work

Appropriate empowerment of the Solution Development Team

Commitment of senior business management to provide the

necessary Business Ambassador (and Business Advisor)

involvement

Incremental delivery

Access by the Solution Development Team to business roles

Solution Development Team stability

Solution Development Team skills

Solution Development Team size

A supportive commercial relationship

http://www.google.pl/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&docid=9OytphrUMexzcM&tbnid=_FogXKoyCcp-_M:&ved=0CAUQjRw&url=http://www.designdistrictauction.com/applying-agile-design-patterns-and-principles/&ei=q06CU9SDG8HoOvXlgfAJ&bvm=bv.67720277,d.ZGU&psig=AFQjCNHUoJp2HPepdDJYolF225FlFJcSEA&ust=1401133516409721


Critical Success Factors of Atern 1. The acceptance of DSDM by senior management and other employees.

This ensures that the different actors of the project are motivated from the

start and remain involved throughout the project

2. The commitment of management to ensure end-user involvement.

The prototyping approach requires a strong and dedicated involvement

by end user to test and judge the functional prototypes

3. The team has to be composed of skilful members that form a stable

empowered union. The team has to possess the power and possibility to

make important decisions without having to escalate. The team needs

the right technology to conduct the project (development environment,

project management tools, etc.)

4. Supportive relationship between customer and vendor is required.

This goes for both projects that are delivered internally within companies

or by outside contractors


WILL AGILE SAVE US?


WILL NOT HELP

Not mature organizations without governance at the

remaining layers

Without being embedded and ownership given

In portfolio management

In project management

In project management (except of AgilePM for small

projects)


WILL HELP

To build team level governance

To build climate of cooperation and not rivalry

To understand that changes must happen during the

project time and we must handle them for business

benefits

To achieve the right solution by applying techniques such

as modelling and prototyping

To manage projects (some approaches as AgilePM)


AGILEPM SAMPLE FOUNDATION

EXAM QUESTIONS


Sample Foundation questions

1. What role should be perceived as the owner of the Business

Case in AgilePM?

a) Project Manager

b) Business Ambassador

c) Business Visionary

d) Business Sponsor

D



2. What does AgilePM state about tailoring?

a) No tailoring is needed

b) AgilePM fits all projects without tailoring

c) AgilePM should be tailored to suit a project's individual

needs withing the organizations' governance needs

d) AgilePM should be tailored to suit Business Sponsor's

individual needs

C



3. What is AgilePM composed of?

a) Philosophy, Principles, Practices, Products, People,

Process

b) Process, Organization, Techniques, Information

c) Philosophy, Principles, Themes, Process

d) Philosophy, Information, Practices, People, Process

A



4. Which of these questions does AgilePM recommend asking

when reviewing the project?

a) Are the business roles each taken by different persons?

b) Is the Business Ambassador allocated full time to the

team?

c) Are there at least two Business Advisors?

d) Is there sufficient business involvement to support the

approach?

D



5. What action should be taken when a "Could have"

requirements cannot be completed in a timebox?

a) Automatically move it to the next timebox

b) The Project Manager is empowered to drop the

requirement

c) The Solution Development Team is empowered to drop

the requirement from the timebox

d) Extend the timebox

C



6. AgilePM states that in a complex environment…

a) agile rules must always take precedence over corporate

constraints

b) agile rules must always defer to corporate constraints

c) agile rules are important but corporate constraints must

also be acknowledged

d) agile is not possible

C



7. AgilePM states…

a) The estimates become fully accurate as the requirements

become more detailed

b) The estimates become more accurate as the

requirements become more detailed

c) The estimates become less accurate as the requirements

become more detailed

d) The estimates become accurate at the end of the

increment

A



8. Which of the following is acceptable to vary in the in AgilePM

project?

a) Time

b) Cost

c) Quality

d) None of the above

D



9. What makes AgilePM inadvisable to apply?

a) The business changing their mind during project delivery

b) Project communication problems

c) PRINCE2 widely embedded in the organization

d) No empowerment of the Solution Development Team

D



10.Which role does not belong to the Solution Development

Team?

a) Team Leader

b) Project Manager

c) Business Ambassador

d) Solution Tester

B



11.Which is not AgilePM technique?

a) Quality review

b) Facilitated workshop

c) Modelling

d) Daily standup meeting

A



12.Which of the above is not AgilePM principle?

a) Focus on the business need

b) Govern effectively

c) Never compromise quality

d) Demonstrate control

B



13. In AgilePM, testing takes place…

a) at the end of the project lifecycle

b) at the end of each timebox

c) throughout the project lifecycle

d) at the end of each increment

C



14.What describes the nature of AgilePM project?

a) Enabling constant change while maintaining the aim of the

project on target

b) Preventing drift from the specification once agreed and

approved as the time is of the essence and fixed

c) Avoiding documentation as this is time consuming

d) Avoiding reporting as this is unnecessary in agile

environment

A



15.What is the expected sequence of phases in AgilePM

lifecycle?

a) Feasibility, Pre-Project, Foundations, Exploration

b) Pre-Project, Feasibility, Foundations, Exploration

c) Pre-Project, Foundations, Feasibility, Exploration

d) Exploration, Pre-Project, Feasibility, Foundations

B



16.Which of the following statement is true?

a) AgilePM can be used to complement other project

management disciplines

b) AgilePM can be used only in the projects with one team

c) AgilePM is limited to IT projects only

d) AgilePM removes the need of project management

A

Documents

Vice-President of OMEC Lead Trainer in PRINCE2, MSP, P3O and … · 2014-06-04 · To agile or not to agile? © OMEC Sp. z o.o. 1 TO AGILE OR NOT TO AGILE? THAT IS THE QUESTION PRINCE2®,