AgileGuideEN2019 PDF

DEVELOPMENT PROJECT
MANAGEMENT
Project Management Associate (PMA)

Certification
Learning Guide
2016
AUTHORS
Ernesto Mondelo Ricardo Sánchez, PMP
MBA, M.Ed., PMP, SMC, Coach MBA, PMP, PMI-ACP
TECHNICAL REVISION Rocío Briceño L. MBA, PMP, CSM, Coach, STC
IDB COLLABORATORS David Zepeda, PMP, SMC; Santiago Cartagena,

PMP; Victor Roa, MBA, PMP; Lucas Hoepel PMP,
SMC
This document represents the intellectual property of the

2nd Edition Inter-American Development Bank (IDB) and the Inter-American
Institute for Social and Economic Development (INDES). Any partial
January 2019 or full reproduction of this document must be reported to: BID-
INDES@iadb.org.
Este documento es propiedad intelectual del Banco Interamericano de Desarrollo (BID) y del Instituto Interamericano para el Desarrollo
Económico y Social (INDES). Cualquier reproducción parcial o total de este documento debe ser informada a: BID-INDES@iadb.org
Page 2
TABLE OF CONTENTS
1. Introduction
2. The Agile Fundamentals
2.1. Basic Principles.
2.2. Characteristics of Development Projects.
2.3. Agile Mentality.
2.4. Agile Triangle.
2.5. Agile Manifesto.
3. PM4R Agile Methodology
3.1. Pillars and Values.
3.2. Roles.
3.3. Tools.
3.4. Activities
4. Steps for the Development of PM4R Agile Plan5 Steps for the Development of the
PM4R Agile Plan.
4.1. Analysis and Consultation of the Stakeholders.
4.2. Step 1: Analysis of the Existing Elements for the Planification Project.
4.3. Step 2: Selection of Priority Works.
4.4. Step 3: Development of the PM4R Agile Plan.
4.5. Step 4: Assignment of Responsibilities.
4.6. Step 5: Implementation of the PM4R Agile Plan
4.6.1. Agile Start Up.
4.6.2. Agile Follow-up and Control.
5. Bibliography.
6. Glossary.
Page 3
INTRODUCTION
The Project Management for Results (PM4R) adventure started in the year 2011 with
the development of a methodology based on the PMBOK® Guide, international
standard for project management of the Project Management Institute (PMI®). PM4R
is the first for project management methodology for development projects in Latin
America and the Caribbean. As a result of continuous successes applying the PM4R
methodology to the management of the projects that the Inter-American
Development Bank finances, the PM4R Agile approach presented here constitutes a
leap into the future for the management of development projects. This does not
mean that the PM4R methodology is replaced by the PM4R Agile approach, but rather
it is presented as a valuable complement to manage some critical works where time
is the most important element to control. The PM4R Agile approach is based on the
Agile Practice Guide and gathers good practices from Agile PM (Prince 2) and Scrum.
It represents a cultural change in the management of development projects and in
particular, a new way of working by the people who make up the team of a project.
PM4R Agile methodology has been the product of more than a dozen workshops in
as many countries for more than a year and with different projects ranging from
providing drinking water to the population and improving road infrastructure, to
strengthening the security system of the citizens. In these workshops where the main
stakeholders participated, a non-traditional approach was used so that the projects
could obtain results with more value in less time.
The PM4R Agile methodology is based mainly on the lean philosophy (eliminate
waste, involvement of all and continuous improvement) that originated in the
Japanese automotive industry, the agile practices that derived from it and that were
initially used in the software development industry and then applied to all different
types of projects. Now the PM4R Agile methodology is introduced for the first time
to the development projects in Latin America and the Caribbean.
® PMBOK, PMI and PMI-ACP are registered trademarks of the Project Management Institute
Page 4
The intention of this document is to serve as a quick implementation guide for
visionary teams that are willing to make a radical change in the way they manage
their projects and the most critical works. With the use of PM4R Agile your list of
successful projects will be much longer.
Ernesto Mondelo
PM4R Director
Albert Einstein
“Do not expect different results if you always do the same"
Page 5
Page 6
BASIC PRINCIPLES
Why should we use a different project management

approach than the one we already know? The answer is
simple: projects need an adequate approach to the
situation they are going through. Especially those
projects that are in a complex and changing environment
need an agile approach.
This new approach is based on the following principles:
• Change is welcome
o One of the fundamental principles of traditional project

