Chapter 6 Agile Project

Management
6.1 Agility
 Agility is the capability to efficiently and effectively adapt to an ever changing
environment.
 Agility can be defined at different levels: personal, departmental or organizational.
 Note that it is not possible to implement agility directly. Agility is a property of a
system that is present to some varying extent, depending on how the system
operates.
 One can identify three drivers which will cause a system to become more agile:
flow, learning and collaboration.
o Flow refers to the way work is processed by the system. If the processing of work
occurs at a steady and sustainable rate, the system has a high level of flow. Such
state of high flow is often accompanied by a feeling that work becomes easy and
routine takes over. Some people refer to this state as “being in the zone”.
o Learning refers to mechanisms in the system which allow the system to learn from
past experiences, mistakes or other people, but also to uncover unknown
unknowns (knowledge discovery).
o Collaboration refers to various ways how people in the system can work together
to achieve a single goal. Different forms of collaboration can be distinguished:
 Helping. One person decides to help another person finish his or her job. This way
of collaboration is useful when you have nothing else to do. In this approach, the
person who helps takes the initiative to collaborate. Most likely this person will
not be as productive as the person he or she is helping due to lack of experience
in the task at hand.
 Apprenticing. A specialist involves another person in his or her job, so this person
can help but also becomes more experienced. In this approach, the expert takes
the initiative for collaboration. This approach is useful to prevent specialists to
become bottlenecks in the process.
 Synchronizing. This is a form of pre-emptive collaboration. The idea is to never
start a task that one cannot complete without the help of another person unless
we are certain that this other person will be available. Synchronizing implies that
one synchronizes with the key resources to make sure they will be available when
necessary.
 Swarming. When faced with a very critical or highly uncertain task, swarming
could be a useful collaboration approach. The idea is for the team to get together
and discuss the task in order to decide on a plan of action and then spread out for
a limited amount of time (e.g. 30 minutes) to each work on a part of the task
individually. Next, they come back together to discuss the progress and
synchronize with each other, before they scatter again to continue working. They
repeat this process until the work is done.
 Integrating. Often a task will require different people to do parts of it. If the task is
moving a lot from one person to another person, the integrating approach would
imply to work together on it. The idea behind this collaboration technique is that
moving work from one person to another implies a transaction cost (waiting time
because both people need to be available, time required to bring the other person
up to speed, errors due to miscommunication, …). By integrating the work, these
transaction costs can be eliminated.
 Pairing & Mobbing. Pairing and mobbing are two techniques where either two
people (pairing) or an entire team (mobbing) work together on a single task. While
one person takes the lead (e.g. controls the keyboard), the rest observes, asks
questions, makes suggestions, … . Often the role of leading the collaboration is
passed around from team member to team member at a fixed time interval.

6.2 Impact of agility drivers on work efficiency

6.2.1 How work works

 While agility refers to the capabilities of a system to adapt to a changing
environment, it is important to realize that the drivers behind agility also influence
the work efficiency of a system.
 Efficiency of work can be expressed in two different ways:
o Resource Utilization. This is the perspective often used by management and refers
to the percentage of available time that a resource is is actually working. A
resource utilization rate of 0.8 implies that a resource is only working 80 percent
of the time that he/she is available. Sometimes this is also called chargeability,
which refers to the percentage of working time (or the corresponding cost) of a
resource that can be charged to the customer.
o Flow Efficiency. This is the reciprocal of the average lead time. Thus as the lead
time (time between arrival of a job and completion of the job) goes up, the flow
efficiency goes down. The more waiting time occurs during the execution of a job,
the higher the lead time and thus the lower the flow efficiency. This perspective is
often taken by the customer and is strongly connected to the concept of ‘flow’.
 To understand how work works, we must be aware of four reinforcing loops.
