open in app

sign up
sign in

William P. de Carvalho

Follow

Jun 24, 2019

🇧🇷

31 min read

save

A summary of the PMI/Agile Alliance “Agile Practice

Guide” book

This post was designed for those who are preparing for the PMI-
ACP certification .

Preparing for the PMI-ACP certification is “mandatory” to study the

contents of the Agile Practice Guide , published by PMI itself in partnership
with the Agile Alliance . I decided to make this summary to help consolidate
the knowledge acquired in the study, and publishing it is a form of
contribution with those who are also studying for the PMI-
ACP certification , or simply want to have an idea of how PMI views Agile
practices.
The Agile Practice Guide has 7 main chapters, and then a lot of content in
its appendix. My aim was to summarize the main chapters, not including the
appendices.

I had some difficulty summarizing some parts of the content because

the Agile Practice Guide is already quite short, but rest assured I tried!

Here goes my “almost summary” =)

1. Introduction

The goal of the team that wrote the Agile Practice Guide was to create a
practical guide to guide leaders and team members in adopting Agile
approaches in project planning and execution. The first point brought is the
project type classifications. The traditional forms of project management are
called by the authors as the predictive type, and here they clearly refer to the
Waterfall model. Non-predictive projects are simply classified as Agile
projects, which is the focus of the Book.

The Book also describes in the Introduction that Agile approaches are
appropriate for the disruptive moment that organizations are going through
in recent years, and, with Agile approaches, these organizations are able to
deliver value to customers in a faster way. He mentions that the customer is
in the first Agile principle (Agile Manifesto and the 12 Principles of the Agile
Manifesto ) and emphasizes that transparency and a fast feedback loop with
the customer are key aspects in Agile projects.

2. An Introduction to Agile

The Agile approach is put into context in this chapter.

2.1 Defined work vs. Work with a high degree of uncertainty

The first point here is the indication of traditional forms (eg Cascade ) of
execution for projects that have low uncertainty (domain of knowledge and
clarity of requirements). In these approaches, the level of knowledge
regarding the scope and form of delivery are sufficiently capable of giving
the comfort to structure the project phases and activities in detail even
before starting execution. Typically, there is a faithful reference of previous
projects that support this management approach.

Agile approaches are recommended for projects whose level of uncertainty,

chances of change, complexity and risks are high (personal note: that is, the
vast majority of software projects ). Usually these projects involve the
construction of a new design , problem solutions, or even projects that have
never been carried out or that have few faithful references to be used as
support. These projects are exploratory and experimental in nature.

To close the concept, the traditional approaches end up being a not very
good way for projects with a high level of uncertainty, since
the feedback cycles are long and the management of scope changes
throughout the project becomes inefficient and costly. Instead, Agile
approaches work with fast feedback loops , allowing for rapid adaptation (ie
incorporation of scope changes), with frequent and incremental deliveries.

2.2 Agile Manifesto and Agile Thinking

Soon after, the Agile Manifesto is addressed, as well as its 12 principles .

This chapter also covers two very interesting views on Agile approaches. The
first is a model inspired by Ahmed Sidky , who explains Agility as follows:
Vision on Agility

“ Agile is a way of thinking defined by the values of the Agile Manifesto,

guided by the principles of the Agile Manifesto and manifested by various
practices ”.

The book also adds that practices are applied by practitioners according to
needs.

Another way to contextualize Agile approaches is in relation to various

inspiring practices and the Agile frameworks themselves, as the figure
below illustrates.
agile in context

Two strategies for adopting Agile practices are also mentioned. One is to
adopt a framework and faithfully follow it, then experiment and understand
aspects of Agile approaches well. It is not recommended to make
adaptations at the beginning of adoption, as there will hardly be enough
maturity to make the right choices about keeping, abandoning or
adapting. The second strategy mentioned is instead of starting an adoption
at the organizational level, first incorporate Agile practices in projects, but
not necessarily all practices, but those that you judge to make sense given
the context of the specific project, to then experiment and then progressively
and sustainably grow Agile practices in the organization.

2.3 Lean and Kanban Method

Lean thinking originates from Toyota's way of working, called Lean

Manufacturing , this way of thinking emphasizes value delivery, respect for
people, waste reduction, transparency, adaptation and change and
continuous improvement. Agile approaches and the Kanban Method can be
understood as a subset of Lean thinking , as they inherit many of its
characteristics.
Many teams mix several approaches in the way they work, which is not a
problem, as you should use what works for each organization.

The Kanban Method emerged in the mid-2000s as an initiation alternative

to Agile approaches, due to the “start where you are” characteristic. It is also
less prescriptive than most Agile approaches, and can be used as a first step
before adopting a more prescriptive Agile approach .

2.4 Uncertainties, risks and the choice of life cycle

PMI places the Stacey complexity model as a reference to decide the correct
approach and life cycle of a project, based on the degree of risks revealed by
2 aspects:

1- Level of clarity / uncertainty regarding project requirements ;

2- Level of mastery / uncertainty in relation to

the technique / technology to be used in the project.
Complexity model proposed by Stacey

