To Agile or Not To Agile: Analyzing an Agile Project Failure

Krzysztof Małus
Vice-President of OMEC
Lead Trainer in PRINCE2, MSP, P3O and AgilePM
TO AGILE OR NOT TO AGILE?
THAT IS THE QUESTION
(FOR PROJECT MANAGERS)
Vilnius, October 09th, 2014
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.
To agile or not to agile? © OMEC Sp. z o.o. 1

In that session
 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

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 wants 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
Change the
Business
Portfolio
Strategic imperatives
Corporate vision and goals
External factors
P3 governance
Programme Programme
Project Project Project Project Project
Run the
Business
Team
Organizational Change Management
Project
P3O®
P3O®
P3O®
Product
Delivery
Team 1 Team 2 Team 3

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 1 Line 2 Line 3
Portfolio
Board
Programme
Board
Project
Board
Team

Agile contribution to the matrix organization (2)
Portfolio Board
Senior Executives
[e.g. Programme
Portfolio
Director
SROs and
Corporate
Functions]
Design
Authority
Portfolio
Office
Senior
Responsible
Owner
[e.g. CEO or
Divisional head]
Strategy Operations
Programme Board
Senior
Responsible
Owner
IT and
Financial
Advisors
Business
Change
Manager/s
Project Board
Executive Senior User
Project
Manager
Team
Manager
Team
members
Expert Reference Group
Stakeholders
Business
Executives
Programme
Manager
Senior
Supplier
Programme
Office
Project
Office
Portfolio
Project
Programme
Business
operations
Direct reporting line
Indirect reporting line
Team
Manager
Team
members
To agile or not to agile? ©Crown Copyright 2008. All rights reserved. Material is reproduced under licence from AXELOS.
© OMEC Sp. z o.o. 24
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?
Traditional approach Agile approach

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
AG I L E

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.

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

2: Deliver on time
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.
 Timebox the work
 Focus on business priorities
 Always meet deadlines

3: Collaborate
Team that work in a spirit of active cooperation and
commitment will always outperform groups of individuals
working in loose association.
 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

4: Never compromise quality
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'.
 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

5: Build incrementally from firm foundations
In order to deliver real benefit early, Atern advocates
incremental delivery.
 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

6: Develop iteratively
In order to converge on an accurate business solution
Atern uses iterative development to deliver the right
solution.
 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

7: Communicate continuously and clearly
Poor communication is often cited as the biggest single
cause of project failure.
 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

8: Demonstrate control
It is essential to be in control of a project at all times.
 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

AgilePM - the people

AgilePM - the process

AgilePM - the products
Pre-Project Feasibility Foundations Exploration & Engineering Deployment Post-Project
Project
Review
Record
Delivery Control Pack
Deployment Plan
Delivery Plan
Timebox Plan
Timebox
Review Record
Management
Foundations
Solution Assurance Pack
Outline
Plan
Terms of
Reference
Feasibility
Assessment
Business
Foundations
Prioritised Requirements List
Benefits
Assessment
Solution
Foundations
Evolving Solution
Deployed
Solution

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.

 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

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

SUCCESSFUL AGILE

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

Agile resolution
 Agile Project Manager is coming to help.
Will you help me?
Keep calm. I am a
Project Manager.

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

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.

Agile team integration
 All in the army.
 One team culture.

Agile team in the project

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)

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

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 within the organizations' governance needs
d) AgilePM should be tailored to suit Business Sponsor's
individual needs
C

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

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

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

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

7. Which role does not belong to the Solution Development
Team?
a) Team Leader
b) Project Manager
c) Business Ambassador
d) Solution Tester
B

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

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

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

To Agile or Not To Agile: Analyzing an Agile Project Failure

Recomendados

Recomendados

Más contenido relacionado

Similar a To Agile or Not To Agile: Analyzing an Agile Project Failure

Similar a To Agile or Not To Agile: Analyzing an Agile Project Failure (20)

Más de Agile Lietuva

Más de Agile Lietuva (20)

Último

Último (20)

To Agile or Not To Agile: Analyzing an Agile Project Failure