o Loop 1: Whenever we start work, we create work in progress. A certain percentage
of this work in progress will get blocked due to unforeseen circumstances, missing
knowledge or waiting for external input. When work gets blocked, it will make
workers idle, which will lower resource utilization. This is typically compensated
by starting new work. However, as more work gets started, the WIP will further
increase, creating a reinforcing loop.
o Loop 2: As mentioned before, a certain amount of work in progress will result in
blocked work. To unblock this work, we need to perform unblocking work which is
non value adding. The fact that resources must spend their time on non-value
adding work, decreases the time they have to finish work. This results again in a
reinforcing loop. The less work is finished, the more work remains in progress,
which increases the likelihood of blocked work, which increases the amount of
non value added work, which furthermore decreases the amount of finished work
and thus the loop continues.
o Loop 3: As the average work in progress increases, the average lead time will also
increase assuming a steady-state process where the average processing rate
remains constant. This follows directly from Little’s Law which states that the
average lead time equals the average work in progress divided by the average
processing time. As the lead time increases, the flow efficiency will go down. But
at the same time, the amount of urgent work will go up. Urgent work is defined as
work that must be started immediately and should get priority in order to meet the
deadline. However, more urgent work thus implies more work that should get
started and the work in progress will again increase, resulting in a third
reinforcing loop.
o Loop 4: Increasing lead times also imply that the time between the moment a
client requests a job to be done and the moment we can deliver the output to the
client increases. The more time passes between these two moments, the longer
we must wait for feedback from our customer. In a non-stable environment, such
feedback delays increases the likelihood that the deliverable is not completely as
the customer desires, resulting in necessary non value adding work. As known
from loop 2, non value adding work decreases the rate at which we can finish
work, which increases the work in progress, which will have a detrimental effect
on the lead time, further increasing the feedback delay, resulting in a fourth
reinforcing loop.
 Note that each of the four loops have the effect to increase the work in progress,
which according to Little’s Law has a negative effect on flow efficiency. However,
unless an organization considers flow efficiency important, this is not necessarily
a problem. After all, we can always keep resource utilization high by starting new
work. The perverse effect however is that this approach will decrease flow
efficiency even further.

6.2.2 Agility drivers and work efficiency

 Flow as a driver implies that one keeps the rate at which work is processed steady
at a sustainable rate. One common way to implement this to set a limit on the
work in progress. Thus, whenever a worker becomes idle and the WIP has reached
its limit, the worker can no longer start new work, thus breaking the first
reinforcing loop.
 Collaboration as a driver can be used as an alternative approach to keep the
resource utilization rate high whenever workers become idle due to blocked work.
Instead of starting new work, they can decide to help other colleagues complete
their work or to unblock blocked work items. Helping colleagues to complete their
work will increase the rate at which work can be finished, which lowers the work
in progress. This approach lowers the negative effect of the second loop on work
in progress.
 Learning as a driver should counteract potential feedback delay. If the system
incorporates sufficient points where we can learn (e.g. from the customer or
environment), the delays in feedback will be smaller again, which will result in
less non value adding work, which again has a positive effect on the work in
progress by breaking the fourth reinforcing loop.
 Note that all three drivers ultimately have a positive effect on the work in
progress, trying to break the reinforcing loops. As a consequence, this approach
allows one to both increase the flow efficiency as well as the resource utilization.

6.3 Agile Project Management Methods

6.3.1 Origin
 Agile Project Management finds its origins mainly within the field of software
development.
 Traditionally, software development methodologies followed a waterfall approach
which resembles traditional project management methods in nature, with a strong
focus on processes, predictability and risk control, assuming a stable
environment.
 In response to such heavyweight software development methods, various
lightweight methods were introduced in the 1990s, such as Scrum, Extreme
Programming and Rapid Application Development.
 While such lightweight methods were introduced before the Agile Manifesto, the
latter is often considered the start of the Agile movement.
 The Agile Manifesto was written in 2001 by 17 software developers who came
together to discuss the lightweight development methods. Together they published
the Manifesto for Agile Software Development.
 Fundamentally, agile approaches (of both project management and software
development) differ from traditional approaches in the sense that they are
adaptive rather than predictive and integrative rather than waterfall.
o Adaptive vs predictive. In a predictive approach the focus is on analysing and
planning the future in detail, preparing for potential risks. The idea is that if one
can predict the future, one can plan for it. In an adaptive approach it is assumed
that the environment changes fast, often and in unpredictable ways. The focus of
adaptive approaches is not to plan everything ahead of time but to leave flexibility
to respond to a changing environment. Flexibility to address changes and the
ability to detect these changes are key elements in an adaptive approach.
o In a waterfall approach, planning, execution, testing and delivery are clearly
separated in sequential steps. In an integrative (also called agile) approach, these
steps are integrated in one phase, which is typically iterated multiple times. These
iterations are also incremental by nature, which means that each iteration builds
upon the output of the previous iteration enhancing it further towards the end
deliverable.

