Be Agile Do Agile

Be Agile Do Agile

Vittal S. Anantatmula and Timothy J. Kloppenborg

Be Agile Do Agile

Copyright © Business Expert Press, LLC, 2021.

Cover design by Charlene Kronstedt

Interior design by Exeter Premedia Services Private Ltd., Chennai, India

All rights reserved. No part of this publication may be reproduced,

stored in a retrieval system, or transmitted in any form or by any
means—electronic, mechanical, photocopy, recording, or any other
except for brief quotations, not to exceed 400 words, without the prior
permission of the publisher.

First published in 2021 by

Business Expert Press, LLC
222 East 46th Street, New York, NY 10017
www.businessexpertpress.com

ISBN-13: 978-1-95334-994-1 (paperback)

ISBN-13: 978-1-95334-995-8 (e-book)

Business Expert Press Portfolio and Project Management Collection

Collection ISSN: 2156-8189 (print)

Collection ISSN: 2156-8200 (electronic)

First edition: 2021

10 9 8 7 6 5 4 3 2 1
 This book is dedicated

Manga Anantatmula
Elizabeth Kloppenborg

for their invaluable support

 Description
The global economy and free market philosophy have resulted in higher
global c­ ompetition and increased expectations from customers. It is obvi-
ous that new ­approaches are needed to satisfy demands and many of them
fall under a broad u­ mbrella called agile. To capitalize fully on the benefits
of agile, one must first understand the concepts that underpin it.
In this book, we first identify many concepts that various approaches
advocate for agile and group them into three areas forming a simple,
robust system. Then, we describe the most useful agile methods in s­ avage
summaries regardless of the approach that promotes them, grouping
them logically and showing how to use them.
We have an agnostic agile model that can be useful to anyone using
any form of agile. Both concepts for being agile and techniques for
doing agile are summarized in this book and there are several ways to use
this book. To understand the concepts of agile, consult Chapters 3, 4,
and 5. Chapters 7, 8, and 9 will help you learn and perform agile tools
and techniques.

Keywords
agile; agile mindset; agile tools; agile metrics; agile manifesto; lean; scrum;
XP; SAFe; disciplined agile; project; project leadership; project success;
­project management; leadership; servant leadership; emergent leadership;
teamwork; roles
 Contents
Acknowledgments�����������������������������������������������������������������������������������xi

Chapter 1 Introduction ��������������������������������������������������������������������1

Part I Being Agile��������������������������������������������������������������������19

Chapter 2 Understanding the Agile Mindset�����������������������������������21
Chapter 3 Successful Outcomes������������������������������������������������������47
Chapter 4 Engaging Your Team: Leadership, Teamwork,
and Roles������������������������������������������������������������������������57
Chapter 5 Effective Communication and Collaboration�����������������77

Part II Doing Agile�������������������������������������������������������������������93

Chapter 6 Agile Methods (Doing Agile)������������������������������������������95
Chapter 7 Planning Adaptively�����������������������������������������������������113
Chapter 8 Creating Useful Solutions���������������������������������������������133
Chapter 9 Giving and Adapting to Feedback���������������������������������147
Chapter 10 Agile in a Nutshell��������������������������������������������������������167

Bibliography���������������������������������������������������������������������������������������177
Savage Summary Glossary�������������������������������������������������������������������183
About the Authors�������������������������������������������������������������������������������197
Index�������������������������������������������������������������������������������������������������199
 Acknowledgments
We would like to thank Frank Forte and Andy Burns who are both agile
gurus and have taught us a great deal. We would also like to thank our
four reviewers, Frank Forte, Kathryn Wells, Laurie Laning, and Marcie
Lensges, who each offered different perspectives and useful suggestions.
Finally, we would like to thank our editor Kam Jugdev who found more
ideas for improvement.
 CHAPTER 1

Introduction
Be Agile Do Agile

Creating
Engaging
Useful
Your Team
Solutions
Successful Planning
Outcomes Adaptively

Effective Giving and

Communication and Adapting to
Collaboration Feedback

With the onset of personal computers in 1980s and becoming popular

in 1990s, an urgent need to develop and implement software projects
became a norm and a requirement. However, for many software develop-
ers and those who sought software programs, it is an unknown territory
plagued with many unknowns and uncertainties. Neither the company
seeking those services nor the project team members who were attempt-
ing to deliver those projects knew what processes to adapt for delivering
requisite outcomes. Then, what persuaded organizations and software
developers to run into this fast-paced situation of developing projects?
The following issues are addressed briefly in this chapter and with
more details in the book.

1. Tell why organizations have turned to agile as a method of

planning and managing their projects
2. Briefly describe major differences between plan-driven (traditional)
and agile project management
3. Describe why agile is sometimes a more useful approach
4. Briefly define what be agile and do agile mean
2 Be Agile Do Agile

The answer is simple. Personal computers and their applications pre-