management approach is to try to influence the factors that cause
changes so that they do not happen or are minimal. Agile sees this
differently: it is expected that the project requirements will change
and indeed we welcome those changes, even if they happen late
in the project. Responding quickly to change and adapting to it can
give project beneficiaries a significant competitive advantage
when opportunities arise.
• Work in small increments of added value
o Agile teams do some planning, deliver something of value, get

feedback, and repeat the cycle.
• Use performance and feedback cycles.
o The point is to quickly put into the hands of the users or

beneficiaries a result that can be used or obtain valuable feedback
about it.
• Learning through discoveries.
o In the agile teams the spread of specialists is encouraged, which

means, people who can assume different roles during the
execution of the work and who are willing to learn by doing so are
welcomed.
Page 7
• Performance driven by value
o To maximize success, the team tries to deliver high-value

components as soon as possible, before things change or they go
the other way. Another reason is that stakeholder satisfaction plays
a substantial role in the success of the project
• It is acceptable to be wrong, but you have to do it quickly and learn

from the mistakes.
o In the traditional approach, if mistakes are made, they are

discovered at the end, when there is nothing left to do. The agile
approach includes cycles of execution and feedback where
mistakes can be discovered early to correct them before the next
cycle.
• Continuous delivery
o Agile teams deliver results quickly and continuously.
• Continuous improvement.
o It refers to the cycle of continuous improvement of Deming: Plan,

Do, Revise, Act.
To apply and make these our principles, will not only make us use other tools,
but also the desired change of mentality: the agile mentality.
Characteristics of development projects
The final goal of development projects is to obtain concrete results that can boost
the socioeconomic development of a country or a region. These projects are carried
out under socio-economic assumptions that respond to a logic of gradual change
whose long-term results are only achieved through the achievement of intermediate
results. Projects must respond to this logic by generating intermediate results on a
path of change whose ultimate goal is to obtain sustainable results in the long term.
These characteristics are ideal to use as a different approach to the traditional project
management approach to achieve different results. Additionally, more and more,
development projects have to do with the creation of knowledge. For example, a
project to create a new justice system or to produce regulatory improvements. These
projects that generate knowledge have the following characteristics:
Page 8
• Less structure with more decisions;
• Give autonomy;
• Continuous innovation;
• Focus on quality;
• Learn and teach continuously; and
• Treat employees as capital, not as costs.
So, if we combine the characteristics of development projects with those of projects

that generate knowledge, we have the ideal result to apply an agile approach. In
addition, the performance of these projects is characterized by uncertainty and risks,
so the process has to be empirical, that is, iterative and incremental with frequent
revisions and adaptation. Communication and collaboration in this environment are
crucial to avoid frustration and failures.
The agile mentality
• PM4R Agile is an iterative and incremental method of managing activities in a

very flexible and interactive way.
• Agile methods aim to respond to high levels of change and to the continuous
participation of stakeholders.
• Being agile is not simply a matter of using a certain set of tools or practices or
following a specific methodology. Agility implies the adoption of a new way
of thinking that is based on agile values and principles.
• Being agile begins by making the agile mentality a habit, then using that
understanding to select and implement the right practices, adapting them to
different situations as needed
Charles R. Darwin
"It is not the strongest of the species that survives, nor is it the most intelligent that
survives. It is the one that is most adaptable to change."
Page 9
The Agile Triangle
In the traditional approach we were accustomed to defining the scope of the project
first and then planning its duration and cost. Both were defined precisely according
to the agreed scope, and if it was necessary to make some adjustment in time or
cost, this had a direct impact on the scope.
On the contrary, in the agile approach, cost and duration can be fixed. The scope
varies depending on the delivery of value to the beneficiaries in each iteration or
sprint, keeping in mind the final result of the project that was visualized at the
beginning. That the scope is "variable" does not mean that today we want a result of
the project and tomorrow a different one. It means that we generate value in each
sprint, it is checked if the obtained value will allow us to achieve the expected
benefits of the project within the time and cost constraints.
For example, imagine that we are developing the procedural manuals of a new
criminal justice system (a project that generates knowledge). Do you agree that in
this type of project we could continue to add figures, examples, references, activities
... "indefinitely" ?, but it may not be necessary to go to such a level of detail in order
to deliver the expected results to the beneficiaries, therefore we set a fixed delivery
date and a budget. This means, we set the time and cost as fixed.
The Agile Manifesto

The Agile Manifesto includes a statute with four values and twelve guiding principles
“we are discovering the better ways to develop software both from our own
experience and helping third parties”.
This manifesto was created during a meeting of developers and software