6.3.2 The Agile Manifesto

 The agile manifesto identifies four core values:
o Individuals and interactions over processes and tools. While tools and processes
are important, it is even more important to have competent people working
together effectively.
o Working software over comprehensive documentation. While good documentation
is useful, the main point of development is to create software not documentation.
o Customer collaboration over contract negotiation. While a contract is important, it
is no substitute for working closely with customers to discover what they need.
o Responding to change over following plan. While a project plan is important, it
should not hinder to accommodate to changes.
 The agile manifesto also identified twelve principles:
o Customer satisfaction by early and continuous delivery of valuable software.
o Welcome changing requirements, even in late development.
o Deliver working software frequently (weeks rather than months).
o Close, daily cooperation between business people and developers.
o Projects are built around motivated individuals, who should be trusted.
o Face-to-face conversation is the best form of communication (co-location).
o Working software is the primary measure of progress.
o Sustainable development, able to maintain a constant pace.
o Continuous attention to technical excellence and good design.
o Simplicity - the art of maximizing the amount of work not done - is essential.
o Best architectures, requirements, and designs emerge from self-organizing teams.
o Regularly, the team reflects on how to become more effective, and adjusts
accordingly.
 While the agile manifesto was written with software development in mind, many of
its ideas can be transferred to projects in general, giving rise to idea of agile
project management. Some core principles that return in agile project
management are:
o Iterative, incremental and evolutionary development.
o Efficient and face-to-face communication.
o Very short feedback loops and adaptation cycles.
o Focus on quality.

6.3.3 Scrum
 The origin of Scrum goes back to the work of Hirotaka Takeuchi and Ikujiro
Nonaka, who developed a new approach for product development based on cross-
functional teams.
 The Scrum framework as agile software development approach was developed by
Ken Schwaber and Jeff Sutherland.
 For a good overview of Scrum as Agile Project Methodology, we refer to The
Scrum Guide
 Some key takeaways are:
o Scrum defines three key roles: a product owner, a team member and a scrum
master.
o Scrum assumes that the work is done by a single self-organizing cross-functional
team which contains a diverse set of skills required to perform the work.
o The role of a product owner emphasizes the need to continuously evaluate the
needs of the customers.
o Scrum defines five key events: a sprint, the sprint planning, the daily scrum, a
sprint review and a sprint retrospective
o The sprint represents a single iteration which is timeboxed (fixed amount of time).
If one considers the work assigned to a single sprint as 1 work-item, one could
state that Scrum uses a WIP-limit of 1.
o Scrum defines three main artefacts: a product backlog, a sprint backlog and an
increment.
o The increment is the potentially releasable output of the sprint. Scrum assumes an
incremental approach. Therefore, the increment refers to the work done in a
specific sprint integrated with the work of all previous sprints. At the end of each
sprint, the end deliverable has received an update which moves it closer to the
end goal.
o Scrum mainly focusses on the collaboration and learning drivers of agility.

6.3.4 Kanban
 The Kanban method goes back to a lean manufacturing method which was
inspired by the Toyata Production System. Its key idea are to visualize work items
to give participants a view of progress and to allow work to be pulled rather than
be pushed.
 Over time, Kanban and Kanban boards in particular found their way to software
development projects.
 Today, Kanban is used in all different kind of contexts outside software
development.
 For a good overview of Kanban, we refer to Essential Kanban Condensed
 Some key takeaways are:
o Kanban focusses on the visualization of work (by means of a Kanban board).
o Kanban limits work in progress (WIP). It does so by defining a commitment point
and a delivery point in the process. The commitment point is where the team and
the customer commit to the work being done, whereas the delivery point is where
the customer commits to accept the output.
o Kanban advises to make work (and kanban) policies explicit.
o Kanban focusses on managing the flow at a steady and sustainable rate.
o Kanban implements feedback loops.
o Kanban assumes collaborative improvements.
 Kanban focusses mainly on the flow driver of agility.
 Typically, Kanban is not only applicable to projects, but also to operations. As a