sented many opportunities to improve productivity and generated many
business opportunities to offer new products and services worldwide.
Computerization attracted every industry—manufacturing, production,
engineering, health care, research and development, service sector—and
the like, you name it! Everyone was eager to adapt this technology, and
you will find an enthusiastic customer for all these projects.
Further, the global economy and free market philosophy are com-
pelling drastic changes in global competition with corresponding higher
expectations from customers. These challenges and fluid situations
demand agility. Agility is the ability to move quickly and easily respond-
ing to changing customer desires. An agile approach is a necessity, not
an option. Obviously, this approach is necessary to manage projects, as
some of the traditional approaches, designed for stable work culture, may
not work. Creative and imaginative efforts of many led to the develop-
ment of new approaches. Many of these fall under a broad umbrella called
agile. Many projects in the current economy face a fluid situation and
­uncertainty that demands agility.
With so many players—customer organizations and software devel-
opment companies—involved in rapid development of new applications
and services, new inventions were emerging at a rapid pace. Obviously,
change was becoming a norm; requirements for many projects were
changing routinely. Some projects were canceling altogether, as their
intended outcomes were becoming obsolete even before the delivery, as
customers were redefining project objectives to catch up with competitors
and market demand. Business was moving at fast pace. Consequently, tra-
ditional project management methods were set aside, as they mismatched
the demands of these new projects. These projects were often referred
to as application development by crisis. These hazy circumstances led to
­thinking of agility in planning and executing projects.
Around the same time, with the advent of information technology
and its applications, business and customers alike were expecting prod-
ucts and services faster, better, and cheaper. Further, the information
technology sector facilitated this change in mindset by explosion of infor-
mation sharing and expansion of the market globally. A major change was
also occurring in the IT world—which is data management. Large subject
 Introduction 3

databases were being implemented to manage data as a corporate asset.

This meant that applications no longer had to create all their own data
and manage it. Applications could now tap into high-quality data sources
quickly. Therefore, the speed at which applications could be developed
increased dramatically. People and organizations liked this opportunity
and placed higher demands for quality products and services at an afford-
able rate. All these changes left no option for project managers but to
consider agility in project planning and execution.
Traditional project management methods and tools were developed
during the period prior to information age that was less chaotic. Project
management, as a formal discipline, began in early 1950s, and propo-
nents of the systemic approach developed traditional project manage-
ment methodology. After the agile approach is developed, this traditional
approach is often referred to as waterfall methodology and justifiably so. In
this traditional or waterfall method, a project usually transitions from one
phase to the next phase sequentially and usually after the previous phase
is completed. For example, one must understand all the requirements
that identify exclusions, inclusions, assumptions, specifications, and con-
straints associated with the project deliverable, and then the scope of a
project is defined. Without scope definition, project plan activities can-
not be initiated, and without developing a comprehensive project plan,
we cannot move forward to the project execution phase. This traditional
approach is systematic, logical, and makes sense when technology and
engineering associated with these projects have been steady and changes
are gradual. However, it is not true with information technology, which is
changing by leaps and bounds.
Specifically, software development projects are faced with rapid
and constant growth of technology and associated changes in customer
demands. Clients often do not know what they want in a new sys-
tem or product, and younger workers chafe at old command and con-
trol restrictions. At the best, a customer can explain the work process
and flow (context of the project) and the desired functional outcomes
expected from the project. In many cases, the software development
effort takes a trial-and-error approach to identify features and use qual-
ity tests to ensure customer satisfaction. The critical challenge is to
translate a need or requirement into a specification, which is not easy
4 Be Agile Do Agile

in this case. This is one of the main reasons why an agile approach
is justified. Other reasons for employing agile methods are ambigu-
ous and changing requirements of the project and compelling forces
of global economy to deliver products and services faster, better, and
cheaper.
In addition to the nature of changes to the projects and global econ-
omy, the U.S. government also permitted an iterative process of project
planning and execution in 1990s. An iterative process is a method to plan
the entire project at only a high level at the start and plan portions to be
done soon in detail, updating plans as more becomes known. This was
one of the main reasons why iterative project planning processes gained
popularity, and one can see the number of applications. The agile (aka
change-driven) methodology is a project method using iterative and
continual processes and is guided by agile mindset described in the Agile
Manifesto and elaborated by many sources. Agile found its a­ cceptance
among the project management professionals and in the corporate
world.
The first agile method that became popular was scrum in 1990s.
When developing new and complex products, the project team will be
informed of the project objectives, and the team will have autonomy of
actions to deliver these objectives. Subsequently, many other variations
of the agile approach have evolved. One of the main purposes of this
book is to identify concepts that various agile approaches advocate and
assemble them into simple, but a comprehensive system. It is our intent
to identify the most common and most useful agile mindset ideas and
methods regardless of the approach, group them logically, and explain
how to use them effectively.

When and Why Agile Should Be Used

One of the compelling reasons for the use of an agile method is the diffi-
culty associated with defining requirements of a project. A requirement “is
a condition or capability needed by a user to solve a problem or achieve
an objective that satisfies a standard, a specification, or any other for-
mally documented need” (Kloppenborg, Anantatmula and Wells 2018;
p. 212). Further, a requirement should unambiguous, complete, usable,
 Introduction 5

and verifiable. Requirement definition and conditions associated with it

cannot easily be defined in the case of a software or similar project where
the technology and customer needs are constantly evolving. This work
situation compels project managers and teams to reject traditional project
management and adopt agile methods.
A good example to illustrate the dynamic nature of projects is the
way many organizations are responding to the COVID-19 pandemic
situation and developing new online solutions for businesses that were
providing services at a facility previously. These solutions differ based on
the nature of the business, location of the business, and the government
restrictions imposed at that location. And, these changes are dynamic
and dictated by local, state, and federal governments. Many other orga-
nizations, governments, and other services are adapting their businesses
to these social changes. One can imagine the changing nature of require-
ments and incremental improvements of solutions of projects that are
aimed to provide solutions.

