Vice-President of OMEC Lead Trainer in PRINCE2, MSP, P3O ... · PRINCE2®, MSP®, P3O®, MoP®,...
Transcript of Vice-President of OMEC Lead Trainer in PRINCE2, MSP, P3O ... · PRINCE2®, MSP®, P3O®, MoP®,...
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
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
Will agile save us?
AgilePM sample Foundation exam questions
In that session
To agile or not to agile? © OMEC Sp. z o.o. 3
COMMON "WISDOMS" ABOUT
AGILE METHODS
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).
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?
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
To agile or not to agile? © OMEC Sp. z o.o. 7
MOBILE SUPPLIER – THE FAIRY
TALE OF THE PROJECT
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).
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!!!
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.
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 want it.
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.
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.
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!!!
To agile or not to agile? © OMEC Sp. z o.o. 15
AGILE IN THE ORGANIZATIONAL
GOVERNANCE
To agile or not to agile? © OMEC Sp. z o.o. 16
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
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)
To agile or not to agile? © OMEC Sp. z o.o. 18
THE GENESIS OF AGILE
APPROACHES
To agile or not to agile? © OMEC Sp. z o.o. 19
Waterfall - the traditional approach
Requirements
Design
Implementation
Verification
Maintenance
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)
To agile or not to agile? © OMEC Sp. z o.o. 21
Teamwork problems
PROJECT
Team 1 Team 2
Technical
team
Business/users
To agile or not to agile? © OMEC Sp. z o.o. 22
The team - co-operation with the customer
http://www.sealswcc.com
To agile or not to agile? © OMEC Sp. z o.o. 23
Agile contribution to the matrix organization
(1)
Main Board
Line 2 Line 3 Line 1 Portfolio
Board
Programme
Board
Project
Board
Team
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 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
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.
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 approach Traditional approach
To agile or not to agile? © OMEC Sp. z o.o. 27
Waterfall and Agile - effects
Source: The CHAOS Manifesto – Standish Group 2011
To agile or not to agile? © OMEC Sp. z o.o. 28
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
To agile or not to agile? © OMEC Sp. z o.o. 29
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
©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.
Material is reproduced under licence from DSDM Consortium.
To agile or not to agile? © OMEC Sp. z o.o. 30
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)
To agile or not to agile? © OMEC Sp. z o.o. 31
AGILEPM REVIEW
To agile or not to agile? © OMEC Sp. z o.o. 32
AgilePM in a nutshell
©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.
Material is reproduced under licence from DSDM Consortium.
To agile or not to agile? © OMEC Sp. z o.o. 33
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.
To agile or not to agile? © OMEC Sp. z o.o. 34
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
©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.
Material is reproduced under licence from DSDM Consortium.
To agile or not to agile? © OMEC Sp. z o.o. 35
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.
To agile or not to agile? © OMEC Sp. z o.o. 36
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.
To agile or not to agile? © OMEC Sp. z o.o. 37
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.
To agile or not to agile? © OMEC Sp. z o.o. 38
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'.
To agile or not to agile? © OMEC Sp. z o.o. 39
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.
To agile or not to agile? © OMEC Sp. z o.o. 40
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.
To agile or not to agile? © OMEC Sp. z o.o. 41
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.
To agile or not to agile? © OMEC Sp. z o.o. 42
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.
To agile or not to agile? © OMEC Sp. z o.o. 43
AgilePM - the people
©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.
Material is reproduced under licence from DSDM Consortium.
To agile or not to agile? © OMEC Sp. z o.o. 44
AgilePM - the process
©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.
Material is reproduced under licence from DSDM Consortium.
To agile or not to agile? © OMEC Sp. z o.o. 45
AgilePM - the products
©2010, 2011, 2012, 2013 Dynamic Systems Development Method Limited.
Material is reproduced under licence from DSDM Consortium.
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
To agile or not to agile? © OMEC Sp. z o.o. 46
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.
To agile or not to agile? © OMEC Sp. z o.o. 47
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.
To agile or not to agile? © OMEC Sp. z o.o. 48
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.
To agile or not to agile? © OMEC Sp. z o.o. 49
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.
To agile or not to agile? © OMEC Sp. z o.o. 50
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.
To agile or not to agile? © OMEC Sp. z o.o. 51
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
To agile or not to agile? © OMEC Sp. z o.o. 52
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
To agile or not to agile? © OMEC Sp. z o.o. 53
WILL AGILE SAVE US?
To agile or not to agile? © OMEC Sp. z o.o. 54
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)
To agile or not to agile? © OMEC Sp. z o.o. 55
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)
To agile or not to agile? © OMEC Sp. z o.o. 56
AGILEPM SAMPLE FOUNDATION
EXAM QUESTIONS
To agile or not to agile? © OMEC Sp. z o.o. 57
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
To agile or not to agile? © OMEC Sp. z o.o. 58
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 withing the organizations' governance needs
d) AgilePM should be tailored to suit Business Sponsor's
individual needs
C
To agile or not to agile? © OMEC Sp. z o.o. 59
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 60
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 61
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 62
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 63
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 64
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 65
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 66
Sample Foundation questions
10.Which role does not belong to the Solution Development
Team?
a) Team Leader
b) Project Manager
c) Business Ambassador
d) Solution Tester
B
To agile or not to agile? © OMEC Sp. z o.o. 67
Sample Foundation questions
11.Which is not AgilePM technique?
a) Quality review
b) Facilitated workshop
c) Modelling
d) Daily standup meeting
A
To agile or not to agile? © OMEC Sp. z o.o. 68
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 69
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 70
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 71
Sample Foundation questions
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
To agile or not to agile? © OMEC Sp. z o.o. 72
Sample Foundation questions
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