methodology experts convened by Kent Beck to discuss new techniques and
Page 10
development processes. In this meeting carried out in February 2001, the term "Agile
Methods" was created to define those alternative methods to the traditional
methodologies that at that time were already considered excessively heavy and rigid
due to their regulatory nature and heavy dependence on detailed planning prior to
development.
We value individuals and their interaction more than processes and tools.
We value software that works more than exhaustive documentation.
We value collaboration with the client more than contractual negotiation.
We value the response to change more than following a plan.
Page 11
The twelve principles are:
1. Our main priority is to satisfy the customer through the early and
continuous delivery of valuable software.
2. Changing requirements are welcome, even if they arrive late in the

development. Agile processes adapt to change as a competitive
advantage for the client.
3. Frequently deliver software that works, in periods of a couple of weeks to

a couple of months, with preference of the shorter periods.
4. Businesspeople and developers must work together on a day-to-day

basis through the project.
5. The projects are built around motivated individuals, giving them the
environment and support they need, and offering them confidence to do
the work.
6. The most efficient and effective way to communicate information to and

within a development team is through face-to-face conversations.
7. The software that works is the main measure of progress.
8. Agile processes promote sustainable development. Sponsors, developers

and users must maintain a constant indefinite rhythm.
9. The continuous attention to technical excellence and a good design

improves flexibility.
10. Simplicity as an art to maximize the amount of work not done is essential.
11. The best architectures, requirements and designs emerge from self-
organized teams.
12. At regular intervals, the team reflects on how to be most effective and
adjusts its performance accordingly.
Page 12
Page 13
PM4R METHODOLOGY
Pillars and Values
As mentioned above, the agile approach is above all a change of mentality, and it
works when this way of thinking is embraced by a visionary project team that is willing
to change the way they work.
The PM4R Agile methodology is a set of roles, activities, tools and steps designed to
guide the team towards an agile performance of the project.
This methodology is based on three pillars:
PM4R Agile Pillars
Comitment
Transparency Inspection Adaptantion
with the Result
Commitment with the Results: Ownership as an individual and as a team of the

deliverables.
Transparency: Allows that all aspects of the process can be observed by anyone.
Inspection: Making timely checks on how ell the project is progressing.
Adaptation: Learn and make improvements during the process.
And six values PM4R Agile:
1. Iterative development
a. Create products that meet the needs of the stakeholders and

manage changes better.
Page 14
2. Empirical control of the process
Inspection and regular adaptation are based on the results obtained and
the context of the project itself.
3. Self-organized team.
People with a great understanding of commitment and responsibility
4. Collaboration
Creation of shared value.
5. Time as a restriction
It is used to effectively manage the planning and performance of the
project.
6. Priority based on value

Offers the maximum value of business, from the beginning of the project
to its conclusion.
Iterative
development
Priority based on Empirical control

value of the process
Time as a Self-organized
restriction team.
Collaboration
Page 15
Roles
Development projects are typically complex, have multiple components, many

products and are difficult to manage by a single person. That is why the following
roles have been defined for the PM4R Agile methodology:
• Sponsor
o The sponsor promotes, provides resources and support for the project
and is responsible for facilitating its success.
o Serves as a spokesperson in the face of high levels of management.
o Participates in the authorization and / or change of scope, end-of-

phase reviews and decisions on the continuation of the project.
o He/she is responsible for the result of the project.
• Product owner
o It is the only authority responsible for deciding the characteristics

and functions that the final product or result of the project will have.
o Represents other users and interested persons(stakeholders).
• Super Agile Leader
o Coordinates between the agile leaders and solves the problems or

impediments that each team has.
o Provides assistance with respect to resources and the

authorization of work.
o They are the bridge between the work teams and the product
owner and the sponsor.
• Agile Leader
o He is the owner of the process and responsible for adapting it to

the conditions of the project.
o Manages obstacles and coordinates controlled activities.
o Is responsible for the commitment to the work that should be done.
Page 16
• Agile team
o They are responsible for defining the way in which the work will be
performed.
o It is recommended that it be a small number with physical

proximity.
o Agile teams work best when they are made up of experienced,

skilled and highly self-directed persons/members.
Sponsor
Product
Owner
Team
Super
Agile
Agile
Leader
Leader
At the beginning of this chapter it was said that this PM4R agile methodology works
when it is received by a visionary project team that is willing to change the way they
work. In addition, it is also required that the team is self-organized, which means that
team members can commit themselves, resolve conflicts and work towards a
common goal. All team members are collectively responsible for everything, which
means that the responsibility for the outcome of the project is shared. Self-
organization provides a way for the team to succeed, fail, adjust and improve
together. Agile teams work best when the team consist of experienced, skilled and
highly self-directed persons.
According to Schwaber and Sutherland, an agile team could have 7 ± 2 members. If