Plan-Driven (Traditional) Versus Agile

Project Management
Plan-driven (aka predictive, traditional, or waterfall) is an approach to
projects where the entire project is planned in detail early in the ­project,
and great effort is expended to control any changes. While all of those
terms are used somewhat interchangeably, for this book, we will use
the term plan-driven, as it is easy to understand the contrast with agile.
Both the plan-driven and agile projects are conceived to meet one or a
combination of the following reasons:

• Market demand
• Organizational need
• Customer request
• Technological advance
• Legal requirements
• Social need (specific for a nonprofit organization)
• Crisis situation
• Replacement or update of obsolete technology or equipment
6 Be Agile Do Agile

Table 1.1  Plan-driven versus agile philosophy

Plan-driven (traditional) Change-driven (agile)
•  Management as planning •  Management as organizing for planning
•  Dispatching model for executing •  Action perspective for execution
•  Thermostat model for control •  Scientific experimentation for control

While the reasons for initiating a project may find commonality,

management philosophy of the plan-driven method and agile method
differs (Table 1.1).
Plan-driven project management presents a transformation view of
production. Three theories of management are considered for plan-driven
project management (Koskela and Howell 2002), and they are: man-
agement as planning, dispatching model for execution, and thermostat
model for control. Project execution is based on a comprehensive project
plan, which is finalized to ensure that project execution is accomplished
strictly based on that plan. The plan also provides measures for prog-
ress and completion, and they are monitored constantly. This approach is
suitable when we have a fairly good understanding of the project scope,
and deliverables are specified accurately. In other words, uncertainties and
unknowns associated with the project are few, and dealing with changes
may not be challenging or disruptive. In general, the project-executing
organization and the project team are qualified with adequate experience
and expertise to complete the project successfully. The planned approach
has its premise on minimizing uncertainties and unknowns. Conse-
quently, the plan-driven project management approach may not deal with
complexity and changes associated with uncertainty and unknowns.
When projects are afflicted with a lack of full understanding of the out-
comes, fast-paced technological changes, and unclear needs of the client,
a plan-driven project management approach may prove to be inadequate.
The client may reveal functional outcomes incrementally as the project
makes progress, and the results are assessed. In other words, these projects
are associated with uncertainties and change. And, to deal with them, a
project team’s immediate focus is on flow and value generation. The agile or
change-driven approach is better suited for these projects with a focus on:

• Management as organizing for planning

• Action perspective for execution
• Scientific experimentation model for control
 Introduction 7

Management as organizing means the emphasis is on developing the

team structure and encouraging the team to perform needed ­planning,
only as much as is needed to execute each portion of work. Progress
is controlled by gaining feedback early and often and discussion of
what worked, what did not work, and why. This approach of man-
agement creating the conditions whereby a team can plan, perform,
and use results and judgment to control progress differs starkly from
plan-driven approach of management as planning and thermostat
model for control.
In the plan-driven project method, requirements are defined in the
beginning of the project (upfront planning), and then it will be signed off
for the project manager to freeze before the design and implementation
phase is started sequentially. The project manager uses a strict command
and control style using formal communication and a mechanistic struc-
ture to ensure that the work is completed as planned. However, in an agile
project, iterative planning is adapted, and only high-level objectives are
defined at the beginning of the project. Then, a detailed requirement pri-
oritization is done iteratively in later stages of the project. Leaders (who
probably do not have the title project manager) use collaboration with
team members, communicating informally to organically and flexibly
develop solutions that will help their clients achieve desired outcomes
(Table 1.2).
The fundamental difference between the two approaches is that
instead of freezing specifications early and developing a fixed plan, the
agile approach adapts flexibility to modify and alter project plans to
address critical business needs. An agile method is employed when:

• The project scope is unclear or poorly defined

• Required task times are unknown or unknowable
• Tasks and task dependencies are unknown
• The availability of resources is unknown or continuously
changing

A decision to adapt agile under these circumstances is justified, as

it offers greater adaptability to frequently changing scope, uses iterative
or phased planning, continuous integration, promotes collaboration, and
improves customer satisfaction.
8 Be Agile Do Agile

Table 1.2  Plan-driven versus agile development

Traditional development Agile development
Assumption Systems are fully specifiable, High-quality adaptive software
predictable, and are built is developed by small teams
through meticulous and using the principles of contin-
extensive planning uous design improvement and
testing based on rapid feedback
and change
Management style Command and control Leadership and collaboration

Knowledge Explicit Tacit

Communication Formal Informal
Model Lifecycle Evolutionary delivery
Structure Mechanistic Organic
Quality control Planning and strict control Continuous control of require-
ments, design, and solutions

Source: Dybå and Dingsøyr, 2008.

What Is the Plan-Driven Method?

It is well known that projects are constrained by scope, time, and cost. Quality,
for the most part, is integral to scope. As it is a nonroutine endeavor, every-
thing about a project is not known to us; we often term them as unknowns
and uncertainties. Also, the client may change requirements based on new
ideas or if an original and documented requirement is not feasible, not
required, or it becomes obsolete during the project implementation stage.
With the change in requirements, the project scope changes, which also
leads to changes in cost and schedule. As everything about a project is not
known, we make certain assumptions, and if these assumptions go wrong,
then also the project scope, cost, and time will change. For example, we
may assume that appropriate resources (quantity and quality) are available
as and when required during the project execution. Some projects tend to
be complex, that is, we know what we prefer as an outcome of the project,
but we do not know how to accomplish it. Obviously, an inherent charac-
teristic of a project is risk. Project risks are due to:

• Inaccurate or unrealistic assumptions

• Lack of complete understanding of the project scope
• Uncertainties
 Introduction 9

• Unknowns
• Changes to project scope, cost, and schedule due to
­unanticipated constraints
• Complexity associated with the project
• Inaccurate estimations of cost, schedule, and risk

In a plan-driven or traditional approach, we may attempt to address

these issues to the extent possible while developing the project plan, but
there is no such thing as a perfect project plan. If there is something
­constant about projects, it is the change.
Another important aspect is the distinction between a project and
process. A process consists of a series of actions designed to bring about
a result, be it a product or service. A process uses a lock-step approach,
and it is repeated. However, a project is complex, nonroutine, and one-
time effort. Once project goals are accomplished, the project is termi-
nated. The key differences between processes and projects are processes
are repetitive and ongoing and produce the same result, whereas proj-
ects are time-bound and unique. However, project management employs
several inter-dependent processes for its completion. These processes fall
into two categories: project management processes and project deliver-
able (product or service) processes. Project management from initiation
to project closeout is not always sequential (Figure 1.1).
As shown Figure 1.1, project phases are not always sequential due to
risks, changes, and quality control, which forces a project management
team to go back to the drawing board. From project initiation to project
closeout phase, managing a project sometimes necessitates us to revisit the
previous project phase. Therefore, we argue that it is not accurate to label
the plan-driven or traditional project management as waterfall method.
Managing projects is challenging, as projects often do not have pre-
cedence or prior knowledge and deal with revolutionary improvements.
Added to this, a project manager’s mission is to manage conflicting and
interdependent goals of delivering the product or service:

• At the client’s specifications or better

• On the promised delivery date or sooner
• With the approved budget or under
10 Be Agile Do Agile

Project Risk
Initiation Management

Project Quality
Planning Control

Project
Execution

Project
Closing
Monitoring
and Control

Figure 1.1  Project management process

With the global economy and free market philosophy, key stake-
holders expect project teams to deliver project outcomes that are better
than originally planned, complete the project earlier than the planned
­completion date, and at a lower cost than the planned.
Plan-driven project management offers many benefits such as:

• Early identification of project risks

• Informed and accurate schedules
• Early warning when milestones cannot be met
• Objective baseline for tradeoff analysis
• Clear functional responsibilities
• Methodically measured accomplishment reports
• Improved planning capability for future projects

However, projects may fail for many reasons such as:

• When requirements are incomplete

• When a user is not involved in planning and execution
• Nonavailability of resources
• Unrealistic expectations
• Lack of executive support
• Frequent changes to specifications
 Introduction 11

• Lack of proper planning

• Product or service is no longer needed

How Agile Is Sometimes Better Than Plan-Driven?

Plan-driven project management has its focus on the triple constraints
of time, cost, and scope and its process-oriented approach. On the other
hand, agile project management has its focus on business value and
solutions to situations. It is an outcome-oriented approach. Plan-driven
projects use distributed work teams and specialists, whereas agile
project teams are ideally colocated or at least virtually colocated. They
are ­composed of generalized specialists who are capable of doing a
wider variety of tasks to manage rapid changes and increments, and
it demands greater commitment from the team members. Although
external forces such as the global economy, free market philosophy, and
challenging situations like COVID-19 make pure colocated difficult
or impossible, the benefits of working closely together are still highly
desired and sought.
The plan-driven approach requires us to develop a comprehensive
project plan before project execution. However, this is not feasible when
projects deal with technologies that are not completely developed or unfa-
miliar. In those cases, an agile method would be a better option than the
traditional approach of managing projects. However, we must note that
new technology is one ingredient of complexity that agile aims to address.
The compelling reason for the decision is our inability to define project
requirements. In such projects, we tend to develop the project incremen-
tally and in phases, allowing the plan to unfold over the time by prioritiz-
ing functions that are more beneficial to the client and delivering them. It
would give the project team flexibility in focusing on important functional
outcomes first instead of dealing with greater complexity. It would also ben-
efit the client as budget is prioritized to maximize benefits. Also, the cost
of rework is minimized. All these advantages would be absent if we adapt
traditional approach for such technology-driven projects. Further, the proj-
ect cost implications could be catastrophic if the entire project is completely
planned and resources are allocated for a project where neither the client
nor the project team is clear about project outcomes.
12 Be Agile Do Agile

First Understand and Be Agile, Then Do Agile

Performing some of the agile methods without understanding the needed
agile mindset ay produce some results, but may even result in some con-
fusion and backlash. Therefore, we strongly believe it is important to
understand, at least a little bit, or the agile mindset to start.

Be Agile

For successful adaption of an agile method, it is critical to develop an

agile mindset. For those organizations that have been practicing plan-
driven project management methods, it would be a paradigm shift
in planning and executing projects. To sustain and improve project
­performance, this change in mindset must use a top-down approach.
The organization, project managers, and project team members must
understand and internalize agile project method principles. They include
values associated with various agile methods, such as scrum ­pillars and
values, and XP core values and practices. In a nutshell, the agile method
advocates the following:

• Use a simple approach

• Embrace change
• Change incrementally
• Maximize value to the client
• Provide rapid feedback to all stakeholders
• Practice transparency to build trust
• Improve quality of people, processes, and products