The PMI understands that Agile approaches work well at the Complicated
( Complicated) and Complex ( Complex) levels of projects, placing
traditional models as more suitable for the Simple ( Simple) level. And , for
the Anarchy level ( Anarchy or Chaos as referenced by the PMI ), it is
recommended that one of the aspects, Requirement or Technology, be
mitigated first, to then enable the project execution, otherwise the risk level
becomes extremely high.

3. Lifecycle Choice

In the introductory part of this chapter, PMI brings a vision of the 4 possible
types of life cycle of a project, namely:
  Predictive : Traditional, with early-stage planning effort and
linear sequential execution;
 Iterative : an approach with feedback from work still in progress,
thus allowing improvements and changes in continuity;
 Incremental : in this approach, it is possible to deliver to the
customer that allows him to use parts of what was produced;
 Agile : this is an Iterative and Incremental approach, allowing for
frequent refinement and delivery of work.

In addition, it is explained about the nomenclature harmonization made

by PMI when adopting the term Predictive for the life cycle previously
understood as Cascade or Sequential .

3.1 Characteristics of Project Lifecycles

In the Publication, 4 categories of life cycles are covered, whose

characteristics are described through the following table.

Life Cycle Table

The table above should not be seen as a definitive guide, but rather a
reference of how each approach best suits different types of projects.

Another way to understand how life cycles vary is through what PMI calls
the Continuum of Life Cycles .
Predictive and Agile lifecycles are polarized, and that is the concept of the
arrow called Continuum . Therefore, the Incremental and Iterative life
cycles are understood as “middle ground”. There is reinforcement in the
issue that one should not expect a life cycle to be perfect for all projects, but
rather always seek the best balance according to the characteristics.

Another important point is the particularities in the way of planning in each

life cycle, described as follows:

 Predictive : planning and detailing of requirements carried out

exhaustively in an initial phase;
 Iterative : use of prototypes and initial tests trigger changes to
the originally constructed plan;
 Incremental : plans made for successive deliveries, which can be
done in advance or not;
 Agile : planning is carried out and adapted as understanding of
the scope increases, and this is done through frequent reviews of
deliverables that are also frequent.
3.1.1 Characteristics of the Predictive Lifecycle

 High degree of certainty regarding requirements, stable time, low

risk rigor, allows linear executions with little or no surprises;
 Detailed plans of what to deliver and how to deliver. Little or no
change expected;
 Changes are avoided through constant monitoring and scope
control. If they occur, an unexpected increase in cost and time
may occur;
 Deliver significant value to the customer only at the end of the
project.

3.1.2 Characteristics of the Iterative Lifecycle

 Iterations with successive prototypes and proofs of concept help to

improve the quality of delivery and reduce the level of project
uncertainty;
 Used in projects whose complexity is high or when frequent scope
changes are expected;
 They may last longer because they prioritize learning over speed of
delivery.

3.1.3 Characteristics of the Incremental Life Cycle

 Prioritizes speed through partial deliveries;

 These deliverables may vary in size and prioritization criteria, they
do not have the iterative element.

3.1.4 Characteristics of the Agile Lifecycle

 Changes are expected, the iterative and incremental approach

provides feedback for a better understanding and planning of the
project in the next phases;
  Há duas formas do Ciclo de Vida Ágil: 1) baseado em Iteração; ou
2) baseado em Fluxo;
 Baseado em Iteração: time trabalha em iterações com o conceito
de timebox, sendo todas as iterações de mesma duração
independente do trabalho selecionado, que por sua vez é sempre
priorizado pelo de maior valor para o cliente;
 Baseado em Fluxo: o time trabalha em fluxo contínuo, não de
iterações, seleciona o trabalho com base na capacidade disponível,
não necessariamente priorizando os de maior valor para o cliente.
O fluxo do trabalho é definido e controlado num quadro, o
controle é feito por funcionalidade, cujo tamanho varia (não usa o
conceito de timebox), e o trabalho em progresso é mantido ao
menor nível possível para permitir ao time adaptação rápida.

Agile lifecycles are those that comply with the principles of the Agile
Manifesto , in particular the one that emphasizes customer satisfaction.

3.1.5 Agile Suitability Filter

There are several models that help to evaluate the adherence or not of Agile
approaches in projects and organizations (Appendix X3 of the Book deals
with this in detail). PMI understands that each project and each
organization can have unique characteristics, and that hybrid models of life
cycles can be considered.

3.1.6 Characteristics of Hybrid Lifecycles

Not necessarily one approach should be adopted for a project from its
beginning to the end. Certain design objectives can lead to hybrid
lifecycle models that are basically the combination
of Predictive , Iterative , Incremental and Agile , in the same project.
A possible combination is the adoption of an Agile approach at the
beginning of the project, which would address issues of
uncertainty, complexity and risk well, then followed in
subsequent phases by a Predictive lifecycle , with defined and
repetitive activities (eg Rollout ).

Agile and Predictive in sequence

3.1.7 Combined Agile and Predictive Approaches

Outra possível combinação é ter abordagens Ágil e Preditiva ao longo do

projeto como todo.

Ágil e Preditivo usados de maneira simultânea

Esse é um modelo comum de ver, geralmente ainda usando estimativas

