krzysztof malus. to agile or not to agile

71
To agile or not to agile? © OMEC Sp. z o.o. 1 TO AGILE OR NOT TO AGILE? THAT IS THE QUESTION (FOR PROJECT MANAGERS) 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 Vilnius, October 09 th , 2014

Upload: agile-lietuva

Post on 02-Jul-2015

378 views

Category:

Software


2 download

DESCRIPTION

There are huge expectations from Agile approaches. Agile is expected to resolve all the problems we face when using traditional project methods. What is more, it is described as a very easy to use, almost without any effort to embed it in an organization. We simply reject the traditional "waterfall" approach to project management and introduce Agile. Some people promise that you don’t need anything more if you start using Agile. The speaker will highlight all myths and facts about Agile and guide the audience through organizational governance of business change with the portfolio, programme, team and delivery management. Agile is a part of organization governance and there is a room for both Agile and traditional project management. There is no conflict between traditional and Agile approaches - they do support each other! The principles of AgilePM will be shortly presented together with good and bad examples of applying Agile to the projects.

TRANSCRIPT

Page 1: Krzysztof Malus. To agile or not to agile

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

TO AGILE OR NOT TO AGILE?

THAT IS THE QUESTION(FOR PROJECT MANAGERS)

PRINCE2®, MSP®, P3O®, MoP®, P3M3®, M_o_R®, ITIL®, MoV® are registered trade marks of AXELOS LimitedThe 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łusVice-President of OMEC

Lead Trainer in PRINCE2, MSP, P3O and AgilePM

Vilnius, October 09th, 2014

Page 2: Krzysztof Malus. To agile or not to agile

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

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

The story of the success with the Agile

Will Agile save us?

AgilePM sample Foundation exam questions

In that session

Page 3: Krzysztof Malus. To agile or not to agile

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

COMMON "WISDOMS" ABOUT

AGILE METHODS

Page 4: Krzysztof Malus. To agile or not to agile

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

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).

Page 5: Krzysztof Malus. To agile or not to agile

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

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?

Page 6: Krzysztof Malus. To agile or not to agile

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

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

Page 7: Krzysztof Malus. To agile or not to agile

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

MOBILE SUPPLIER – THE FAIRY

TALE OF THE PROJECT

Page 8: Krzysztof Malus. To agile or not to agile

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

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).

Page 9: Krzysztof Malus. To agile or not to agile

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

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!!!

Page 10: Krzysztof Malus. To agile or not to agile

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

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.

Page 11: Krzysztof Malus. To agile or not to agile

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

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 wants it.

Page 12: Krzysztof Malus. To agile or not to agile

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

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.

Page 13: Krzysztof Malus. To agile or not to agile

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

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.

Page 14: Krzysztof Malus. To agile or not to agile

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

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!!!

Page 15: Krzysztof Malus. To agile or not to agile

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

AGILE IN THE ORGANIZATIONAL

GOVERNANCE

Page 16: Krzysztof Malus. To agile or not to agile

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

Strategy

Change the

Business

Portfolio

Programme Programme

Project Project Project Project Project

Run the

Business

Team

Organizational Change Management

P3 governance

Project

P3O®

P3O®

P3O®

Strategic imperatives

Corporate vision and goals

External factors

Product

Delivery

Team 3Team 1 Team 2

Page 17: Krzysztof Malus. To agile or not to agile

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

Corporate governance layers

PORTFOLIO

PROGRAMME

PROJECT

TEAM

PRODUCT

DELIVERY

MoP

MSP

PRINCE2

SCRUM

AGILEPM

XP

DSDM

(ATERN)

Page 18: Krzysztof Malus. To agile or not to agile

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

THE GENESIS OF AGILE

APPROACHES

Page 19: Krzysztof Malus. To agile or not to agile

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

Waterfall - the traditional approach

Requirements

Design

Implementation

Verification

Maintenance

Page 20: Krzysztof Malus. To agile or not to agile

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

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)

Page 21: Krzysztof Malus. To agile or not to agile

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

Teamwork problems

PROJECT

Team 1 Team 2

Technical

team

Business/users

Page 22: Krzysztof Malus. To agile or not to agile

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

The team - co-operation with the customer

http://www.sealswcc.com

Page 23: Krzysztof Malus. To agile or not to agile

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

Agile contribution to the matrix organization

(1)

Main Board

Line 2 Line 3Line 1Portfolio

Board

Programme

Board

Project

Board

Team

Page 24: Krzysztof Malus. To agile or not to agile

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

Portfolio Board

Design Authority

Portfolio Director

Portfolio Office