The majority of the benefits that we accrue comes from understand-

ing agile as the implementation strategy, and agile methods are dependent
on the characteristics of the project. In other words, the agile strategy
would depend on the type of project at hand.
Part of understanding agile is how Agile Manifesto principles are
transformed into various practical streams of agile such as scrum, XP,
lean, Scaled Agile Framework (SAFe), and disciplined agile. Only after
a comprehensive understanding of these agile streams and associated
 Introduction 13

benefits are understood, one can select an appropriate agile method for
the project. An understanding is not enough; belief and inclusion of
agile principles—by project team members, project managers, senior
management, internal and external stakeholders, and the organization
itself—are essential prerequisites to doing agile.

Do Agile

To begin with, doing agile requires a clear understanding of the type of

project at hand. In general, projects can be divided into four categories
(Figure 1.2).

1. Goal is clear—solution is clear

2. Goal clear—solution is unclear
3. Goal is unclear—solution is unclear
4. Goal is unclear—solution is clear

The fourth option is not possible because when the goal is not clear,
how can we have clarity about the solution? Even if you say that a solu-
tion is clear, which goal is it trying to achieve? It is possible to consider an
agile approach to manage projects of the first three categories. However,
the fourth category does not seem feasible. The agile strategy would also

Not Clear
4 e
ssibl 3
t po
No
Goal

1 3
Clear

Clear Not Clear

Solution

Figure 1.2  Agile strategy

Source: Wysocki 2006.
14 Be Agile Do Agile

depend on project priority, delivery date, level of quality, and desired visi-
bility of the project. Further, agile strategy is also influenced by the project
team and the client. A comprehensive understanding of these issues and
complete preparedness for all these strategies is critical before selecting the
appropriate agile stream and associated values. The purpose of this book
is to provide a detailed account of both the aspects—understanding agile,
then doing agile—to manage agile projects effectively and successfully.

How the Rest of the Book Is Organized

This book has two parts. Part A of the book presents the concepts and
practices associated with understanding agile, and Part B of the book
consists of the tools, techniques, and metrics of doing agile, as shown in
Table 1.3.
Part A presents comprehensive information to understand agile, and
it consists of four chapters, namely: Understanding the Agile Mindset;
Successful Outcomes; Leadership and Teamwork, including Roles and
Responsibilities; and Communication and Collaboration. Part B focus
is on doing agile or practices associated with managing agile practices.
This part consists of four chapters, namely, Summary of Doing Agile
Tools, Techniques, and Metrics; Planning Adaptively; Creating Useful
­Solutions; and Giving and Adapting to Feedback.

Part A: Being Agile

Chapter 2: Understanding the Agile Mindset presents Agile Manifesto prin-

ciples, which is the basis of various agile streams such as scrum, extreme
programming, lean, PMI-ACP, SAFe, and disciplined agile use as a foun-
dation. Core values and principles of all these agile streams are briefly dis-
cussed. After a review of all these agile streams, we propose an agile model

Table 1.3  Be agile and do agile here

•  Be Agile •  Do Agile
•  Successful Outcomes •  Planning Adaptively
•  Engaging Your Team •  Creating Useful Solutions
•  Communication and Collaboration •  Giving and Adapting to Feedback
 Introduction 15

for a better understanding of the key factors and associated elements with
each key factor to manage agile projects effectively and efficiently.
Chapter 3: Successful Outcomes discusses the vision and value based
upon stakeholders’ needs along with concepts of simplicity, excellence,
and improvement. We start with considering the importance of vision
at the project, project team, and organization levels. The vision must be
aligned with an organization’s objectives and goals. Integral to the vision
is understanding stakeholders and their needs and delivering value to all
the stakeholders. Simplicity is focused on work that is absolutely nec-
essary to avoid unnecessary work and rework. Then, focus on doing it
with excellence provides value to all the key stakeholders. Excellence work
results in high-quality deliverables that enable users to achieve their goals.
The aim is to improve products, processes, and people continuously.
Chapter 4: Leadership and Teamwork takes an approach that is differ-
ent from the traditional approach of top-down leadership of command
and control. In this chapter, we present concepts such as servant lead-
ership, emergent leadership, self-managed teams, respect for all team
members, selection of motivated people, creating avenues for motivation,
and participative decision making. Our discussion in this chapter also
includes roles and responsibilities of the team leader, team members,
product owner, and technical leader.
Chapter 5: Communication and Collaboration. In a project situation
of uncertainties, and absence of complete understanding of desired out-
comes of the project, effective communication is critical. Face-to-face
meetings, transparency, and frequent interactions with the client to
receive timely feedback are critical constituents of effective communica-
tion. Team members need to collaborate effectively with each other and
with various stakeholders.

Part B: Doing Agile

6. Performing Agile Methods. The Agile Manifesto was all about the mind-
set of agile, so we draw no tools or metrics from it. However, we draw
upon the tools and metrics from each of the approaches mentioned so
far: scrum, XP, lean or Kanban, PMI-ACP, SAFe, and disciplined agile. As
with the mindset ideas, we attribute techniques to the agile approach that
16 Be Agile Do Agile

we feel makes the largest contribution to each. Many of the techniques