exaustivas no início do projeto, atribuição de tarefas a partir de um controle
centralizado característico do modelo Preditivo, mas já utilizando
práticas Ágeis como reunião diária (Daily Standups para o PMI) e outros.
Não se pode chamar esse modelo de Ágil, porque claramente não está
fundamentado no mindset, valores e princípios Ágeis. Também não é
correto dizer que é Preditivo por conter elementos Ágeis.

3.1.8 Predominantly Predictive with some Agile components

Some projects may adopt an Agile approach to a specific scope element that
contains a greater degree of uncertainty, complexity, and risk, in addition to
expected scope changes. Still, such projects are managed and controlled in
a Predictive way .

Predictive with some Agile scope component

3.1.9 Large portion Agile with some Predictive component

There are also projects that mostly adopt an Agile portion and treat a
specific component with a Predictive model . This usually occurs in
projects that have parts of the scope that are managed by external entities,
which cannot be integrated into an iterative and incremental model.

Predominant agile, with predictive component

3.1.10 Fit-for-Purpose Lifecycles

In this section, the Book mentions that project teams can create hybrid
models according to the risk presented by the project, and not necessarily
similar to those previously exemplified. Here, the emphasis is on how the
project will quickly bring more value. The question to ask should be
something like: What combination of approaches will quickly bring the most
value to the organization? One should not adopt an Agile approach simply
for the sake of being Agile.

3.1.11 Hybrid Lifecycles as a Transition Strategy

Teams that are used to and have experienced success
using Predictive approaches often feel a lot of difference when exposed to
Agile approaches. This is accentuated in large organizations with many
teams moving at the same time. For this reason, a gradual transition is best
suited for this type of environment. The Book states that a possible
transition is to first combine an Iterative approach to leverage the issue of
learning and team alignment. Afterwards, the Incremental portion
should be added to accelerate project results.

O PMI entende que essa é uma abordagem possível e que deveria ser
iniciada em projetos pequenos/médios, com menor risco, usando primeiro a
abordagem híbrida, e somente depois expandir para projetos maiores,
crescendo a porção Ágil e diminuindo a Preditiva.

3.2 Misturando Abordagens Ágeis

Dificilmente os times limitam suas práticas a uma única abordagem Ágil.

Aqui o Livro menciona que frequentemente vê-se a mistura de Scrum,
Kanban e XP nos times. Outro ponto importante é que os frameworks não
se ajustam, quem se ajustam são as práticas dos times.

 Scrum: guia na gestão do Backlog do Produto, estabelece

um Dono do Produto, Scrum Master e time multifuncional,
incluindo Planejamento da Sprint, Reunião Diária, Revisão
da Sprint e Retrospectiva da Sprint.
 Kanban: ajuda em melhoria contínua, usa o quadro Kanban para
controlar o fluxo de trabalho, além de tornar impedimentos
visíveis e ajustar os limites de trabalho em progresso. Há outros
conceitos adicionais;
 XP: adoção de práticas de engenharia de software como Cartões
de Histórias, Integração Contínua, Refatoração, Teste
Automatizado e Desenvolvimento orientado à testes.
3.3 Fatores de Projeto que Influenciam a Adaptação

Adaptando Opções para uma melhor adoção de abordagens Ágil

4. Implementando Ágil: Criando um Ambiente Ágil

4.1 Comece com o mindset Ágil

O mindset Ágil normalmente provoca questionamentos a respeito de:

 Como o time pode trabalhar de maneira Ágil?

 Como fazer entregas rápidas, obtendo feedbacks que trazem
benefícios para o próximo ciclo de entrega?
 Como agir de maneira transparente?
 Como focar em itens de alta prioridade, deixando trabalhos que
podem ser evitados?
 Como uma liderança servidora beneficia o time no atingimento
das metas?

4.2 A Liderança Servidora Empodera os Times

A abordagem de Liderança Servidora num projeto deve-se materializar na

seguinte ordem:
  Propósito: ajuda o time entender o propósito do trabalho e isso
torna o time coeso em relação ao objetivo do projeto;
 Pessoas: cria um ambiente em que cada membro do time
contribua para o sucesso;
 Processo: foca na entrega frequente de valor, o produto e os
processos seguidos serão reflexo disso.

Esse tipo de liderança não é exclusivo das abordagens Ágeis, mas se integra
muito bem à elas. Os líderes servidores ajudam os times serem mais
colaborativos e a entregar valor mais rapidamente. Há várias características
nesses líderes:

 Promovem autoconhecimento, segurança, respeito e confiança;

 São bons ouvintes;
 Ajudam no crescimento das pessoas;
 Priorizam ensinar ao invés de controlar;
 Estimulam a energia e inteligência do time.

4.2.1 Responsabilidades de um Líder Servidor

Eles ajudam na comunicação e coordenação dos times com o resto da

organização. Desenvolvem esse relacionamento, ajudam a remover
impedimentos, suportando o time a melhorar seus processos.

4.2.1.1 Líderes Servidores Facilitam

Facilitadores ajudam os times a pensarem e a trabalharem de maneira

melhor. Eles encorajam a participação de todos, a trazer questões para um
entendimento comum, além de compartilhar a responsabilidade pelo
resultado, com soluções aceitáveis. Eles promovem a colaboração e a
comunicação entre times. É uma mudança de paradigma de
gestão/coordenação para facilitação/colaboração.
4.2.1.2 Líderes Servidores Removem Impedimentos
Organizacionais