the teams are small, they develop better relationships and communicate more
directly. Team members must have complementary skills and be committed to a
common purpose. The team must share ownership of the project result.
Page 17
Regarding the participation of the team members, each one is expected to make a
positive and measurable contribution for the success of the project. The key is that
the contribution of each member should be visible to the whole team. Team
motivation should increase as much as each team member contributes to the
success of the project
Having team members who can perform different tasks, helps minimize that there
are members doing nothing and avoids peaks and valleys in their workload.
Spreading specialists, that all team members can do everything, helps solve
bottlenecks, sharing the workload.
Page 18
According to Carl Larson and Frank LaFasto, high-performance teams are built as
follows. They:
• Create a shared vision for the team.
• Set realistic goals.
• Limit the team to 12 or fewer members.
• Build a sense of team identity.
• Provide strong leadership.
In development projects, you typically have an agile leader and one team for each
component of the project.
Leaders who use the PM4R Agile methodology recognize that it is team members,
not them, who do the work and achieve value for the organization and the
beneficiaries. They provide what the team needs, remove the impediments to their
progress and perform support tasks to maximize their productivity.
There are five clear actions of agile leaders to serve the team (servant leadership):
• Protect the team from interruptions.
• Remove the impediments to progress.
• Limit the team to 12 or fewer members.
• Communicate the vision of the project whenever it is necessary.
• Provide what the team needs to do their job.
The agile leader is not a filter or control for decision-making, he is in charge of

making things happen so that the team can progress and fulfill the project's
objectives.
Page 19
Tools
Priority work
The product owner, with the collaboration of the team, orders the work by priorities
in a list of elements required to create the product or final result of the project. The
prioritization is conducted according to the value that the work contributes to the
achievement of the project's objectives. The acceptance criteria of the work on the
list have to be defined, with which verification will take place during the sprint review.
This list is also called the product backlog or prioritized product list. In this list, the
work related to the deliverables that were rejected during the previous sprint review
(see sprint deliverables paragraph) are included because they did not meet the
acceptance criteria and should therefore also be included.
Work A
Work B
Work C
Work N
PM4R Agile Plan
It is the subset of work that the team selected from the Work Breakdown Structure
(WBS) for each of the Sprints of the PM4R Agile plan.
Work should be decomposed at the task level. It is very important that at the time of
selecting the works, the team estimates the complexity and time to perform them. In
the event that a work requires more time than a sprint lasts, it will have to be
decomposed into smaller parts that will be programmed in the other sprints of the
PM4R Agile plan. If it is not possible to decompose a work by its nature, then in each
sprint it will be necessary to program a partial result that serves as a control. For
example, in an acquisition, which usually lasts more than two weeks, the minutes,
reports or any other document will have to be included in each sprint to indicate the
progress of that work.
Page 20
Sprint
Agile projects are divided into sprints. In the development projects, it is