are used by more than one approach.
7. Planning Adaptively. This chapter starts with using an agile lifecycle
whether that cycle is based upon iterations, continuous flow, or hybrid.
Second, we discuss governance of agile projects—both from the stand-
point of the team monitoring their own performance and from that of
others in the organization who need reassurance that the team is progress-
ing well. We touch on systems thinking. Then, we include initial planning
of envisioning the entire project, understanding user stories, prioritizing
requirements and work, and guiding initial improvement efforts. Finally,
we introduce the concept of ongoing planning that is expanded in the
following chapter.
8. Creating Useful Solutions. This chapter starts with the tools and met-
rics for product planning generally and those specific to increment-based
agile and lean-based agile. It includes tools for continual planning, build-
ing solutions, monitoring and controlling progress, testing, and quality.
9. Giving and Adapting to Feedback. This chapter starts with the
tools for visual communication. The second section includes ideas for
conducting effective sprint meetings of the following four types: plan-
ning, standup, demo, and retrospective. The third major section of this
­chapter is testing, followed by working through problems. We conclude
the ­chapter by discussing improvements.

Summary
Agile is a fundamentally different approach to managing projects. When cli-
ents do not know upfront what they want in terms of deliverables and are
willing to learn with the development team as progress is made, agile may be
appropriate. Team members take a more active role in planning and man-
aging their own work, and the role of project manager may be split between
the team, a product owner, and a facilitator known as a scrum master. Early
results lead to informed decisions as the details of deliverables emerge.
The goal is not to merely deliver according to specification, on time, and
on budget. Rather, the primary goal is to help the client become successful
using the results of the project. This is an important distinction. Often, using
traditional project management methods on large complex projects, such as
 Introduction 17

implementing an enterprise resource planning (ERP) system with new work

processes, an additional project phase would have to be added. This addi-
tional project phase will focus on delivering the promised business benefits by
­learning how to leverage the new system capabilities and new work processes.

Questions
1. Tell why organizations have turned to agile as a method of planning
and managing their projects.
2. Briefly describe major differences between plan-driven (traditional)
and agile project management.
3. Describe why agile is sometimes a more useful approach.
4. Briefly define what be agile and do agile mean.
 Index
Acceptance test, 32, 101, 160, 170 Alignment, 37
Achievement stage, 68–69 Analyze tag, 152
Adaptation, 29, 31, 55, 143 Architecture and design quality, 38
Adaptive planning. See Planning Architecture owner, 43
Advocate for agile, 34–35 Arnold, R. D., 106
Agile, 4–5 Artifacts, 99, 134
and plan-driven project Assume variability, 107, 124
management, 11 Awareness, 42
process, 26–27 Awesome, 41
strategy, 13–14
Agile Certified Practitioner. See Backlog refinement, 131
Project Management Backlogs, 134
Institute-Agile Certified Being agile, 12–14, 168–175
Practitioner (PMI-ACP) Blocked status tag, 152
Agile coach, 63, 74, 90 Bottleneck, 103, 139, 153, 171
Agile contracts, 106, 162–163 Building, 99, 141–142
Agile lifecycle, 16, 108, 109, 114 Build quality in, 38, 102, 138
construction phase, 115–116 Burn-down chart, 99, 143, 150, 155
hybrid lifecycle, 119–121 Burn-up chart, 99, 143, 150, 155
initiation phase, 114–115
iteration-based lifecycle, 116–118 Cadence, 37, 99, 133, 142, 155
lean lifecycle, 118–119 Change-driven project management,
transition phase, 116 29
Agile manifesto, 4, 12–16, 21–28, 31, Change for free, 106, 163
39–41, 43, 46, 84, 89, 96, Charter project, 104
109, 147 Code quality, 38
Agile metrics, 122 Collaboration, 87–89
Agile mindset, 4, 12, 14, 21–22, Collaboration games, 55
43–46, 109 Collective code ownership, 144, 172
disciplined agile, 39–43 Commitment, 11, 29–31, 44, 50, 59,
extreme programming (XP), 31–32 61, 64, 85, 114, 141
lean, 32–34 Commit to work, 97
manifesto values and principles, Communication, 7, 14–16, 26, 29,
22–28 32, 45, 49, 54, 57, 58, 62,
PMI-ACP, 34–37 65–68, 75, 77–78, 82–85,
SAFe, 37–39 87–91, 96, 110, 149, 170
scrum pillars and values, 28–31 and collaboration, 87–89
Agile Release Team (ART), 38–39 cultural differences and, 79–82
Agile release train, 107, 124 feedback and timeliness, 84–85
Agile teams, 40 learning process, 86–87
Agile tools, 96, 103, 109–110 organizational issues, 89–90
Agility, 2, 3, 27, 162, 175 scaling, 90–91
200 Index

team location and, 78–79 Delighted stakeholders, 109, 115