Senior Executives[e.g. Programme

SROs andCorporate 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

Page 25: Krzysztof Malus. To agile or not to agile

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

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.

Page 26: Krzysztof Malus. To agile or not to agile

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

Basics - What is negotiable?

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

Material is reproduced under licence from DSDM Consortium.

Agile approachTraditional approach

Page 27: Krzysztof Malus. To agile or not to agile

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

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 LG I E

Page 28: Krzysztof Malus. To agile or not to agile

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

AGILEPM REVIEW

Page 29: Krzysztof Malus. To agile or not to agile

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

AgilePM in a nutshell

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

Material is reproduced under licence from DSDM Consortium.

Page 30: Krzysztof Malus. To agile or not to agile

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

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.

Material is reproduced under licence from DSDM Consortium.

Page 31: Krzysztof Malus. To agile or not to agile

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

AgilePM - the principles

1. Focus on the business need

2. Deliver on time3. Collaborate4. Never compromise

quality

5. Build incrementally from firm foundations

6. Develop iteratively7. Communicate

continuously and clearly

8. Demonstrate control

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

Material is reproduced under licence from DSDM Consortium.

Page 32: Krzysztof Malus. To agile or not to agile

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

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.

Page 33: Krzysztof Malus. To agile or not to agile

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

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.

Page 34: Krzysztof Malus. To agile or not to agile

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

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.

Page 35: Krzysztof Malus. To agile or not to agile

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

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'.

Page 36: Krzysztof Malus. To agile or not to agile

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

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.

Page 37: Krzysztof Malus. To agile or not to agile

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

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.

Page 38: Krzysztof Malus. To agile or not to agile

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

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.

Page 39: Krzysztof Malus. To agile or not to agile

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

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.

Page 40: Krzysztof Malus. To agile or not to agile

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

AgilePM - the people

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

Material is reproduced under licence from DSDM Consortium.

Page 41: Krzysztof Malus. To agile or not to agile

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

AgilePM - the process

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

Material is reproduced under licence from DSDM Consortium.

Page 42: Krzysztof Malus. To agile or not to agile

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

AgilePM - the products

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

Material is reproduced under licence from DSDM Consortium.

ProjectReviewRecord

Timebox Plan

Deployment Plan

Delivery Plan

Delivery Control Pack

TimeboxReview Record

ManagementFoundations

OutlinePlan

Terms ofReference

FeasibilityAssessment

BusinessFoundations

Prioritised Requirements List

BenefitsAssessment

Solution Foundations

Evolving Solution

Solution Assurance Pack

DeployedSolution

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

Page 43: Krzysztof Malus. To agile or not to agile

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

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.

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

Material is reproduced under licence from DSDM Consortium.

Page 44: Krzysztof Malus. To agile or not to agile

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

AgilePM - the core practices (2)

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.

Material is reproduced under licence from DSDM Consortium.

Page 45: Krzysztof Malus. To agile or not to agile

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

AgilePM - the core practices (3)

Testing - through each iteration (not just only at the

end)

Facilitated workshop

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

Material is reproduced under licence from DSDM Consortium.

Page 46: Krzysztof Malus. To agile or not to agile

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

AgilePM - the core practices (4)

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

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

Material is reproduced under licence from DSDM Consortium.

Page 47: Krzysztof Malus. To agile or not to agile

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

AgilePM - the core practices (5)

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

a timebox get together to understand progress,

expose and possibly resolve issues.

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

Material is reproduced under licence from DSDM Consortium.

Page 48: Krzysztof Malus. To agile or not to agile

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

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

Page 49: Krzysztof Malus. To agile or not to agile

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

Critical Success Factors of Atern1. 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

Page 50: Krzysztof Malus. To agile or not to agile

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

SUCCESSFUL AGILE

Page 51: Krzysztof Malus. To agile or not to agile

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

Background

A bank: problems with projects, no project delivers

on time, no project delivers initial scope.

Business dissatisfaction.

CEO needs a success.

Do I need to employ VVECC (Very Very Expensive

Consulting Company)?

Page 52: Krzysztof Malus. To agile or not to agile

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

Agile resolution

Agile Project Manager is coming to help.

Will you help me?

Keep calm. I am a

Project Manager.

Page 53: Krzysztof Malus. To agile or not to agile

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

Agile diagnosis

Business and technical person do not collaborate.

In the projects there is a wall between them.

They are perfect in blaming: "It not our fault".

Page 54: Krzysztof Malus. To agile or not to agile

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

Agile Project Manager proposal

There will be one integrated team of business and

technical persons.

My team must be empowered to decide.

I need some founds for the initial integration.

There must be reword for the team for a success.

Page 55: Krzysztof Malus. To agile or not to agile

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

Agile team integration

All in the army.

One team culture.

Page 56: Krzysztof Malus. To agile or not to agile

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

Agile team in the project

Page 57: Krzysztof Malus. To agile or not to agile

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

WILL AGILE SAVE US?

Page 58: Krzysztof Malus. To agile or not to agile

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

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)

Page 59: Krzysztof Malus. To agile or not to agile

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

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)

Page 60: Krzysztof Malus. To agile or not to agile

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

AgilePM training

The nearest AgilePM Foundation

training is scheduled for:

December 8th-10th

in Vilnius

• The AgilePM Foundation certification

is planned

at the end of the training course.

Page 61: Krzysztof Malus. To agile or not to agile

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

AGILEPM SAMPLE FOUNDATION

EXAM QUESTIONS

Page 62: Krzysztof Malus. To agile or not to agile

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

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

Page 63: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

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 within the organizations' governance needs

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

individual needs

C

Page 64: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

3. 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

Page 65: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

4. 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

Page 66: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

5. 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

Page 67: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

6. 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

Page 68: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

7. Which role does not belong to the Solution Development

Team?

a) Team Leader

b) Project Manager

c) Business Ambassador

d) Solution Tester

B

Page 69: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

8. 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

Page 70: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

9. 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

Page 71: Krzysztof Malus. To agile or not to agile

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

Sample Foundation questions

10.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