recommended that the sprints last two weeks, but that will depend on the
complexity and characteristics of the project. It is also recommended that an agile
plan be developed every three months until the project is completed.
Page 21
Sprint Deliverables
It is the product or result of the sprint that has real functional characteristics so that
it can generate an expected value. These deliverables are inspected by the sprint
review. Deliverables that meet the criteria established by the owner of the product
are accepted and those that do not comply are rejected and sent to the prioritized
set of work for prioritization and programming in the following sprints. Deliverables
should not be rejected frequently, as this would indicate poor planning of work or
time. Additionally, it will be necessary to have an escalation mechanism to approve
the rescheduling of the sprints.
Page 22
Activities
Analysis of the existing elements of project planning.
The key stakeholders of the project, team members, sponsor, contractors, personnel
of the finance group and any other person whose participation is important, meet to
analyze the existing planning instruments, such as the project plan (PEP, POA at the
IDB), WBS and any other planning element that the project has. If the WBS is not
available, it has to be developed, since it is the base for the selection of priority works
Selection of priority works
The team, in collaboration with the product owner and the super agile leader and
other key stakeholders, selects the priority works for the next three months from the
WBS. This work is prioritized according to the value they bring to the project's
objectives and must have three characteristics: critical, priority and achievable.
The output is a prioritized set of work for each component of the project.
Development of the PM4R AGILE Plan
The work team meets to determine which work will be developed and delivered at
the end of each sprint. For a development project it is recommended to plan six
sprints of two weeks each and repeat this as many times as necessary to complete
the project. That is, the PM4R Agile plan will last for three months and will be
repeated as many times as necessary. The team breaks down work into tasks,
estimates durations and decides how the work will be done. It is valid to obtain criteria
and expert opinion to perform these activities. The product owner must be present
to clarify his vision of the result of the project, if necessary. The output is the three
months PM4R Agile plan.
Execution of the Sprint
The team performs the necessary tasks to complete work engaged in each sprint.
During the performance, its very important to maintain accurate and effective
communication, especially through the co-location of the team, informal
conversations and face-to-face interactions.
For the execution of each sprint it is recommended to use a board on which the
members of the project team and other stakeholders, can graphically visualize at any
moment the advances of the sprint in a quick and simple way. In the agile approach
Page 23
the use of the tools called: low tech high touch is promoted. As for example the
following board:
To Do In Process Done
Work 6 Work 3 Work 1
Work 7 Work 4 Work 2
Work 8 Work 5
In the first column or the” To do” column, the work placed in the sprint. At the start
of the sprint all the work will be in this column. Once you start the performance, work
is moved to the "In progress" column and when they are completed, they are moved
to the “Done” column. Ideally, at the end of the sprint you would expect all the work
to be completed.
Sprint Review
The team meets with the product owner and agile leader to present and review
deliverables completed at the end of each sprint. The focus of this meeting is on the
product or result of the sprint. Deliverables must meet the acceptance criteria
defined by the product owner at the start of the sprint. In case that a deliverable does
not meet the acceptance criteria, it is considered as a rejected deliverable. The work
corresponding to that deliverable will be incorporated in the prioritized set of work
so that they can be considered for execution in the next sprint.
Sprint Retrospective
The team performs the activity of inspecting and adapting at the end of each sprint.
Compiles lessons learned and looks for opportunities of improvement. The focus is
on the process to generate the deliverables. The discussions in these meetings
should include both what went well and what went wrong. The objectives of the
retrospective are to identify:
Page 24
o Best practices: the things that the team has to keep on doing.
o Improvements in the process: the things that the team has to start
doing in the next sprint.
o Problems of processes and obstacles: the things that the team has
to stop doing
The agile leader takes note of the problems and obstacles reported by members of
the team to solve them. In the case that he/she cannot solve them, the agile leader
should submit them to the super agile leader. If yet they cannot solve the problem,
the super agile leader must submit them to the project’s sponsor.
Page 25
Page 26
DEVELOPMENT OF THE PM4R AGILE PLAN
Once the activities and tools of the PM4R Agile methodology have been presented,
we will proceed to present the processes for the development of the PM4R Agile
plan.
1. Analysis of the existing elements of the project planning
2. Selection of priority works
3. Development of the PM4R Agile plan
4. Assignment of Responsibilities
5. Implementation of PM4R Agile plan
Before starting the development of the PM4R Agile plan, it is suggested to carry out
a series of interviews with key stakeholders of the project, for example: sponsor,
manager and members of the Executive Unit, members of the project team on behalf
of IDB, contractors and beneficiaries. During these interviews we are trying to obtain
an objective view of the challenges and opportunities of the project and to find
underlying factors that can be affecting the execution of components, but that are
not easily detectable in the official documentation. It is also intended to gather
information on which of the works, in the opinion of these key stakeholders, are
priorities for the coming months, especially the following three.
These interviews are coordinated with the team leader of the IDB and the manager
of the Execution Unit of the Project with at least one month of anticipation. It is
essential that the list of interviewees includes the sponsor (s) of the project and the
main contractors.
It is recommended that the interviews be face-to-face meetings, although in some