transparency in, 82–84 Disciplined agile, 12, 14, 15, 21, 34,
visual, 149–155 39–43, 107, 114, 123
Complexity belief, 43 lifecycle, 107–108
Computerization, 2 Disciplined Agile Delivery (DAD),
Confirmatory testing, 160 91, 185
Construction phase, 108, 115–116, Diversity, 42
160 Documentation, 23–24
Continual planning, 105, 141 Doing agile, 13–14, 169–175
Continued viability, 109, 123, 171 Done status tag, 152
Continuous delivery pipeline, 107, Duration, 67, 90, 97, 99, 127, 139,
124 149, 150
Continuous improvement, 33, 47, 48,
158, 163 Earned value, 105, 143
Continuous integration, 7, 143, 159 Eliminate waste, 101, 139–140
Continuously identify risks, 105, 141 Embrace change, 100, 131
Courage, 30 Emergent architecture, 114
COVID-19, 5, 11 Emergent design, 97, 134
Creation stage, 67 Emergent leadership, 15, 36, 61–63,
Cultural differences and 75, 76, 172
communication, 79–82 Empiricism, 28, 55
Culture, 33, 65, 79–81, 89, 123, 149, Encourage emergent leadership, 36
172 Epic, 29, 99, 125–129, 135, 157
Cumulative flow diagram, 143 Escaped defect rate, 145
Customer-driven value, 33, 49–51, Events, 41, 97–98, 110, 126, 148,
170 155–159
Customer-driven vision, 48–49 Excellence, 53–54
Customer prioritization, 104, 129, Experimentation, 30, 35–36, 59
173, 185 Extra features, 128, 140
Customer readiness, 145, 173, 175 Extra processes, 140
Customer satisfaction, 24–25 Extreme programming (XP), 14, 21,
Customers, delight, 41 31–32, 100–101, 143
Cycle time, 102, 139
Feedback, 7, 15, 16, 25, 32, 34, 40,
Daily progress (scrum) board, 87–89 45, 51, 54, 59, 87, 96, 102,
Daily scrum (aka standup), 84, 85, 103, 110, 114, 116, 119, 122,
98, 117, 148, 152, 156, 172 123, 140, 141, 145, 147,
Daily standup, 157–158 159–162, 169, 174–175
Decision making, 70–72 agile contracts, 162–163
Defect rate, 106, 144 events, 155–159
Defects, 140, 144 improving, 163–164
Defer decisions, 102 need for, 148–149
Definition of done, 31, 38, 52, 74, problems, 161–162
99, 117–119, 135, 156–158, testing, 159–161
175 and timeliness, 84–85
Definition of ready, 99, 142, 156, visual communication, 150–155
157, 170, 172, 174 Five whys, 106, 144
Delegate tag, 152 Fixed-price increments, 106
 Index 201

Flow, 102, 138–139 project, 7

Flow quality, 38 role, 64
Focus, 6, 11, 29–30, 33, 38–39 servant, 15, 36–37, 59, 61–62, 64,
Forty-hour work week, 53, 100, 131, 89, 171–172
171 transactional, 60
Foundation stage, 68 transformational, 60–61, 171
Lead time, 103
Generalized specialists, 11, 63, 138 Lean, 12, 16, 21, 32–34, 52
Governance, 108–109, 121–123 eliminate waste, 101, 139–140
Graduated fixed price, 106, 163 flow, 102, 138–139
pull production model, 102–103,
Handoffs, 33, 140, 173 137–138
High-context culture, 78, 80 visual management tools, 103
Hybrid, 16, 34, 41, 97, 104, 107, Lean (aka Kanban) lifecycle, 108,
109, 114 118–119
Hybrid lifecycle, 119–121 Learning process, 86–87
Lifecycle model, 107–108
Impediments, 73, 75, 85, 90, 99, Low-context culture, 78–82
117, 142, 157, 158, 172
Improve collaboratively, 102, 130, Make process explicit, 102
138, 174 Manage flow, 173
Improvement efforts, 130 Metaphor, 49, 100, 115
Improvement process, 54–55, Minimal marketable feature (MMF),
163–164 104, 128
Inception (initiation) phase, 108, Minimize WIP, 38; See also Work in
114–115 progress (WIP)
Increments, 135–137 Minimum marketable release (MMR),
Information radiator, 105, 137, 142, 108, 116, 145, 188
143, 150, 152, 155, 174 Minimum viable product (MVP), 34,
Initial planning, 104–105, 124–130 53, 128, 140
Inspection, 29, 55 Money for nothing, 106, 163
Integration test, 101, 160 Monitoring and controlling progress,
Investigative testing, 160 105–106, 142–143
Iteration-based lifecycle, 116–118 Monochronic time (M-Time), 79–80
Iterative process, 4, 148 MoSCoW, 104, 129, 134

Journey maps, 104, 126 Name tags, 152

Just-in-time (JIT) planning, 100, 131, Negotiation, 24
138
Objective milestones, 107, 175
Kanban board, 84, 101–103, 137, One-day tasks, 151
150, 153–154 One-size-fits-all model, 42
Kanban lifecycle, 114 Ongoing planning, 131
Openness, 29, 30, 84, 164
Leadership, 15, 58–60, 75–76, 82–83 Optimize the whole, 33, 102, 138
decision making and, 70–72 Organizational issues, 89–90
emergent, 15, 36, 61–63, 75, 76, Organizations, 40
172 Outcomes, 40, 47–56
202 Index

Pair programming, 144 Project leadership, 7