O primeiro valor do Manifesto Ágil fala que indivíduos e interações são mais
importantes que processos e ferramentas. Os Líderes Servidores agem
diretamente nesse ponto. Eles também ajudam a melhorar processos longos
que causam impedimentos e gargalos, que impedem a agilidades dos times.

Habilidades Interpessoais vs. Habilidades Técnicas

Eles vão além das habilidades técnicas, enfatizando habilidades

interpessoais e de inteligência emocional, ajudam os times a terem mais
iniciativa, integridade, honestidade, inteligência emocional, colaboração,
humildade e disposição para ter uma comunicação que impulsione o time
trabalhar unido.

4.2.1.3 Líderes Servidores Pavimentam o Caminho para a

Contribuição de Outros

Líderes Servidores se esforçam para que o time tenha as condições ideais

para focar exclusivamente na construção do produto e trabalhar para
entregar o valor proposto pelo projeto. Isso inclui trabalhar com outras
áreas da organização, influenciando e melhorando processos e comunicação
para que haja a fluidez necessária do time na entrega de valor. Eles ajudam
as organizações a pensarem diferente.

4.2.1.4 Considere as Seguintes Responsabilidades para os Líderes

Servidores

Eles podem ter vários títulos nas organizações, mas o que eles fazem é mais
importante do que tais títulos:

 Ensinam os stakeholders por que e como ser Ágil;

  Ajudam os times através de mentoria, encorajamento e suporte,
inclusive em suas carreiras individuais;
 Ajudam os times em questões técnicas de gestão de projetos;
 Celebrates success and helps connect with external teams and
professional growth activities.

4.2.2 The Role of the Project Manager in an Agile Environment

Due to the self-organizing nature, many Agile approaches do not recognize

the Project Manager role. However, there are situations in which the Project
Manager can add significant value in Agile environments, with the main
difference being the description of their roles and responsibilities.

4.2.3 Project Managers apply Servant Leadership

The 6th. edition of the PMBOK Guide defines the Project Manager as 'the
person to whom the organization has assigned leadership of the team
responsible for achieving the project's objectives'.

In an Agile environment, Project Managers are no longer the center to serve

the team and the organization, distributing responsibilities and starting to
emphasize and promote coaching to people, boosting collaboration and
“sewing” alignment with stakeholders . The approach that many are used to
is suitable for teams organized in silos, and not for the Agile environment,
where responsibilities are distributed with the Development Team and
Product Manager.

4.3 Composition of Teams

Agile approaches optimize the value stream, prioritizing the rapid delivery
of functionality to the customer, rather than focusing on using people. This
is revealed by giving more importance to individuals and the interaction
between them.
4.3.1 Agile Teams

There are certain recommendations to Agile teams , as they make them

more effective, facilitate self-organization, communication, transparency
and frequent delivery of product increments. The main ones are:

 Teams of 3 to 9 members;
 “Co-located” teams;
 100% dedicated members;
 Multifunctional teams;
 Limits for work in progress ( Work in progress ).

The Publication provides an interesting table, which demonstrates the

attributes that make Agile teams more collaborative.

Attributes of a successful Agile team

4.3.2 Roles in Agile Approaches

In Agile approaches, there are typically 3 roles:

Agile Functions

I-Shaped and T-Shaped team members

The Book mentions two types of team members from a knowledge and skills
perspective, which are:

 I-Shaped: profunda especialização em uma área de domínio e

raramente contribui fora de sua área de atuação;
 T-Shaped: possui especialização em uma área de domínio,
suportada por outras habilidades desenvolvidas, associadas a um
perfil colaborativo, com atuação versátil.

4.3.3 Tornando Especialistas também Generalistas

Times Ágeis são multifuncionais, mas geralmente não iniciam dessa

maneira. Times Ágeis de sucesso são formados em maioria por membros T-
Shaped, os quais se tornaram assim pelas características de intensa
colaboração, auto-organização e determinação na entrega, o que é resultado
de uma atuação baseada em ajuda mútua entre os membros.

4.3.4 Estruturas de Time

Although “co-located” teams perform better in Agile environments, this

does not mean that there is no way to structure distributed teams. Tools and
methods that mitigate the issue of physical distribution must be adopted.
In some situations, teams can also have their cross-functionality local to
optimize the flow during product construction.

4.3.5 Dedicated Team Members

The condition of team members who are not 100% dedicated is not ideal,
but in some cases it is not possible to avoid. It is not ideal as there is a real
loss of productivity when one job is interrupted and then resumes
another. In addition, “multitasking” is a productivity decelerator and
increases the chances of creating defects.

Although not ideal, this is a frequent reality and must be managed in project
teams. It is also important to set realistic expectations for how part-time
members will perform.

4.3.6 Team Workspace

The ideal Workspace for an Agile team is one where all members are “co-
located”. There are several possible layouts , with Cave and Common being
considered good practice. This type of layout has a common area (Common)
where team members work in the same physical location, allowing greater
collaboration, and also provides an isolated area ( Cave ) for the
development of activities and sessions that require greater concentration or
isolation.

For geographically distributed teams, virtual environments,

videoconferencing, teleconferencing and similar tools can be used. There are
at least two techniques indicated by the Book for these cases:

 Fishbowl window : is the availability of a permanent