cases for logistical reasons, they can be done via telephone or virtually. It's very
important to have the interview scheduled at least two weeks prior to its occurrence,
in order to invite the interviewee with enough time between and to receive their
confirmation. The agenda should include the names of the interviewees, their
function/job title, telephone, email address and address where the interview will be
carried out.
Page 27
During the interviews, the PM4R Agile experts, will try to identify the challenges and
project opportunities, their solutions and the priority works for these stakeholders.
For the development of the PM4R Agile plan it’s recommended to carry out a two-
day workshop facilitated by experts in the PM4R Agile methodology, and with the
participation of key stakeholders to the project, following these steps:
1. Analysis of the existing elements of project planning
It begins with the formation of work teams, usually by component, according to the
PM4R Agile roles described in chapter 3. Once the teams are formed, they perform
the analysis of the existing project planning elements, such as the project plan (PEP,
AOP in the case of the IDB), the Work Breakdown Structure (WBS), the schedule, the
S curve, etc. If the WBS is not available, the team, with the help of the PM4R Agile
experts, will have to develop it, since it is the base for selection of the priority works
that will be included in the PM4R Agile plan. If the component you are working on is
already in execution, ensure that only the works that have not been completed yes
are considered for inclusion in the WBS.
The result of this step is a revised / improved WBS
2. Selection of the priority works
Once the existing project planning elements have been analyzed, and there is a
revised / improved WBS, the team, with the collaboration of the product owner and
the super agile leader, selects the work to be done for the next three months. These
works must have three characteristics:
Page 28
o Priority (which has preference over another thing)
o Critical (which has great importance and requires urgent attention
or action)
o Achievable (which can be obtained or achieved).
If a work does not have these three characteristics, it should not be selected. It is also
fundamental that the selected works have a significant weight in the budget or are
part of the critical path. As well as a person in charge who is part of the team that is
present during this process.
The result of this step is a set of prioritized work.
3. Development of the PM4R Agile plan
It is recommended that the PM4R Agile plan comprises a planning horizon of three
months. These three months are organized in 6 sprints of two weeks each. For their
realization, the work team meets to determine which elements of the set prioritized
work will be developed and delivered in each sprint. If a work lasts estimated more
than two weeks, that is, a sprint, it must be broken down into smaller elements.
The suggested way to make the plan is drawing six columns on the wall representing
the six sprints. Each sprint should have a beginning and ending date, and then, the
team members place the of work, represented by post its, in each one of the
columns. It is important that the workload in each sprint be balanced, since there is a
tendency for more work schedule in the initial and final sprints.
Once the work is placed in the sprints, the work team validates the plan with the
owner of the product and the agile leader. It is fundamental that the plan is realistic,
since it represents a commitment that the entire team must fulfill.
The result of this step is the PM4R Agile plan.
Page 29
4. Assignment of Responsibilities
The responsibilities for each work are assigned when the team has validated the
PM4R Agile plan with the owner of the product and agile leader. This can be done
by writing in smaller post-its the names of those responsible and placing them in the
corresponding work.it Is very important that you do not assign a responsibility to
someone who is not present, and if that were the case, by exception, the team must
commit to inform that person about the responsibility that has been assigned to them
and inform the designated agile leader that the person has accepted the
responsibility assigned.
The result of this step is the assignment of responsibilities in the PM4R Agile plan.
5. Implementation of the PM4R Agile plan
5.1 Agile Start up
Once the PM4R Agile plan is developed for the next three months, what
follows is to carry out the committed work for each sprint.
As seen in chapter 3, in this process the team, the agile leader and if it is the
case, the contractors and other key stakeholders must participate. The
techniques that are used to perform the work are: meetings, Expert opinion
and communication. The output of the performance of the sprint is the set of
deliverables.
It is suggested to use a board like the following, which is an adaptation of the