Persona, 105, 127, 170 Project management, 2–12, 22, 24,
Pivot, 99, 123, 130, 140, 142, 143, 34, 50, 61, 64, 76, 83, 97,
163, 175 101, 113, 127, 152, 153, 175
Plan at multiple levels, 105, 141 Project Management Institute-Agile
Plan-driven, 5–11, 61, 64, 65, 80, 81, Certified Practitioner
113, 114, 119, 127 (PMI-ACP), 34–37
Planning, 24, 100, 113–114 agile contract types, 106
agile lifecycles, 114–121 continual planning, 105
continual, 105, 141 initial planning, 104–105
governance, 121–123 initiating, 103–104
initial, 104–105, 124–130 monitoring and controlling
just-in-time, 100, 131, 138 progress, 105–106
ongoing, 131 Project risks, 8–9
release, 32, 98, 105, 110, 114, 131 Project success, 6, 44, 45, 63–65, 83,
sprint, 98, 129, 131, 156, 157 121
systems thinking, 124 Project team, 58–59, 63–65; See also
Planning poker (games), 89, 97, 136 Leadership
Polychronic time (P-Time), 79–80 Proven approach, 175
Portfolio vision, 107, 124 Proven architecture, 109, 123
Practice servant leadership, Psychological safety, 42
36–37, 173 Pull production model, 102–103,
Pragmatic goal, 41–42 137–138
Premortem, 105, 130
Prioritized backlog, 98 Quality, 101, 143–145
Problems, 161–162 Queue duration and length, 103
Process, 23
Product, 98–99, 134 Refactoring, 54, 143
Product backlog, 51, 53, 98, 128, Refine requirements, 104, 105, 141
130, 156–157 Release, 38, 97, 117, 145
Product backlog refining, 53, 98, 127, Release backlog, 98, 117, 135
156–157 Release decision, 145
Product increment, 52, 53, 99, 123, Release planning, 32, 98, 105, 110,
129, 135 114, 131
Production readiness, 123 Requirement, 4–5
Production-ready, 109 Resolution stage, 68
Product owner, 31, 43, 52, 53, 62, Respect, 31
63, 73–76, 82, 87, 117–119, Retrospective, 16, 98, 118, 142, 174
125, 129–131, 134–137, 157, Right-sized, 100, 127, 136
158, 163, 164, 172–175 Risk, 50
Product planning, 134–135 Risk-adjusted backlog, 104, 130
Product roadmap, 104, 125, 126, 170 Risk-based spike, 105, 130
Product vision, 48, 49, 63, 129, 170, Roles, 68
175
Program, 124 Savage summary, 82, 109, 153
Program execution, 38–39 Scaled Agile Framework (SAFe), 12,
Project, envisioning the, 125–126 14, 15, 21, 37–39, 43, 90–91,
Project initiation, 103–104 106–107, 109, 124
 Index 203

Scaling, 90–91 Systems thinking, 106–107, 124

Scrum, 4, 12, 14–16, 21, 28–31, 43,
62, 63, 73–75, 82, 85–88, 90, Task card, 103
96–99, 114, 119, 134, 135, Task switching, 102, 140
142, 148, 152–153, 173 Team development and motivation,
Scrum master, 16, 31, 62, 63, 73–76, 65–70
80, 82, 85, 86, 97, 142, 149, Team lead, 80–82
152, 157, 173 Team learning process, 86–87
Scrum of scrums, 90, 152 Team location and communication,
Semiautonomous self-organizing 78–79
teams, 42–43 Team member, 73, 173–174
Servant leadership, 15, 36–37, 59, Team roles, 72–76
61–62, 64, 89, 171–172 Teamwork, 14, 15, 45, 74, 87, 89
Shared vision, 35, 61 Test-driven development, 143
Share knowledge, 35, 105, 148 Testing, 100–101, 159–161
Shift left, 159 Test plan, 101, 159–161
Simplicity, 15, 27, 31–32, 44, 51–53, Three columns, 151
170–171 3C process, 103, 153
Slice a story, 127, 128, 135 Throughput, 102, 139
Small releases, 100, 114 Timebox, 52, 97, 117, 135, 174
Software development, 2, 3, 22, 32, Timely feedback, 84–85
78, 149, 159 Traditional project management, 2, 3,
Software Engineering Institute (SEI) 5–9, 22, 24, 25, 61, 76, 83,
Capability Maturity Model, 97, 152
164 Transactional leadership, 60
Solutions, 39 Transformational leadership, 60–61,
Spikes, 100 171
Sponsor, 26–27, 74, 75 Transition phase, 108, 115,
Sprint (aka increment), 53, 97 116, 160
Sprint backlog, 98, 117, 135, 157 Transparency, 29, 40–41, 82–84, 174
Sprint daily scrum, 148, 156 Trend analysis, 106, 142
Sprint planning, 98, 129, 131, 156, Tuckman’s team stage development
157 model, 66–70
Sprint retrospective, 156, 158–159
Sprint review (aka demo), 98, 135, Unit test, 32, 101, 160
156, 158, 175 Unplanned items and legacy issues,
Stakeholder, 39–40, 74 152
Stakeholder vision, 109, 115, User story, 99, 127, 135, 156, 170
122–124
Status tags, 151 Value stream mapping,
Storyboard, 151–153 105, 124
Story map, 104, 125, 126, 134 Variance analysis, 105, 142
Story point, 97, 136 Velocity, 99, 136
Subject-matter expert (SME), 75 Verification and validation, 143
Sufficient functionality, 109, 123 Visioning, 98
Support readiness, 145 Visual communication,
Sustainable pace, 131, 171 150–155
System quality, 38 Visual management, 103
204 Index

Wade, J. P., 106 Work culture, 79

Waiting, 140 Work in progress (WIP), 29–30,
Waiting status tag, 152 33–34, 38, 102, 139, 140
Waterfall method, 3, 9 Work item pool, 108, 119
Work breakdown structure (WBS),
127, 128 XP. See Extreme programming (XP)