videoconference link, present in the distributed locations to allow
the teams to communicate spontaneously in real time;
 Remote pairing : use of virtual conference tools, which share
screen content, in addition to voice and video.
4.3.7 Overcoming Organizational Silos

Project teams are often made up of members whose direct managers

designated by the organization do not necessarily work for the project. In
these scenarios, organizational silos are often identified. It is usually
difficult to obtain the exclusive dedication of project resources to a given
team.

Recommendations for dealing with organizational silos are:

 Build a safe and trusting environment for the team, where

everyone can be heard and respected, based on
the Agile mindset ;
 Working in partnership with direct managers, so that they enable
the maximum dedication of people to the project teams.

The dedication of the team members, as well as the multifunctionality

aspect of the members, are the two initial focus items in building successful
Agile teams.

5. Implementing Agile: Deliveries in the Agile

environment

5.1 Charter and the Agile Team

Every project needs a Charter, which is the official source from which the
delivery team can understand the project objectives. But for Agile teams this
may not be enough as they also need to understand how they will work
together.

In an Agile project, the team needs:

1. Understand the purpose/vision of the project;

2. Be supported by an agreement on how they will work together.
An Agile Charter should answer questions such as:

a) Vision of the project;

b) Who will benefit and how;

c) The definition of ready for the project;

d) How the team will work together, for example: Values,

Rhythm, Timebox Respect , Work in Progress Limits, Event Rules and
Coexistence Rules, among others.

This does not necessarily have to be a formal process if the team

understands well how they will work together.

5.2 Common Practices in Agile Approaches

5.2.1 Retrospectives

The Retrospective is an important practice of an Agile team, as it allows the

team to learn, improve and adapt the work process.

Some approaches establish Retrospective events at the end of each iteration,

however, PMI understands that it can occur at any time during the project,
not necessarily at the end of an iteration or when a major delivery is made.

Retrospective sessions should not have a blame-seeking atmosphere, but a

focus on improvement. They must have a facilitator to be productive.

Another important consideration is not to try to work on a long list of

improvement items all at the same time, but to prioritize so that actual
improvements are made without creating the frustration of having multiple
unfinished initiatives.
5.2.2 Backlog Preparation

The Product Backlog is an ordered list of all the work to be done, created in
story form, for a delivery team. It should contain enough detail to allow for
the first few deliveries, and it doesn't have to have all the stories created in
advance and in detail for the entire project.

The Product Owner is primarily responsible for this artifact and must also
provide a high-level long-term view ( Roadmap ) of the delivery
sequence. The Backlog is an artifact that is constantly updated, as the team
learns more about the product over time.

5.2.3 Backlog refinement

In iterative approaches, the Product Owner often works with the delivery
team to refine, prepare, and estimate stories that will be worked on in future
iterations. This is ongoing work, and involves:

 Just-in-time refinement for stream-based approaches;

 Several iterative approaches use timebox events (1h for a 2-week
iteration) to perform the refinement;
 Several refinement discussions, as deemed necessary.

It is understood that this work is the primary responsibility of the Product

Owner, and may be supported by the development team, which should
dedicate no more than 1 hour a week to this work, otherwise this is an
indication that the Product Owner is investing more time than necessary to
carry out the preparation, and the team must not lose focus on delivering
the product.

5.2.4 Daily Standups

These are daily meetings lasting up to 15 minutes, in which team members
commit to each other at the lowest level of delivery, reveal problems,
impediments and use them as an instrument for a continuous flow of work.

In iterative approaches, the following questions are typically commented on

by each team member with ongoing activity:

 What have I concluded since the last Standup ?

 What do I intend to conclude from now until the next Standup ?
 What are my impediments, risks or problems?

In flow-based approaches, typical queries are done with the Kanban / Tasks
board, looking at it from right to left:

 What is needed to advance that particular job?

 Is someone working on something that's not on the board?
 What do we need to finish as a team?
 Are there any bottlenecks or blockers impacting the workflow?

This excerpt from the Book also brings some examples of bad practices that
should be avoided:

 Make Standup a status meeting;

 Trying to solve problems during Standup , when you should just
list them.

5.2.5 Demonstrations / Revisions

Such sessions are led by the development team, which performs the
demonstration of the increment produced to the Product Owner, who must
evaluate, approve or not the deliveries. Other stakeholders may also
participate to gain familiarity with the increment and contribute feedback .
In iterative approaches, these sessions occur at the end of each iteration. As
for flow-based approaches, the team must define when they occur. A good
practice is to perform every 2 weeks.

5.2.6 Planning in Iterative Agile Approaches

The combination of organization, team, project and product always results

in a unique environment, and this fact must always be taken into account in
planning.

Planning must consider a realistic view of the team in relation to its capacity
and this includes periods of oscillation such as vacations.

Agile plans are not “set in stone” commitments, but should reflect the best
judgment made by the core team and the level of knowledge available at the
time of planning. They are also not unique events in the initial phase of the
project. Instead, several planning rounds are carried out and learning over
time feeds back into future planning rounds, making it a cyclical and
evolutionary process.

5.2.7 Practices that help the Team Deliver Value

Quality in construction must be something non-negotiable and treated as a