Kanban method, which in turn derives from the lean production system
Page 30
developed in Toyota. "Kanban" is a Japanese word that means "board." This
board shows the work at each stage of the process of "production" defined by
the team.
In the first column (“To do”) all the Sprint work are placed. Once the sprint
starts, the work move through the following columns according to the
progress it has as indicated by the arrow of value flow. For example, if a work
has been started, it must be in the "in process" column. If a work is already
finished and is being revised or is in acceptance (authorization), place in the
column "in verification / acceptance ". Finally, when a work has been verified
or accepted, it is placed in the column "Completed". The idea is that at the end
of the sprint, all the work that were in the first column, should be placed in the
last one, which means, that they are completed. If, at the end of the sprint any
work has not been completed, it must be scheduled for the next sprint. This
situation should not be repeated in each sprint, because it would cause
accumulation of the work to be done at the end of the plan, with the
consequence of failure of the activities.
It is recommended that at the first moment that this situation is presented, the
agile leader requests support from the super agile leader, since the reason
that a work has not been completed in a sprint, usually has to do with
Page 31
decisions that must be made and that are beyond the scope of authority of
the team.
The result of this step is the set of sprint deliverables
5.2 Revision and Inspection
In the PM4R Agile methodology, monitoring and control takes place, but is
reduced to its minimum.
That means, only the necessary and conducted by the team, as mentioned
previously, must be self-directed and self-controlled. The focus must be on
adaptation and continuous improvement, that is, instead of only inspecting
to find mistakes for correction, the team learns and improves the process
with which it produces the deliverables in every sprint.Agile tracking and
control is given in two moments: during the performance and at the end of
the sprint.
During the performance, the team can use the Board shown in the previous
section:
With this board, besides graphically and easily showing the flow of the work
packages, the amount of work in process can be controlled (second column).
When the work is starting to accumulate in this column means that you have
created a bottleneck and there's something that prevents the team from
progressing. This is a good indicator for the team to identify problems or
impediments and be more productive. These problems or impediments must
be communicated to the agile leader to manage and resolve them.
Page 32
At the end of the sprint we have two activities of monitoring and control:
review of the sprint and retrospective of the sprint. Both have to be performed
through a team meeting with the agile leader and the owner of the product.
Sprint review
It focuses on the results of the works; this means that the deliverables
generated are displayed and inspected at the end of the sprint. If any
deliverable does not meet the criteria of acceptance defined by the owner of
the product, it must be included in the following sprint for correction. As it was
mentioned before, this is not ideal, since all the work dedicated in the sprint
must be complete and should comply with specifications (acceptance
criteria).
Sprint retrospective
It focuses on the process that the team used to generate the deliverables.
The discussions in these meetings should include both what went well as well
as what went wrong. The objectives of the retrospective are to identify:
o Best practices: the things that the team must keep on doing.
o Improvements in the process: the things that the team must
start doing in the next sprint.
o Process problems and obstacles: the things that the team must
stop doing
This lesson must be applied immediately, that is, in the next sprint.
Finally, these 5 steps can be repeated in three months’ cycles until completing the
project.
Page 33
BIBLIOGRAPHY
Crowe, Andy. The PMI-ACP® Exam. United States of America, Iteration 2, 2016.
Griffiths, Mike. PMI-ACP® Exam Prep Second Edition. United States of America, RMC
Publications,
Inc. 2015.
Mondelo, Ernesto. Siles, Rodolfo. Certification Project Management Associate (PMA)

Learners Guide. United States of America. Inter-American Development Bank. 2016.
Project Management Institute. La guía de los fundamentos para la dirección de

proyectos (Guía del PMBOK®). Sixth edition. United States of America. Project
Management Institute, Inc. 2017.
Satpathy, Tridibesh. Una guía para el conocimiento de Scrum (Guía SBOK™). United
States of America, SCRUM Study™. 2013.
Womack, James P., Jones, Daniel T. Lean Thinking. United States of America, Free
Press. 2003.
Page 34
GLOSSARY
Adaptive life cycle Deliverable
The Adaptive life cycles (agile In the context of the WBS, a

methods) aim to respond to high levels deliverable is the result of the effort,
of change and the continued not only the effort itself.
participation of stakeholders. Adaptive
methods are also iterative and
Gradual delivery
incremental, but they differ that the
Iterations are very fast, and duration It's another way in which the agile
and cost are fixed. methods deliver value. The team
regularly deploys work increases of
the product throughout the project.
Co-location
Reduce the amount of re-work due to
All team members working together in early problem finding, thus
the same location. It means working at contributing to the delivery of value in
a maximum distance of 10 meters the project.
without physical barriers.
Self-organized teams
WBS
A self-organized team requires
Disaggregated Work Breakdown members that can commit, solve
Structure. It is a hierarchical conflicts and work towards a common
organization of the deliverables of the goal. All team members are
Project. It defines the scope of the collectively responsible for everything.
Project. It does not include time or The self-organization provides a way
costs, only deliverables. for the team to succeed, fail, adjust
and improve together.
Performance driven by value

Agile teams
Agile methods are value-driven, its
objective is to maximize the business If the teams are small, they develop
value with delivery. better relationships and communicate
more directly. The members must
have complementary skills. The teams
are committed to a common purpose.
Page 35
The team shares ownership of the knowledge and the learning really
result of the project. happen in a project.
Estimate Value added increments
Evaluation of the duration, effort and / It's a key way in which Agile teams
or cost required to complete a task or seek to maximize value. It means that
project. the team manages to deliver the
highest value portions of the project
as soon as possible.
Analogue estimate
Technique used to estimate the

Stakeholders
duration or cost of an activity or a
project using historical data from an People and organizations that could
activity or similar project. be impacted by the project or the
result of the Project
Parametric estimation
Work package
An estimation technique which uses an
algorithm to calculate the cost or the The work at the lowest level of the
duration based on historical data and work breakdown structure for which
project parameters. the cost and duration can be estimated
and managed.
Low technology tools and high