project method it is often combined with other method to give sufficient guidance
for project management.

Agile Teams

An Agile Team is a cross-functional group of typically ten or fewer individuals with all the skills
necessary to define, build, test, and deliver value to their customer. Agile Teams may be technical
teams focused on building digitally-enabled solutions, business teams delivering business functions,
or, increasingly, elements of both. By quickly delivering work in small increments, all Agile Teams
strive for fast learning, gaining fast customer feedback, assessing the results, and adjusting
accordingly.
Details

Agile teams are self-organizing and self-managing and are accountable for delivering results that
meet the needs and expectations of their customers and stakeholders.

Agile Teams power the Agile Release Train (ART) and thereby, the entire development portfolio.
Agile teams collaborate with other teams to deliver ART solutions.

They contribute to the Vision and Roadmap, and participate in ART events. In addition, teams build
the Continuous Delivery Pipeline (CDP) that accelerates the flow of value and supports the ability to
Release on Demand.

Agile teams are cross-functional, long-lived, and organized to deliver value as easily as possible. By
building longer-lived teams and trains, enterprises can eliminate the start-stop-start ‘project’ way of
working (see Lean Budgets) and eliminate waste and delays in the process.

Agile Teams Lean-Agile Leaders provide the vision, guidance, and autonomy necessary to foster
and promote high-performing Agile teams. As a result, assigning work to individual team members is
no longer required. Teams become self-directed and self-reliant, have more autonomy, further
enabling decentralized decision-making all the way to the individual contributor. Agile teams are
more productive than groups of similar individuals, are more engaged in their work, and have more
fun on the job.

Characteristics of Agile Teams

Agile teams share certain defining characteristics, as described in the following sections.

Teams Constitute the ART

Most Agile Teams are a part of an Agile Release Train and deliver value together with other teams
that operate within the context of a common solution mission. They synchronize frequently with other
teams, stakeholders, and their management. Some Agile teams—for example, business teams,
enabler teams that support multiple ARTs, independent research teams, LACE teams, etc.— can
deliver value independently of an ART, but they still benefit from their Agile method in establishing
the flow of customer value.

Agile Teams are Cross-functional Agile teams are composed of members dedicated full-time to their
teams and contain all the functions they need to deliver value (Figure 1). This avoids individuals
multiplexing across teams and eliminates the handoffs and delays that occur when pushing value
across functional silos. Most generally, Agile Teams are capable, enabled, and able to:

Define Elaborate and design the features and stories needed to deliver customer value

Build – Contain all skills necessary to create the elements of the solution

Test – Ensure quality and performance of the new functionality

Deploy – Deploy increments of value to their customer

Agile Teams are Organized Around Value guides enterprises to organize people and teams around
one goal: the continuous delivery of value to the customer. But to do so, they must consider how
best to design their Agile Teams.

four primary ways to organize Agile Teams

Stream-aligned teams are end customer-aligned and are capable of performing all the steps
needed to build end-to-end customer value

Complicated subsystem teams are organized around critical solution subsystems. They focus on
areas of high technical specialization, which limits the cognitive load on all the teams

Platform teams provide application services and APIs for stream-aligned teams to be able to
leverage common platform services

Enabling teams provides tools, services, and short-term expertise to other teams

High-Performing Great teams require more than talented individuals. Team composition and dynamics play a
significant role. In fact, who is on a team has less impact on performance than how the team works together. High-
performing teams share many ‘teaming’ characteristics:

Alignment on a shared vision with clear goals and purpose

A safe environment for taking risks without fear of embarrassment or criticism

Diversity of knowledge and skills to independently make quick, effective decisions

Mutual trust that allows for both healthy conflict and reliance on others

Accountability to each other and the organization for reliably completing quality work Meeting commitments
Understanding their work’s broader impact on the organization

Having fun with their work and with each other

SAFe’s Organizational Agility competency provides more information on how Lean-thinking people and high-
performing Agile Teams work to create better business outcomes.

Enabled by Critical Roles

Agile Teams are further enabled by two specialty.

The Product Owner contributes to the Vision and roadmap and works with the team to define Stories
and prioritize the team’s work. By working with the customer and the teams, they define a backlog
that addresses customer needs and also helps maintain the technical integrity of the product.

 Connect with customer

 Contributing the vision to the road map
 Managing and prioritizing the team backlog
 Supporting the team in delivering value
 Getting and applying feedback