prerequisite, otherwise there is no way to carry out frequent deliveries.

Within the scope of software development projects , the following practices

from the eXtreme Programming (XP) model help teams deliver with quality
and speed:

 Continuous Integration ;
 Testing at all levels, with an emphasis on automated testing;
 ATDD ( Acceptance Test-Driven Development );
 TDD ( Test-Driven Development ) and BDD ( Behaviour-Driven
Development );
  Spikes ( experiment and research timebox events

5.2.8 How Iterations and Increments help deliver a Working

Product

Iterations help the team create a delivery cadence, they also help to
receive feedback on deliveries on a frequent basis, which also allows for
frequent adaptation.

5.3 Dealing with the Challenges of Agile Projects

The following challenges and possible ways to address them are mentioned
in the Publication.
Table of Challenges and Possible Solution Paths

5.4 Metrics in Agile Projects

Metrics in Agile projects are different from predictive projects. In predictive

projects, it is customary to monitor progress through a percentage of
completed activity, which often becomes a “surprise box” because in the
final stages of the project, problems with the integration of the parts
produced throughout the life cycle can be discovered. from the project. Such
projects are sometimes referred to as “watermelon” projects, as they have a
status of “green on the outside” but are “red on the inside”.
Agile metrics contain significant information, with an understanding and
evolutionary perspective, based on concrete and frequent deliveries
(product working with value to the business). This information can still be
used to improve future projections and also be used in decision making.

In addition to quantitative metrics, Agile teams often consider qualitative

measurements, such as user/business satisfaction using the product, team
engagement, and others.

5.4.1 Agile Teams Measure Results

The big point is that Agile teams measure what the team delivers, not what
the team predicts will be delivered. In an Agile environment, if there is little
variation in the work assigned to the team and if the team members avoid
multitasking approach, then their deliverability ends up becoming more
stable and predictable. This means that in Agile approaches, there is
recognition that projects involving learning can and should be estimated,
but their accuracy is evolutionary, and even if it is evolutionary, it can
undergo changes in the various variables and work scenarios over time. This
is characteristic of empiricism.

Often Agile teams use the story points technique to perform estimations ,
through which their velocity can be calculated and projections can also be
made.

The Burndown chart is a tool normally used in Agile projects, taking the
story points as a basis for tracking finished work and remaining work.
Burndown chart example

In this example, there are about 37 story points on day 1 considered as

remaining work. Already on the 3rd, such a project began to present risks of
not being able to finalize all the points until the 10th.

Some teams prefer to use Burnup charts to track progress.

Burnup chart example

The Burnup chart demonstrates completed work. In this example, the data
is the same as in the previous Burndown chart .

Using Burndown or Burnup charts , teams are able to understand the

performance of concrete deliveries at the end of the iteration and print
adjustment actions in what they deem necessary. These adjustments can be
of different natures, from the granularity and detail of the user stories,
better calibrating the estimates vs. definition of done, adjustments in the
definition of done, as well as of course using it as a reference in planning the
next iterations, which tend to be more accurate.

The velocity of an Agile team is measured through the sum of story points
completed in an interaction, and through the monitoring of the velocity,
which the planning is also refined.

Flow-based agile teams use different measures, seeking to eliminate internal

or external bottlenecks:

 Lead time : total time since the item was added to the board
until its completion;
 Cycle time : effective working time to complete the item;
 Response time : time of the item in queue, waiting to be
processed.

The foundation of flow-based lifecycle measurements is on the Kanban

board.
Kanban board example

The use of Lead time is important to understand Cycle time , from a

perspective of final delivery to the customer. Limiting Work in Progress
( WIP ) helps the team visualize when new work can be started in a given
phase, and, if there is a bottleneck, the team as a whole ends up prioritizing
the elimination of the bottleneck to allow continuous flow of delivery.

In this approach, each feature and each team is seen as unique, and
precisely because of this, teams end up not being able to compare their
performance with that of other teams or projects.

Burndown and Burnup charts (capacity measure), combined with Lead

time and Cycle time (predictive measure) are very useful during project
execution and guide the teams, allowing them to understand whether or not
they will be able to finish the work within the initially estimated time frame.

Another possible type of measurement in Agile projects is the so-called

' Functional Burndown/Burnup ', which demonstrates the fluctuation of
requirements throughout the project, helping to understand how changes in
scope influence the vision of speed.

Example Functionality Burndown/Burnup chart

The Added Value in Agile projects is measured from ready-to-use

functionalities. The chart below shows completed work compared to
expected work on a Feature Set , over a range of iterations or milestones .
Product Burnup chart example

This chart helps you visualize that 'FS 2', or Feature Set 2, has increased in
the timeline.

Another way to measure the Earned Value is through the graph below,
which combines the Scope and Cost on the timeline, showing several
indicators such as Earned Value, Planned Value, Projected Cost, Actual
Cost, Cost Variation and Schedule Variation.
Exemplo de medição de Valor Agregado no contexto Ágil

As medidas tradicionais de Gestão de Valor Agregado (sigla EVM em inglês)

podem ser realizadas facilmente para o contexto Ágil:

SPI (Schedule Performance Index):

 Pontos de história planejados na iteração: 30

 Pontos de história concluídos na iteração: 25
 SPI = 25 / 30 → 83%

CPI (Cost Performance Index):

 Valor Agregado conforme o exemplo, são as Funcionalidades

completadas: $ 2,2Mi
 Custo real conforme o exemplo: $ 2,9Mi
  CPI = 2,2 / 2,9 → 0,79 centavos de dólar agregado para cada 1
dólar gasto.

Outra medição valiosa em projetos Ágeis vem dos Diagramas de Fluxo

Acumulativos, que podem revelar gargalos e acúmulos e Trabalho em
Progresso, o que é nocivo aos times de desenvolvimento. Muito Trabalho em
Progresso diminui a capacidade de realizar entregas completas.

Exemplo de um Diagrama de Fluxo Acumulativo

6. Considerações Organizacionais para Agilidade em

Projetos

Cada projeto existe em um contexto organizacional. Cultura, estrutura e

políticas influenciam a forma como um projeto se dá em todo seu ciclo de
vida. Os projetos Ágeis podem ter um maior sucesso se as organizações
puderem se ajustar para suportar tais abordagens.
6.1 Gestão de Mudança Organizacional

PMI has a comprehensive Guide to Organizational Change Management,

which is not specific to the Agile environment, but does offer valuable
recommendations such as the ones below, which are also recommended in
the context of the Agile Practice Guide .

 Descriptive models of dynamics in changes;

 Frameworks for achieving change, and;
 Change Management Practices in Projects, Programs and/or
Portfolios.

6.1.1 Drivers for Organizational Change

PMI understands that there are 2 main factors that drive aspects of Change
Management in organizations that embark on the adoption of Agile
practices :

 Changes associated with faster deliveries : Organizations

may not be prepared to receive faster and more frequent
deliveries. This alignment with those who receive project
deliveries should be treated with importance.
 Changes associated with Agile approaches : the Agile way
of working brings the concept of fail fast , which can be
misunderstood by those who are not used to such
approaches. Change Management techniques must be adopted for
this scenario.

6.1.2 Preparing for Change

The Publication brings a vision from 3 angles in relation to the preparation

and readiness to receive the changes of Agile approaches in organizations:
First , organizations with the following characteristics make change
easier :

 Executive layer desire for change;

 Desire for the organization to change the way it assesses employee
performance;
 Ability to centralize or decentralize Project, Program and Portfolio
Management;
 Focus on budget and short-term metrics, rather than long-term
vision;
 Maturity in talent management.

Second , characteristics that make change difficult :

 Structures in silos;
 Purchasing strategy prioritizing price and the short term, rather
than a long-term vision of building competencies;
 Culture of recognizing leaders for specific optimizations instead of
a broader view (thinking of the whole);
 Highly specialized employees without the incentive to become
more generalist and flexible;
 Used to multitasking and distributing employees on multiple
projects at the same time.

Third , project leaders can try the following approaches to accelerate

change adoption :

 Visible and active support from sponsors;

 Change Management practices, including coaching ;
 Adopt a “slow and steady” approach, project by project, scaling up
progressively;
 Introduce Agile concepts incrementally to teams;
 Lead by example, using Agile practices.
6.2 Organizational Culture

Organizational culture is the DNA of organizations, their identity. Any

strategy will be executed by people who are closely linked to the
organizational culture. If this aspect is neglected or mismanaged in a change
process, the chances of success are low.

6.2.1 Creating a Security Environment

The first and most important aspect in any organizational change initiative
is to create an environment of security, honesty and transparency for
people, being important the easy perception of these characteristics in the
leaders of the organization in the process of change.

6.2.2 Assessing the Culture

The different organizational cultures existing in the market must be

recognized. There are, for example, companies with a greater inclination
towards execution speed, while others strive for excellence even if that
means a longer execution time. The list, of the most diverse cultural
characteristics, is long and it must be understood in each context.

PMI recommends, for the Agile context, that an assessment of the culture be
carried out, through a structured technique (there are several), that make it
very clear how close or far a certain organization is from the Agile values
and principles. And then, from that understanding, structure the change
plan.

6.3 Forms of Hiring and Contracts

Ideally, an Agile hiring model should have a win-win

mechanism, PMI mentions the following models as adherents (I left the
terms in English):
 Multi-tiered structure : structure with Master Service
Agreement giving general guidelines, using the concept
of Statement of Work to formalize the objective scope of hiring,
gaining agility in hiring;
 Emphasize value delivered : instead of linking payments for
intermediate achievements, associate it with the delivery of value
to the business, which can be incremental;
 Fixed-price increment : hires by iterations or by story points,
with a short-term horizon and incremental nature;
 Not-to-exceed Time & Materials : it is an hourly allocation
model with a ceiling limit, priority is given to adjusting the scope
in relation to the contracted nominal effort, however, an increase
in hours on demand is allowed;
 Graduated Time & Materials : it is a model based on a
progressive rate table, which establishes a higher rate for early
deliveries and a lower rate when delivery takes longer than
estimated ;
 Early cancellation option : establishes a limit of financial
exposure to the contracting party who, if it reaches the objectives
in advance, pays a limited fine, does not commit to the total
estimated value and allows the contracted team to be de-allocated,
which will be rewarded with the amount of the fine ;
 Dynamic scope option : fixed capacity model, where only the
scope varies and not the contracted amount;
 Team augmentation : it is the most collaborative form of
hiring, inserting the contractor as an integral part of the
contracting organization. The teams are financed, without
establishing scope in the contract ;
 Favor full-service suppliers : refers to the application of a
contracting strategy with multiple partners to mitigate risks. In
this model, partners should be avoided in silos, prioritizing scopes
that deliver value to the business, rather than processing a part of
the value cycle.
6.4 Business Practices

The values and principles applied by Agile teams often create challenges and
conflicts with traditional business practices used in areas such as Finance,
Human Resources and others.

In this section, the Publication advises not to expect radical and rapid
changes from organizations. Teams must work to create competencies in
organizations (in a progressive way), leading with transparency and
collaboration, so that business practices are adjusted, and thus allow better
performance of Agile teams.

6.5 Coordination of Multiple Teams and Dependencies (Scaling)

Many projects deal with dependencies, and for that it is important to know
how Agile practices work with this issue.

6.5.1 Work Models ( Frameworks )

PMI understands that Scrum and XP are frameworks that work well in non-
scaled environments, that is, one or a few teams.

On the other hand, it mentions some scaled models such

as SAFe , LeSS and DA and the Scrum of Scrums approach , as ways of
working in an Agile way in environments with many teams for the same
product.

Note to self: I include the Nexus framework in the list as well.

6.5.2 Considerations

There are several ways to scale an Agile environment. More important than
the form or framework of scaling is how well teams are already working on
the Agile model even before scaling. If, even before scaling, teams are not
being successful, it is better to identify and improve current practices
beforehand, otherwise the result will be to grow the size of the problem.

6.6 Agility and the PMO (Project Management Office)

The PMO exists in an organization to ensure the business value obtained by

the projects. This involves helping projects achieve business objectives,
supporting the company in selecting projects that maximize value, and
related activities.

The Agile approach changes the culture and way of looking at projects, and
the PMO's performance also changes in this scenario.

6.6.1 An Agile PMO is Value Focused

The actions and tools of an Agile PMO must be adjusted according to the
business value and the individual issues of each project. Some projects may
need tools, others coaching , or other support. It is important for the PMO
to be clear about how its actions will maximize the value brought by a
project.

6.6.2 An Agile PMO is Invitation-Oriented

The central point of this section is: if the PMO's performance is bringing
value to the teams, it will be invited to act and provide the services of its
portfolio. Your role should not be to ensure that all teams work in the same
way, as this does not mean that your role is addressing a project need.

6.6.3 An Agile PMO is Multidisciplinary

In an Agile environment, a PMO must have multidisciplinary

characteristics. There are already some organizations that have turned PMO
areas into Agile centers of excellence , which typically provide in-house
services such as:
  Development and Implementation of standards and tools;
 Team skills development through training and mentoring ;
 Multi-project management, which aims to share learning,
practices and work at a portfolio level;
 Facilitates organizational learning;
 Stakeholder management ;
 Recruitment, selection and evaluation of team leaders;
 Perform specialized or facilitation tasks on projects.

6.7 Organizational Structure

There are a number of characteristics that influence the speed at which

organizations adapt:

 Geography : the geographic distribution of teams directly

influences the complexity of how such teams will work
together. Aspects such as language, time zone differences, cultural
differences and other points end up being of great
importance. Fortunately, Agile practices encourage close
collaboration, which means techniques and tools to mitigate these
challenges are employed;
 Functional structures: structures in silos are not indicated for
environments that require great collaboration;
 Size of increments / delivery : with smaller and more
frequent deliveries, the amount of handoffs from one team to
another increases, and organizations must prepare for this reality;
 Allocation of people in projects : always prioritize full-time
allocation, even if it is for short periods, so that there is a
maximization of the delivery flow;
 Organizations with heavy Purchasing processes : there are
organizations that prioritize the execution of projects through
partners and not with internal teams. This approach makes it
difficult to internalize the knowledge and evolution of the teams,
 because once the project is closed, the partner teams are
demobilized and with them the acquired knowledge goes, in
addition to blocking the long-term accumulated learning.

6.8 Evolving Organizations

The journey of adopting Agile practices must be done incrementally, already

using the techniques during adoption, such as experimentation, iterations,
etc. The use of Kanban boards to follow the evolution is also indicated to
already allow transparency and quick adaptation to increase the chances of
success in the journey.

7. Call to action

In this section the authors recognize interesting questions:

1- The demand for Agile adoption has never been as great as it is today,
regardless of the type and size of organization, and not only applied to
technology projects. For an organization that built much of its history with
traditional methods, this is an interesting position;

2- They understand that this publication is a Guide that can be improved

and that perhaps it was not deep enough. It's a way of acknowledging that
there isn't a single answer, a single way of doing things, and that agile
practices will continue to evolve.

Pmi Acp

Pmi Acp Certification

PMI Acp Exam

Pmi Acp Training

Agile

6
More from Guilherme P. de Carvalho
Follow

May 23, 2019

My Captsone Project: Launching Teahouse stores in Australia

data science

13 min read
 Love podcasts or audiobooks? Learn on the go with our new app.
Try Knowable

About Help Terms Privacy

Get the Medium app