awareness Iterative and incremental
These tools are simple, such as cards The iterative and incremental life
and graphics and they are easy to cycles are those in which, within
manipulate by all stakeholders. By phases of the project, one or more
using these techniques, the accurate project activities are intentionally
perception of the data is avoided and repeated as the project team's
allows more people to update the understanding of the product
plans as needed. They promote increases. The iterations develop the
communication and collaboration, product through a series of repeated
which is where the transfer of cycles, while the increments add
Page 36
continuous functionality to the
product.
POA (Annual Operating Plan)
Detailed plan that shows the methods

Learned lessons of implementation, timelines, goals,
the deadlines, objectives and points of
Group of experiences obtained after
temporary evaluation of a project or
the conclusion of a project or a part of
program.
it. The experiences describe in a
neutral way what worked and what did
not do so and it includes a report about
Frequent reviews and adaptations
the risk that could be caused by
Agile uses tests and review points on a
ignoring the lesson learned. Capturing
regular basis to address the problems
and sharing the lessons learned is a
before they get bigger. It is an effective
part of the improvement process.
antidote for the fact of making
mistakes as well as for the
Service leadership misinterpretations of what the client
wants. With frequent verification and
The leader provides what the team
validation, we make sure that things
needs, removes impediments for their
and the work progress as they should.
progress and performs support tasks
to maximize productivity.
Sprint
Continuous improvement It is a short period of time of fixed

duration in which a defined set of
Also known as the Deming cycle: Plan,
activities or work is carried out.
Do, Review and Act.
PEP
Project or program’s performance
plan.
Page 37

AgileGuideEN2019 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AgileGuideEN2019 PDF

Uploaded by

Copyright:

Available Formats

DEVELOPMENT PROJECT

Project Management Associate (PMA)

Ernesto Mondelo Ricardo Sánchez, PMP

MBA, M.Ed., PMP, SMC, Coach MBA, PMP, PMI-ACP

TECHNICAL REVISION Rocío Briceño L. MBA, PMP, CSM, Coach, STC

IDB COLLABORATORS David Zepeda, PMP, SMC; Santiago Cartagena,

This document represents the intellectual property of the

2. The Agile Fundamentals

2.1. Basic Principles.

2.2. Characteristics of Development Projects.

2.3. Agile Mentality.

2.4. Agile Triangle.

2.5. Agile Manifesto.

3. PM4R Agile Methodology

3.1. Pillars and Values.

4.1. Analysis and Consultation of the Stakeholders.

4.3. Step 2: Selection of Priority Works.

4.4. Step 3: Development of the PM4R Agile Plan.

4.5. Step 4: Assignment of Responsibilities.

4.6. Step 5: Implementation of the PM4R Agile Plan

4.6.1. Agile Start Up.

4.6.2. Agile Follow-up and Control.

“Do not expect different results if you always do the same"

Why should we use a different project management

This new approach is based on the following principles:

o One of the fundamental principles of traditional project

• Work in small increments of added value

o Agile teams do some planning, deliver something of value, get

• Use performance and feedback cycles.

o The point is to quickly put into the hands of the users or

• Learning through discoveries.

o In the agile teams the spread of specialists is encouraged, which

o To maximize success, the team tries to deliver high-value

• It is acceptable to be wrong, but you have to do it quickly and learn

o In the traditional approach, if mistakes are made, they are

o Agile teams deliver results quickly and continuously.

o It refers to the cycle of continuous improvement of Deming: Plan,

Characteristics of development projects

• Learn and teach continuously; and

• Treat employees as capital, not as costs.

So, if we combine the characteristics of development projects with those of projects

The agile mentality

• PM4R Agile is an iterative and incremental method of managing activities in a

The Agile Manifesto

This manifesto was created during a meeting of developers and software

We value software that works more than exhaustive documentation.

We value collaboration with the client more than contractual negotiation.

We value the response to change more than following a plan.

2. Changing requirements are welcome, even if they arrive late in the

3. Frequently deliver software that works, in periods of a couple of weeks to

4. Businesspeople and developers must work together on a day-to-day

6. The most efficient and effective way to communicate information to and

7. The software that works is the main measure of progress.

8. Agile processes promote sustainable development. Sponsors, developers

9. The continuous attention to technical excellence and a good design

Pillars and Values

This methodology is based on three pillars:

PM4R Agile Pillars

Commitment with the Results: Ownership as an individual and as a team of the

Inspection: Making timely checks on how ell the project is progressing.

Adaptation: Learn and make improvements during the process.

And six values PM4R Agile:

a. Create products that meet the needs of the stakeholders and