2. The Scrum Master / Team Coach (SM/TC) helps implement and maintain Agile practices,
optimizes and improves team performance, partners with the RTE to guide improvements of the
entire ART, and helps to optimize the flow of value.

 Facilitate planning
 Supporting iteration execution
 Improving flow
 Building high performance teams
 Improving ART teams

Connecting with customer:

Agile Teams are responsible for understanding customer needs and defining the functionality needed to satisfy them.
In order to develop a thorough understanding of the customer context, they apply Customer Centricity. To understand
the problem and design the right solution, they apply Design Thinking. Doing so requires that all Agile teams:

Build empathy with the customer – To build a great product for the customer, the team needs to think like the
customer. However, often due to multiple degrees of separation from the customer, teams may struggle to
understand actual customer needs and what represents value to them. Thus, increasing a team’s exposure to the
customer context is essential. There are many ways to do that, including:
Leveraging the Product Owners’ skills, knowledge, and responsibilities

Establishing direct communication with the customer

Participating in solution support

Direct observation of the customer in action

Implementing solution telemetry to monitor usage

Planning the work :

Planning allows teams to stay aligned with the rest of the train and progressively refine work within
a short timeframe. Planning involves all team members and relies on collaboration and
transparency. Effective planning facilitates alignment to a common goal while leveraging the
flexibility and autonomy of each team member in achieving their objectives. Planning occurs at two
levels:

ART Planning – PI Planning is the event where each Agile Team gains alignment with the rest of the
train and creates their backlog for the upcoming PI. PI Planning provides the larger, system view that
is necessary to achieve a shared goal. As a result of PI Planning, the team creates a set of PI
Objectives and a story-level outline of the planned progression of their work across iterations. This
seeds the Team Backlog for the upcoming PI.

Team planning – Once ART alignment has been established, teams perform shorter-term planning
on a regular basis during the PI. The purpose of this planning is to leverage new learnings and plan
the next short increment of value. The planning approach differs depending on whether a team
applies SAFe Scrum or SAFe Team Kanban.

Refining the Team Backlog – As knowledge emerges, teams continuously refresh and refine their
backlog. The backlog is used to identify and prioritize the upcoming work they need to do to deliver
their committed value.
Delivering Value :

Frequently integrate and test – A fast rhythm of development requires frequent integration and testing. This helps
uncover technology and implementation problems early and gives the teams enough time to respond to the findings.

Regularly synchronize with the rest of the train – While executing the PI, a team has multiple
checkpoints with the rest of the train. This can take place in the form of an ART Sync that includes
Coaches Sync and PO Sync. These events create visibility into the progress toward current PI
objectives and help the ART make timely adjustments.

Build the continuous delivery pipeline – An effective Agile development process also depends on
a continuous delivery pipeline that has mechanisms for Continuous Exploration, Continuous
Integration, and Continuous Deployment. This typically requires value stream mapping to identify
sources of delay and excessive variability.

Release frequently – Some teams are able to release directly to the customer. These teams may—
typically in collaboration with some specialized teams or Shared Services—establish their own
release process. Decisions on when to release value are typically made at different levels: major
releases may be decided upon during PI Planning; routine deployments are governed at the iteration
level. Others can even be event-driven.

Feedback :

The speed of solution development depends directly on the speed and fidelity of the feedback the team can obtain.
Without it, the team cannot adjust the course quickly. Errors start to accumulate, resulting in ineffective and delayed
solutions. Both customer and technology feedback is needed to move forward effectively.

Find pathways to the customer – In a large organization, the customer may be many degrees of
separation away from the Agile team that creates value. The Product Owner serves as a local
customer proxy and can be instrumental in helping the team establish the right connections to obtain
direct customer feedback. System Demos are one productive venue for customer feedback. Teams
should also seek feedback from ad hoc interactions with the customers who are using the solution in
their working environment.

Frequently validate technical concerns – A team must continually validate the assumptions
behind the solution architecture and the implementation strategy. Technology feedback comes from
frequent integration, testing, and deployment. Additionally, research spikes and prototypes help to
cost-effectively explore technical strategies.