AGILE PROJECT MANAGEMENT has been coalescing for many years at the intersection of

1
Lean Principles and the Project Management Institute’s A Guide to the Project Management

AGILE Almanac – BOOK 1: Single-Team Projects |

Body of Knowledge, (PMBOK® Guide) Fifth Edition, Project Management Institute, Inc. 2012. #
Over time multiple schools of thought, each with their own evangelists and disciples
developed. However no one has undertaken the effort necessary to collect and codify the
SELLER
various insights, options, and best practice choices available, until now.
BEST 3.15
This almanac brings a unique perspective to the divergent, often conflicting and accusatory 12 .1
viewpoints expressed by the evangelists on any side of the Agile versus Traditional battlefield.
It serves the Agile and Project Management communities by presenting the best practices
that are most used, numerically, and most proven, statistically.
It also extends that thought leadership into NON-software environments. And finally, it
presents the information in an easily accessible and immediately applicable fashion in order
to serve as a Field Guide for practitioners in the real world!

JOHN G. STENBECK, PMP, PMI-ACP, CSM, CSP, is the Founder of GR8PM, Inc. (pronounced “Great
PM”). John is the best-selling author of “PMI-ACP® and Certified Scrum Professional Exam Prep and
Desk Reference” that achieved over $1 million in sales as well as “Agile Government Contracting”. He
has a combined background in Accounting, Operations, I.T. and Project Management.
He is a sought-after Keynote speaker delivering over 50 events a year. John specializes in programs
that engage hard-to-impress technical and engineering professionals with a unique Keynote-Workshop
style that returns them to work... enabled to be powerfully productive!!
A partial list of John’s clients includes: Booz Allen Hamilton, Inc. – Defense Information Technologies
Group, County of Orange (CA), Guinness Bass Import Company, Hewlett-Packard Company, BOOK 1: SINGLE-TEAM
Lucent Technologies, Nike Corp., Oracle Corp., Qualcomm, Inc., U.S. Army – Space and Terrestrial PROJECTS & EXAM PREP
Communications Directorate, U.S.D.A. – National Finance Center, Visa – Smart Cards.
John was an Adjunct Instructor for UCSD’s School of Extended Studies teaching the Project
Management course in the Systems Engineering Certificate program before relocating
to Spokane, WA. He has taught over 9,500 students in public and corporate onsite A FIELD GUIDE FOR EVERYONE USING AGILE TO IMPROVE PROJECT RESULTS
events.
John is certified by PMI as a Project Management Professional (PMP®) and an
Agile Certified Practitioner (PMI-ACP®). He also holds Certified Scrum Master
(CSM) and Certified Scrum Professional (CSP) designations from the Scrum
Alliance and an ITIL v3 Foundations certification. JOHN STENBECK, PMP, PMI-ACP, CSM, CSP

ABRIDGED
Stenbeck

VERSION
BOOK 1: SINGLE-TEAM PROJECTS
& EXAM PREP
ii AGILE ALMANAC: Single Team Projects & Exam Prep
BOOK 1: SINGLE-TEAM PROJECTS
& EXAM PREP

JOHN G. STENBECK, PMP, PMI-ACP, CSM, CSP

First Edition

Spokane, WA

iii
 Agile Almanac
Book 1: Single-Team
Projects and Exam Prep

John G. Stenbeck, PMP, PMI-ACP, CSM, CSP

Published by:
GR8PM, Inc.
1818 W. Francis Ave. #228, Spokane, WA 99205 USA
(619) 890-5807
custserv@gr8pm.com; http://www.gr8pm.com/

All rights reserved. No part of this book may be reproduced or transmitted in any form
or by any means, electronic or mechanical, including photocopying, recording or by any
information storage and retrieval system without written permission by the author, except
for the inclusion of brief quotations in a review.

Copyright© 2015 by GR8PM, Inc.

ISBN Edition: 978-0-9846693-5-6

is book includes material based on the Project Management Institute, A Guide to the
Project Management Body of Knowledge, (PMBOK® Guide) – Fih Edition, Project Man-
agement Institute, Inc. 2012.

e book also contains many references to other registered terms such as PMP®, PgMP®,
CAPM®, PMI-SP®, PMI-RMP®, or PMI-ACP®, which are registered marks of the Project
Management Institute, Inc.

is book expresses the views and opinions of its author. e information contained
in this book is provided without any express, statutory, or implied warranties. e au-
thor, GR8PM, Inc., its resellers, and distributors disclaim any liability for any damages
caused or alleged to have caused either directly or indirectly by this book.

iv AGILE ALMANAC: Single Team Projects & Exam Prep

 Table of Contents

FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

PART ONE – INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix

CHAPTER 1: Why is Almanac Is Needed . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Understanding is Almanac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
How do these books help Practitioners and Organizations? . . . . . . . 3
Important Structural Highlights and Conventions . . . . . . . . . . . . . . . . . . . 5
e “Big 5” Deep Dive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Recommended Reading and Chapter Endnotes . . . . . . . . . . . . . . . . . 6
Flashcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix 1: Exam Certification Choices . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix 2: Exam Prep “Pre-Game” Quick Notes . . . . . . . . . . . . . . . 7
Summarizing Agile Certification Choices. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Agile, PMP®s and 1500 Agile Hours . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

CHAPTER 2: Agile From a PMP®’s Perspective . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Two Quick, Familiar Analogies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Assembling a Jigsaw Puzzle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Building a Shopping Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
What Makes Planning Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Understanding Lean’s Evolution Into Agile . . . . . . . . . . . . . . . . . . . . . . . . 20
Agile and Apollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Agile and the PMBOK® Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Core Purpose of Project Management … and Agile . . . . . . . . . . . . . . . . . 24
Agile Value Proposition … in a Nutshell! . . . . . . . . . . . . . . . . . . . . . . 26
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

CHAPTER 3: Agile Project Management and Lean Principles . . . . . . . . . . 39

Agile Lexicon – Methodologies, Frameworks and Processes. . . . . . . . . . 39
Agile Manifesto and e 12 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Understanding the Agile Manifesto. . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Table of Contents xv
 Principles Behind the Agile Manifesto . . . . . . . . . . . . . . . . . . . . . . . . 42
Agile Micro-Dynamic Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Micro-Dynamic Team-level Workflow . . . . . . . . . . . . . . . . . . . . . . . . 46
Micro-Dynamic Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Micro-Dynamic Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Micro-Dynamic Work Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Stakeholders and Minimal Marketable Features (MMF) . . . . . . . . . 58
Value-Driven Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Test-Driven Development (TDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Product and Iteration Backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Operational Ceremonies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Actionable Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Osmotic Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Agile Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

PART TWO – THE “BIG 5” DEEP DIVE. . . . . . . . . . . . . . . . . . . . . . . . . . . 115

CHAPTER 4: Scrum Deep Dive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapter Highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Overview of Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Ceremonies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

CHAPTER 5: eXtreme Programming (XP) Deep Dive . . . . . . . . . . . . . . . . 157

Chapter Highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Overview of eXtreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . . . 157
Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Ceremonies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

CHAPTER 6: Lean Soware Development (LSD) Deep Dive . . . . . . . . . . 203

Chapter Highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Overview of Lean Soware Development (LSD). . . . . . . . . . . . . . . . . . . 203
Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

xvi AGILE ALMANAC: Single Team Projects & Exam Prep

 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Ceremonies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

CHAPTER 7: Kanban Basic Practices Deep Dive. . . . . . . . . . . . . . . . . . . . . 235

Chapter Highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Overview of Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Ceremonies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

CHAPTER 8: Hybrid Project Management Deep Dive. . . . . . . . . . . . . . . . 281

Chapter Highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Overview of Hybrid Project Management . . . . . . . . . . . . . . . . . . . . . . . . 281
Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Ceremonies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Earned Value Management (EVM) . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Agile Mindset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Chapter Close-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

PART THREE – AGILE TOOLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

CHAPTER 9: Estimating and Derived Schedules . . . . . . . . . . . . . . . . . 305
CHAPTER 10: Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
CHAPTER 11: User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

PART FOUR – GLOSSARY and EXAM PREP APPENDICES . . . . . 333

Exam Prep Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Comprehensive Exam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Comprehensive Exam Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Table of Contents xvii

 PA R T O NE
INTRODUCTION

PART 1: Introduction xxix

 CHAPTER

2
Agile From a PMP®’s Perspective
Chapter Highlights
In this chapter we describe how Lean principles evolved into Agile Project
Management practices. We will highlight important Agile principles that
impact every organization – commercial, industrial, governmental and
institutional – and need to be understood in order to assess the value of
agility in their environment.

Two Quick, Familiar Analogies

Years of teaching experience have shown that sharing quick, familiar
examples helps students create useful mental maps as they study Agile Project
Management in greater depth. Let’s use building a jigsaw puzzle and also a
shopping center as examples of Agile thinking being applied in situations
familiar to you.

Assembling a Jigsaw Puzzle

Imagine for a moment that you and three friends decide to
assemble a jigsaw puzzle. In many ways, Project Management
oen feels like this. e first step is to define the project
objective. In this case, the objective is to assemble a 1,000-piece
puzzle of a Space Shuttle Launch. You clarify the understanding
of the objective by propping up the lid from the puzzle box so
everyone can see a clear picture of the desired final result. In
Traditional Project Management this activity would be
called creating the Project Charter, while the same
activities in Agile would be considered
defining the Product Vision. By the way, a
side objective that oen goes unspoken is
to finish successfully and remain

CHAPTER 2: Agile from a PMP®’s Perspective 15

 friends aerwards! Next, your group
agrees on the tactic it will use to
complete the work. e most common
tactic is to assemble the outer edge, or
frame, of the puzzle as single team then
work independently creating sub-
assemblies of pieces that make up
distinct sections of the puzzle. For
example, the external fuel tank, the
adjacent tower, and the steam clouds.
While you are doing the work, you
pause frequently and synchronize with
your teammates by sharing data on
what you have done and what you are
trying to do. It might sound somethin trying to do. It might sound something
Figure 2.1 | Jigsaw Puzzle like, “I’ve connected all the white steam
cloud pieces. Now I’m looking for the dark pieces of the fuel tank.” In Agile
Project Management this activity would be called a Stand-up Meeting while
the same activities in a Traditional setting would be called a Status Meeting.
As the work proceeds, in order to help the team complete the project, the
“expert” in white clouds and dark landscaping might begin helping the
“expert” working on the external fuel tank or the “expert” working on the
water tower. is concept of teamwork highlights the value of having a cross-
functional team where each Subject Matter Expert (SME) is also willing to
extend beyond their core skills and learn other skills in order to help the team
accomplish the shared mission.

Building a Shopping Center

Expanding on the jigsaw analogy,
imagine for a moment that you and
three friends are investors who decide
to build a shopping center on a piece
of land you recently acquired.

e first step you take is to hire an

architect to help define a Project
Objective, maximizing the value of your
investment. e architect would then
initiate a repetitive, cyclical process to
Figure 2.2 | Plot Plan
help you make choices and define the

16 AGILE ALMANAC: Single Team Projects & Exam Prep

Final Objective with a set of blueprints. In Agile Project Management, each
timebox in the cycle would be called an Iteration or Sprint and the expected
result would be called a Potentially Shippable Product.

Iterations are single cycles of development with a fixed-length that is

not varied during the Release. Commonly the length is fixed at one to
four weeks. It is the basic operational process used in Agile to deliver
desired results in small increments. e standard Iteration typically delivers
new development work that has been subjected to full quality assurance and
user acceptance testing. It begins with the Iteration Planning meeting and
concludes with a Review meeting for interested stakeholders and a
Retrospective meeting for the Team. In Scrum it is called a Sprint.

For example, Iteration 1 would likely deliver the Plot

Plan, as seen in Figure 2.2, as the Potentially Shippable
Product. Following your discussions with the architect,
either the Plot Plan would be accepted or additional
revisions would occur in the next Iteration. You would
review the result, again deciding to accept it or request
more revisions. Assuming for the moment that you
accepted the Plot Plan at the end of the second Iteration,
then Iteration 3 might deliver the Elevation Drawing, as
Figure 2.3
seen in Figure 2.3. Elevation Drawing

Again, following discussions with the architect, either the Elevation Drawing
would be accepted or revisions would occur during additional Iterations until
you accepted the result. If, for example, you accepted the Elevation Drawing
at the end of the sixth
Iteration, Iteration 7
could possibly deliver a
Computer Generated
Walkthrough, as pictured
in Figure 2.4.

By now you can see how

the process works. e
team does the work to
deliver a result. You
discuss the result with the
Figure 2.4 | Computer Generated Walkthrough team of SMEs, in this case

CHAPTER 2: Agile from a PMP®’s Perspective 17

the architectural firm, then you make a decision to accept or revise the
Potentially Shippable Product from that Iteration.

Your decision to accept or reject the Potentially Shippable Product is either a

formal or informal Test-Driven Development (TDD) process depending on
the experience and maturity of your group of investors and the architectural
firm. Eventually, the process will embrace a formal TDD process when
another critical stakeholder – the Building Department – gets involved. Until
the details in the blueprints, schedules and specifications meet the minimum
standards defined by the Building Department, they will not issue the
building permits and your project cannot begin the construction phase.

is same process in Traditional Project Management would be called Rolling

Wave Planning and the activities would be Progressive Elaboration and
Decomposition. e timeboxes might be weeks or months and the decision
points would be called Milestones, Phase Gates, or Go – No Go Meetings.

e goal of the process is to reduce waste regardless of whether you use the
Agile or Traditional lexicon to describe it! Waste reduction is one of the core
Lean principles that drive both Agile and Traditional Project Management
best practices.

ere are other best practices also implied and imbedded in these analogies.

For example, your jigsaw team and the architectural team are both cross-
functional. eir strength comes from the different skill sets contributed by
each SME. Consequently, it is implied that the team has all the skills necessary
to complete the project. Neither Agile nor Traditional Project Management
are a magic potion or wand! If a team does not have the required skills, it
cannot successfully complete the project.

Another example is using various meetings and techniques to solicit feedback

as part of the Stakeholder Management best practice. Consider for a moment
the pancake stacks in Figure 2.5 and ask, “Which one do most stakeholders
want and expect if all the information they are given is what they see in
Figure 2.5?” en ask yourself, “What happens to stakeholders’ expectations
when they are shown the information in Figure 2.6?” Far too oen Project
Managers complain about irrational stakeholder behavior without identifying
the underlying cause and accepting responsibility for doing their part to
change the situation. Stakeholders are human and humans are irrational when
they make a decision without the information needed to understand the real
context of the decision.

18 AGILE ALMANAC: Single Team Projects & Exam Prep

Figure 2.5 | Stakeholder Management

Cost and schedule are two of the key drivers in making scope decisions. A stack
of pancakes I definitely wanted when I understood the cost and schedule to be
$100 and 1 day becomes a stack of pancakes I absolutely don’t want when I learn
the cost and schedule are $10,000 and 6 months. Without complete, clear
information the stakeholder could make the wrong decision and appear
irrational, but it would be the Project Manager’s fault. e core purpose of both
Traditional Rolling Wave plans and Agile Iterative and Incremental
development is to provide adequate, accurate and timely information so
stakeholders can properly understand the context of their decisions.

$100 $1,000 $10,000

1Day 3 Weeks 6 Months

Figure 2.6 | Stakeholder Management

What Makes Planning Agile

Given the simple analogies just described, one of the first follow-up questions
that should be asked is, “What makes project management Agile? What makes
planning Agile? What is the difference between Agile and Traditional?”

CHAPTER 2: Agile from a PMP®’s Perspective 19

Interestingly enough, Helmuth Graf von Moltke, a German Field Marshal3 in
the early 1800s summed it up when he said, “No plan survives contact with
the enemy!” He was thinking of the high complexity and high uncertainty
that exists and is unavoidable, by definition, on battlefields. at description
also happens to be a pretty good fit for what most projects are like. Projects
are challenges with high complexity, high uncertainty, and even battlefield-
like atmospheres at various times.

No plan survives contact with the enemy. Is there anybody who has ever been
on a project of any significance that actually went according to the original
plan? Has such a project ever even been heard of? His observation is really
interesting because it focuses on the core assumption of Agile that project
management must be responsive to the situational reality.

So what makes project management Agile? What makes planning Agile?

ere are really two key characteristics. First, Agile balances resource
consumption against the absolute certainty that the plan is going to change.
We know the plan is going to change so spending a huge amount of time
doing a super detailed plan at the very beginning – knowing that it is going to
change – violates the Lean practice of always reducing avoidable waste!
Instead, Agile uses an iterative and integrated cycle of development and
planning that applies the best practices of Rolling Wave Planning and
Progressive Elaboration in a robust and meaningful way. e second trait that
makes planning and project management Agile is embracing change that is
driven by two factors – the acquisition of new knowledge or the
circumvention a problem in the original plan.

When either of those factors is present, we change in order to leverage the

opportunity presented by the new knowledge or to avoid the mistake inherent
in the original plan.

Understanding Lean’s Evolution Into Agile

According to Winston Churchill, “To improve is to change; to be perfect is to
change oen!”

Given the wisdom in Churchill’s comment, the movement to adopt and adapt
Lean principles into the project management profession is not surprising. An
oen overlooked reality of today’s workplace, now and forever into the future,
is that the constantly increasing rate of technological capabilities is driving
almost unimaginable levels of complexity, and therefore uncertainty, into
project management. A related and unavoidable truth for organizations,

20 AGILE ALMANAC: Single Team Projects & Exam Prep

whether they are competing in budget battles for tax dollars or competing in
the marketplace for consumer dollars, is that every constituent and customer
has had their expectations conditioned by the Internet and companies like
Amazon, Facebook and Google. Good enough is no longer good enough.
Speed, complexity and uncertainty are constants in the new baseline of every
project!

In such a challenging environment, experience has shown the best practices

available for achieving success come from the principles of Lean
Manufacturing, as originally developed in the Toyota Production System with
the insight and guidance of W. Edward Demings4 and extended by Eli Goldratt5
in his seminal work on the eory of Constraints and the Critical Chain.

Because a great many projects today have levels of complexity and uncertainty
similar to when John F. Kennedy launched the Apollo Space Program, taking
a moment to reflect back can provide interesting insights into understanding
how Lean was the outgrowth of iterative and adaptive development practices,
and also how Lean is being adapted and adopted into the project management
profession.

Agile and Apollo

If you are old enough to remember, you can still hear John F. Kennedy’s clipped
New England accent as he said, “We will go to the moon and return a man
safely by the end of the decade!” But to really understand the power of his
statement, you have to put yourself in the context of that timeframe. To fully
understand how boldly he embraced a challenge with epic levels of complexity
and uncertainty, you have to recall the situational context.

At the time that he made that bold proclamation, as a nation we had never put
anything in orbit and engineers were using slide rules to do calculations because
computers with adequate computational power did not exist. It would have been
a huge claim to say that we are going to put an object into orbit and return it
safely. But to say that we were going to put a man on the moon and return him
safely was an outlandish claim. And part of the power that is held was that it was
crystal clear; to the moon and back, safely, by the end of the decade!

ere could be no fudging. It would be exactly clear whether you reached the
moon, returned safely, and when! e Project Charter provided an unmistakable
set of Acceptance Criteria that could be decomposed into a completely
measurable series of Iterations where Test-Driven Development could harness
talent and energy to create Incremental Progress at a Sustainable Pace.

CHAPTER 2: Agile from a PMP®’s Perspective 21

He then took the next important step that is sometimes missing from projects
in a lot of organizations. He recruited the right team to take on this
unbelievably challenging project. And that team decided to move forward
using an iterative development methodology.

Stop for a moment, again, and recognize that the Apollo team chose iterative
development before Agile’s Manifesto had been written, before the Project
Management Institute existed, and before the Toyota Production System, the
source of Lean principles, existed. ey took on this project in the absence of so
many of the core best practices available today and still succeeded.

So even though iterative development techniques were being employed before

Lean principles were developed, and even though Lean principles were
developed before the Agile movement began, the introduction of Agile to many
PMP®s has still been an experience of surprise and confusion. Unfortunately,
Agile has been presented by some of its early adherents as something
completely new, completely foreign to project management, and completely
opposed to the PMP®’s worldview. is has resulted in unnecessarily limiting
Agile adoption simply because it was misrepresented by those early adherents
who were misinformed about the true pedigree of Agile.
Agile and the PMBOK® Guide
For many PMP®s with a background in Traditional Project Management, the
whole idea of Agile Project Management seems to have appeared out of
nowhere. Additionally, it is hard for many of them to discern whether it is
simply a passing fad or a source of genuine value to the project management
profession. So before we begin a deep dive of the details of Agile and focus on
how it works, it is useful to step back and get an overall perspective by
examining the relationship between Traditional, oen called Waterfall, as
embodied in the PMBOK® Guide and Agile Project Management.

A valuable place to begin is with some common myths about Agile and its
relationship to Traditional Project Management.

MYTH #1 – Agile is completely separate from and outside the PMBOK®

Guide.
FACT #1 – e PMBOK® Guide 2000 Edition included Rolling Wave
Planning, Progressive Elaboration, and Decomposition and was published
a full year before the Agile Manifesto was written. All three are core Agile
practices and the simple fact is that it is impossible to be a successful
Project Manager and not be using those three practices.

22 AGILE ALMANAC: Single Team Projects & Exam Prep

 MYTH #2 – Agile is a revolution.
FACT #2 – Suggesting Agile is a revolution is an exaggeration, at best, and
a self-aggrandizing deception, at worst. At its most basic core, Agile is
simply the application of proven Lean principles to the profession of
project management. Because Agile draws on the proven heritage of Lean,
it offers improved planning and team management practices in
environments where high uncertainty and high complexity exist. e idea
that the child, Agile, sprang into existence from nothing is ludicrous and
insults the very fine parentage of Lean.

MYTH #3 – Agile is easily scalable to large programs and enterprise

portfolios using the practices taught and utilized in Scrum, eXtreme
Programming, Lean Soware Development, and many other frameworks.
FACT #3 – Every Agile framework is missing two key components
required for scalability. Every Agile framework is missing both budgeting
and sophisticated scheduling tools. e good news is that Agile can
overcome this limitation by integrating with practices from the PMBOK®
Guide and PMI’s other Practice Standards.

MYTH #4 – Agile can meet its stated goal of “changing the world of work”
with the practices used by many Agilists that maintain an exclusive focus
on the Customer and Team while ignoring the needs of the Organization.
FACT #4 – Any approach that fails to meet the budgeting and scheduling
needs of the Organization is self-limiting because without the resources of
the Organization, the Teams cannot exist to develop the products and
services desired by the Customer. Without meeting the needs of the
Customer, the goal of “changing the world of work” will never be achieved.
erefore, integrating the needs of the Organization is fundamental to
“changing the world of work.”
Beyond these very common myths, many Agilists seem to ignore the evidence
that Lean-aligned organizations in every industry have planning guidelines
and processes that enable and sustain the focus and productivity of teams,
including Agile teams. In order for a Team to serve a Customer, it is necessary
for an Organization to provide resources. erefore, the Organizational-
customer has the right to expect a reliable estimating and planning
environment. e Lean-aligned, proven techniques from the PMBOK® Guide
can be integrated in mutually beneficial ways with Agile best practices to
support and enable Teams while creating a healthy and dynamic world of
work in the process.

CHAPTER 2: Agile from a PMP®’s Perspective 23

In order to understand the numerous ways in which Agile and the PMBOK®
Guide can be complementary, a clear lexicon must be developed and used. As we
like to say at GR8PM, “Power comes from using precise language … precisely!”
We talked about Methodologies as the highest-level structure or philosophical
foundation. At the highest level in project management you have two primary
Methodologies, referred to as Traditional or Waterfall, on the one side and
Agile or Lean on the other side. Traditional typically refers to approaches
based on A Guide to the Project Management Body of Knowledge, (PMBOK®
Guide – Fih Edition, Project Management Institute, Inc. 2012). Agile or Lean
approaches are based on iterative product development, the Toyota
Production System, and the Agile Manifesto.
It is worth noting that, technically speaking, the PMBOK® Guide covers the
entire body of knowledge about project management, which implies that Agile
or Lean practices are a subset of that overall body of knowledge.
Methodologies contain Frameworks, sometimes referred to as Extensions. For
example, the PMBOK® Guide has extensions for the Automotive,
Construction and Soware industries that contain best practices beyond the
core of the PMBOK® Guide. In the Agile lexicon, instead of extensions, they
refer to Frameworks and there are a variety of them. Scrum is by far the best-
known and best recognized, but the list also includes eXtreme Programming
(XP), Lean Soware Development (LSD), Kanban and Hybrid Project
Management approaches.
It is also worth noting that when you reach for a box of facial tissues, you are
likely to call it a box of Kleenex regardless of the actual brand. at is because
Kleenex is the best-known brand in facial tissue. Similarly, many people use
Scrum and Agile interchangeably. But to be accurate, Scrum is a particular set of
practices within the Agile Methodologies.

So, to use an analogy, when you choose a Framework, it is the “house” or

“container” that holds the various processes, practices and protocols defining
how to initiate, manage, organize, fund and report about the project being done.
erefore, different Frameworks may have similar and different processes,
practices, and protocols tailored to their specific industry or environment.
Core Purpose of Project Management … and Agile
e core purpose of project management is to aid and support stakeholder
decision-making! at’s it. Period. And that core purpose is the same whether
Traditional or Agile Project Management methods are being used.

24 AGILE ALMANAC: Single Team Projects & Exam Prep

As mentioned earlier, many Project Managers complain about irrational
stakeholders. In fact, some Project Managers insist there isn’t any other kind!
But the sad, self- incriminating truth is that a lot of times stakeholders are
irrational precisely because the Project Manager made them that way. When
the Project Manager doesn’t continually teach, and reinforce, and re-impress
upon stakeholders that their job is to support the stakeholder’s decision
making, the Project Manager becomes the decision maker. And that is a big
mistake!

Stakeholders cannot make intelligent decisions if the Project Manager doesn’t

give them adequate, accurate, and timely information. e Project Manager’s
job is to be the expert source of that information and provide it with a proper
frame around it. e Project Manager must be able to structure the
information so the stakeholder can make a rational decision.

John Maynard Keynes, a well-known economist, said, “It is better to be

roughly right than precisely wrong!” If 80% of projects are on time and on
budget, deliver what they’re supposed to, and do so 80% of the time, then the
organization should not change! Projects are already executing at a very, very
high standard. Likewise, if 80% of projects are nightmares, have members of
the team quitting, have everybody else on blood pressure medicine, and
deliver unhappy customers, the organizational approach is precisely wrong
and must change!

e most common point of confusion is when senior decision makers think

the organization is in situation number one, with 80% of everything going
well, but the actual reality is situation number two, with 80% of everything in
chaos. If senior management is living with a rose garden perception, the first
critical step is to establish contact with reality. Doing so is beyond that
immediate scope of any project management approach, including Agile, but it
can be done. A good starting point can be a discussion of the biennial Chaos
Studies (from the Standish Group) showing the reality that one third of
projects actually succeed, one third are challenged, and one third outright fail.
But, again, that is beyond the scope of this book as well.

e science suggests that the highest probability is that no more than 40% of
projects in your organization are successful even if your project management
practices are exceptionally good! Another 40% of your projects are
challenged. is means that implementing Agile practices can help achieve
the essential purpose of aiding and supporting better decision-making
throughout the organization.

CHAPTER 2: Agile from a PMP®’s Perspective 25

at makes it very important that your organization understand that Agile
and the PMBOK® Guide are intertwined and that many Agile practices are
important to the organization because they are a more robust way to apply
core PMBOK® Guide principles. at central truth makes it is important to be
able to express the Agile “value proposition” concisely.

Agile Value Proposition … in a Nutshell!

As strange as it sounds, companies and organizations don’t actually want
agility – or at least not agility for agility’s sake. ey want innovation!
Organizations of all types have come to recognize that the economic drivers
of success have moved from information to innovation.

Although the rate of information technology innovation has cooled down

over the last decade from majestic to simply exceptional, innovation in
bioengineering, nanoscale science, combinatorial chemistry and big data
analytics have filled any vacuum and accelerated competition along the
innovation curve. Technology has fundamentally altered the innovation
process so that it permanently advances on a non-linear growth curve. at
vertical shi, driven by technology, has altered the process of research,
experimentation and change thereby reducing the cost of discovery by rough
orders of magnitude. e cost of iterating through uncertainty, and the speed
at which those iterations can be done, mean that the process of finding the
best possible solution has been improved so dramatically it has altered many
of the fundamental rules of business and government.

at technology-driven process change means the cost of exploration and

experimentation has been so drastically reduced that discovering solutions
both more effective and less costly is now possible. is new dynamic can be
seen in the advances driven by Lean manufacturing and Agile development in
industries as varied as integrated circuits, pharmaceuticals, soware, and
automotive, commercial and rail transportation vehicles.

However, leveraging this technology-driven process change has proven tricky.

Nowhere has it been trickier than in project management. Moving from
Traditional prescriptive processes with detailed specifications, to discovery
processes with experimental and exploratory methods, means organizations
and people have been compelled to change. Project Managers must now
facilitate the discovery process rather than design detailed, prescriptive plans.
Additionally, organizations need new metrics for guiding and measuring the
discovery process in order to activate lower cost and higher value

26 AGILE ALMANAC: Single Team Projects & Exam Prep

performance for their customers and constituents. erefore, it should not
come as a surprise that this transformation sometimes proves difficult.

Difficult or not, it is necessary because the playing field where human

communities compete, from companies to agencies, commands, and
departments, requires innovation and agility to create or maintain any
competitive advantage.

Sustainable advantage comes from systematic innovation. Whether

enterprises, agencies, or communities thrive, survive, or fail is directly
correlated to their ability to be agile and innovative. (And the same can be
said for your career and future!) at core driver is behind the ever-increasing
demand for Agile Project Managers. at is also the Agile value proposition…
in a nutshell!

Stated another way, projects allow organizations to operationalize their

innovative strategic vision. Executing those projects using the correct project
management framework ensures those projects maximize the positive impact
of the assets and people deployed to deliver them. To accomplish this,
professional Project Managers are increasingly being tasked by their
organizations to synthesize the best practices of Traditional and Agile
frameworks into an approach that is tailored to the environmental demands
they face.

Without a solid base of Agile project management knowledge it is impossible

for a project manager to fulfill that responsibility effectively. Evidence strongly
suggests that the future of project management is running Hybrid projects
(see Figure 2.7).

Figure 2.7 | Total Projects by Framework

CHAPTER 2: Agile from a PMP®’s Perspective 27

 Hybrid projects are projects managed with a combination of
Traditional and Agile practices or with a combination of practices from
multiple Agile frameworks.

Today’s professional Project Manager cannot be effective without the ability to

run Hybrid projects. Basically, the Agile Project Management value
proposition is the ability to manage Hybrid projects because you have an
understanding of both Traditional and Agile frameworks!

Is Agile Really Needed?

For many practitioners from a Traditional Project Management background,
the whole idea of Agile Project Management seems to have appeared out of
nowhere. Even though there is a core of Agile principles in the concepts of
Rolling Wave Planning, Progressive Elaboration, and Decomposition, for
many Project Managers it seems hard to discern whether it is simply a passing
fad or a source of genuine value to our profession.
Project management, aer all, is not a profession that quickly embraces
change. e last major tool recognized in the Project Management Institute’s
"A Guide to the Project Management Body of Knowledge (PMBOK® Guide) ¬–
Second Edition was the Critical Chain6 in 1997.
With today’s non-linear increasing rate of technology-driven process change,
survival requires organizational agility. Broadly speaking, organizational
agility can be described as having the capacity to quickly respond to strategic
opportunities because internal structures enable shorter decision cycles
through frequent market and product development reviews. Organizational
agility means having an integrated view of the customers’ needs and
responding to those needs with desirable solutions. To accomplish that
objective, cross-functional project teams must have the power to act fast while
maintaining appropriate change and risk management processes.
Interestingly, the Apple iPad provides a classic case study in Agile Project
Management. In Lean and Agile terminology, it was a full function device
that included the minimum marketable feature set, yet it was not a full feature
tablet PC. Because it was focused on what the customer wanted, it sold 3
million devices in 80 days and almost 15 million devices in its first 8 months,
taking 75% market share of tablet PCs by the end of that year (2010). at
meant that it sold more units than all other tablet PCs combined.
e success of the iPad speaks eloquently to the success that agility enables. It
also challenges organizational leaders who may feel an expectation to produce
achievements equivalent to those of Steve Jobs7.

28 AGILE ALMANAC: Single Team Projects & Exam Prep

PMI even seems to have acknowledged the increased demands and
complexity of the project management universe. ey moved beyond the
long-cherished Iron Triangle – time, cost, scope – that was a part of the first
three editions of the PMBOK® Guide. With the release of the PMBOK® Guide,
Fourth Edition, PMI took the traditional view of time, cost, scope, and added
quality, risk, and customer satisfaction. e triangle became a hexagon in
order to express the increased complexity that Project Managers now face in
the everyday world. Soon, Project Managers around the world will be
speaking about the “Hell-of-a-Hexagon” that replaced the “Iron Triangle.” (See
Figure 2.8)

Figure 2.8 | Iron Triangle vs. Hell-of-a-Hexagon

In 2012, PMI released a Pulse of the Profession In-depth Report, Organizational

Agility 2012 that said in part, “Slow economic growth and shiing global
market priorities have created a complex, risk-laden business environment –
one that rewards innovation yet also threatens to derail projects.” e annual
global study of more than 1,000 project, program and portfolio managers
continued, “Such a turbulent environment demands organizational agility. To
forge that agility, successful organizations are aggressively reshaping their
culture and business practices on a three-pronged front:

• Rigorous change management to better adapt to shiing market

conditions
• More collaborative and robust risk management
• Increased use of standardized project, program and portfolio practices

e report reveals a clear payoff saying, “Highly agile organizations are twice

CHAPTER 2: Agile from a PMP®’s Perspective 29

as likely to see increased success with their new initiatives as their
counterparts with low agility.”

Beyond PMI, there is an abundance of additional evidence pointing to the

added complexity faced by Project Managers. Consider the high project
failure rates documented over the last couple of decades by the Standish
Group in the aptly named CHAOS Reports8. Also consider the Standish
report proved only 20% of the features being delivered to users are in the
“Always” or “Oen Used” categories, while 16% are “Sometimes Used,” and a
full 64% fall into the “Rarely” and “Never Used” categories.

In Built to Last9, the authors wanted to answer the question, “What makes
truly exceptional companies different?” One core discovery was that
exceptional companies had an unchanging foundation complemented by
strategies and practices that change in response to marketplace realities.

In today’s challenging economic times, organizational agility is definitely

necessary and best executed on a firm foundation.

Recommended Reading
Effective Project Management: Traditional, Agile, Extreme, by Robert K. Wysocki (Wiley; December 2013)

30 AGILE ALMANAC: Single Team Projects & Exam Prep

Answers – Terminology Matching
1:J, 2:D, 3:B, 4:H, 5:C, 6:A, 7:F, 8:E, 9:G, 10:I

Chapter End Notes

3
German Field Marshal Helmuth Graf von Moltke (1800 – 1891) was chief of staff for the Prussian Army
and is revered as one of the great military strategists of the latter 19th century.
4
William Edwards Deming (October 14, 1900 – December 20, 1993) is perhaps best known for his work in
Japan. He taught how to improve product quality through the application of statistical methods. Deming
made a significant contribution to Japan's later reputation for innovative high-quality products. Despite
being a hero in Japan, he was only beginning to be recognized in the U.S. at the time of his death.
5
Goldratt, E. M., Critical Chain. Great Barrington, MA: e North River Press (1997) and eory of
Constraints. Great Barrington, MA: e North River Press (1999).
6
Goldratt, E. M. (1997). Critical Chain. Great Barrington, MA: e North River Press.
7
Steven Paul "Steve" Jobs (February 24, 1955 – October 5, 2011) was a visionary widely recognized as a
charismatic pioneer of the personal computer revolution. He was co-founder, chairman, and chief
executive officer of Apple Inc.
8
See for example CHAOS 2009 Report Summary, Boston, MA, April 23, 2009, e Standish Group
International, Inc. (www.standishgroup.com)
9
Built to Last: Successful Habits of Visionary Companies by Jim Collins and Jerry I. Porras, HarperBusiness,
November 2, 2004

38 AGILE ALMANAC: Single Team Projects & Exam Prep

 CHAPTER

3
Agile Project Management
and Lean Principles
In the previous chapter, two quick, familiar examples were used to describe
Agile Project Management. In this chapter, a more complete discussion of the
Agile Lexicon, the Agile Manifesto, and the Principles behind the Agile
Manifesto (commonly called “e 12 Principles”) will be covered.

It will include an overview of Agile’s Micro-Dynamic Workflow and the

Micro-Dynamic Work Practices that are used, in common, by many of the
Agile Frameworks. ose work practices include such things as Minimal
Marketable Features (MMFs), Value-Driven Deliverables, Test Driven
Development (TDD), Operational Ceremonies, Actionable Reports, Osmotic
Communication and Agile Leadership.

Agile Lexicon – Methodologies, Frameworks

and Processes
A key point to be aware of is that the lexicon used in this book is the most
common taxonomy of methodologies, frameworks, and processes. However,
it is important to note that unlike Traditional Project
Management that has the authoritative PMBOK® Guide,
there are no similar governing standards in the Agile
sphere at this time. It is not unreasonable to expect that
standards for Agile will become part of the PMBOK®
Guide over time. e PMBOK® Guide Fih Edition
already includes some Agile content and it is likely
the PMBOK® Guide Sixth Edition will contain
significantly more.

CHAPTER 3: Agile Project Management and Lean Principles 39

 Frameworks are context-specific foundations created to support
particular industry settings, such as aerospace or automotive, or
particular categories of activities, such as soware or product
development. Frameworks have a set of Processes that are used to execute
work in a defined way.

Methodologies provide the philosophical foundation for organizing

Frameworks. In project management, the two dominant choices are
Traditional, as embodied in the PMBOK® Guide, and Agile.
Methodologies contain and define various Frameworks as context-specific
logical foundations.

Processes are practical “how to” protocols used to direct things like
sponsoring, organizing, funding, and controlling solution development
projects. e Processes guide work to follow or align with context-
specific best practices.

e best-known Agile Framework is Scrum. Each of the Agile Frameworks,

including Scrum, started in a specific context, such as soware development.
Each of the Frameworks strives to apply Lean principles to produce processes
that are appropriate to a context-specific environment.

Agile Manifesto and The 12 Principles

One of the seminal events in the rise of Agile Project Management occurred
in February 2001, at the Snowbird resort in Utah. Seventeen luminaries in
the field of soware development met to discuss the need for alternatives to
the project management processes that were producing failure-prone results.
Perhaps no one was more surprised than the participants themselves when
they achieved a meeting of the minds and all agreed to sign the Manifesto for
Agile Soware Development, now commonly referred to as the Agile
Manifesto.

e group named itself e Agile Alliance and published the Manifesto for
Agile Soware Development. It outlined fundamental beliefs that reinforce
Agile soware development, a precursor to Agile Project Management.

Manifesto for Agile Soware Development10

We are uncovering better ways of developing soware by doing it and
helping others do it. rough this work we have come to value:

40 AGILE ALMANAC: Single Team Projects & Exam Prep

 Individuals and interactions over processes and tools
Working soware over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
at is, while there is value in the items on the right, we value the items
on the le more.

Notice that the central word in the Agile Manifesto is “over.” e Manifesto
does not support the common, erroneous interpretations suggesting that it
supports individuals and interactions “instead of ” or “rejecting” processes
and tools. Great damage has been done to the potential of the Agile
movement by imposters claiming their focus is working soware “not”
comprehensive documentation, or customer collaboration “without needing”
contract negotiation, or responding to change “without” following a plan.
Proponents of such approaches are simply not Agile in spirit or in fact!

Understanding the Agile Manifesto

e Agile Manifesto is so widely published and well known that almost
anyone with an interest in Agile has seen it, read it or heard about it at least at
some level. Everybody seems to want to talk about it and some people try to
use it as an excuse for bad behavior. ose folks say things like, “I’m doing
Agile so I don’t do planning,” “I’m doing Agile so I don’t do reporting” or “I’m
doing Agile so I don’t do documentation.” at is not Agile. at is Agile as an
excuse for bad behavior.

is violates the core of the Manifesto. In fact, to understand the heart of
Agile, you need to notice it says, “We value these things on the le…”, and
there are four values listed. en it says, “Over these things on the right” and
lists four other values. at construction makes the word “over” very
important. It doesn’t say “in rejection of ” or “in refusal of ” the values on the
right. It says “over” right there in the middle. What “over” implies, on some
level, is the things on the le help us better understand and apply the things
on the right.

It says, “We value individuals and interactions over processes and tools” and
experience shows that the correct processes and tools cannot be selected and
applied, especially when dealing with work that has high complexity and high
uncertainty, unless you know who the individuals are and what interactions
they need to have. Knowing who the team and customers are guides the
process of selecting the correct processes and tools.

CHAPTER 3: Agile Project Management and Lean Principles 41

To be successful it is imperative to ask discovery questions like, “Who are my
stakeholders and what feedback do they need? Who is my core customer or
my voice of the customer and what information do they need to have? Who is
on the team and what is the work composed of?”

e second ‘P’ in PMP stands for professional and our organizations expect
us to be professional enough to ask discovery questions to guide the team to
the best choices for executing this project.

e next statement says, “Working soware over comprehensive

documentation.” It says soware because the seventeen folks who were in
Snowbird and signed the Manifesto all happen to be from the soware
industry. Today it could easily say, “Working solutions” because it is being
used in so many different environments.

If you think that Agile is soware only, you are talking about Agile a decade
ago. Today, Agile is in all kinds of industries. Agile helps us create competitive
advantage and that is what organizations really care about.

You can go right down the Manifesto. Customer collaboration over contract
negotiation doesn’t mean not to use contracts. at would be silly. It’s the real
world aer all. Lean would say that contracts are an unavoidable waste and to
minimize unavoidable waste. e Manifesto implies the desire to minimize
waste by using the contract to develop a collaborative relationship with the
customer wherever possible.

Finally it says, “Responding to change over following a plan.” It doesn’t say or

even imply not to have a plan. It acknowledges that the plan is going to
encounter the enemy. And by the way, the enemy is not your co-workers or
your customers. e enemy is the complexity and the uncertainty.
Encountering the enemy means discovery and learning by the Customer and
Team can be leveraged and the plan will be adjusted to cope with those
potentially good things as well as challenges.

One last thought about Agile and the Manifesto worth noting is that despite
the reverential awe of some of the Agile faithful, Agile is not a magic wand. If
a senior manager is insistent on creating chaos, Agile won’t fix him. Agile may
offer tools that are better able to manage the environment in spite of him, but
it is not going to eliminate him. ere are situational variables that Agile can’t
do anything about. Agile can help put a frame around it perhaps, create better
value in spite of it perhaps, but it is not a magic wand.

42 AGILE ALMANAC: Single Team Projects & Exam Prep

Principles Behind the Agile Manifesto
e Agile Alliance also published the Principles behind the Agile Manifesto,
which stated the following.

“We follow these principles:

Our highest priority is to satisfy the customer through early and

continuous delivery of valuable soware.

Welcome changing requirements, even late in development. Agile

processes harness change for the customer’s competitive advantage.

Deliver working soware frequently, from a couple of weeks to a couple

of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout

the project.

Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job done.

e most efficient and effective method of conveying information to and

within a development team is face-to-face conversation.

Working soware is the primary measure of progress.

Agile processes promote sustainable development. e sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.

Continuous attention to technical excellence and good design enhances

Agility.

Simplicity – the art of maximizing the amount of work not done – is

essential.

e best architectures, requirements, and designs emerge from self-

organizing teams.

At regular intervals, the team reflects on how to become more effective,

then tunes and adjusts its behavior accordingly.”

ese principles address various aspects of the fact that good communication

CHAPTER 3: Agile Project Management and Lean Principles 43

does not occur automatically and must be deliberately cultivated. Something
about being human makes communicating unavoidably complex.

at fact has been observed hundreds of times during a simple exercise,
called the “Stare and Share,” conducted at numerous training seminars. e
exercise has three steps. In Step 1, all participants are asked to stand, choose a
partner, and face that partner. ey are then given 20 seconds (which always
seems like a lifetime to the participants) to “visually study their partner.” In
Step 2, they are instructed to stand with their backs turned so they cannot see
each other, and change three things about their appearance. In Step 3, they
are asked to turn so they can each see their partner once again, then identify
the three changes their partner made. At no time are the participants told not
to collaborate, and they are even referred to as “partners” repeatedly
throughout the instructions. Nevertheless, there are normally less than one-
third of the participants who identify all three changes, and less than five
percent who ask for, or reveal, the changes to one another.

is human trait impacts many project teams. Critical information –

information vital to success – will not be shared automatically, unless the people
assigned to the project unite as a team. Commitment to one another’s success
does not begin until a team is born! Catalyzing as a team, therefore, is critical to
success and only happens when communication is properly facilitated.

So the quantitative goal of having collocated, cross-functional, trusted teams

is to reduce project risk by reducing the unknown about the project. e
situation before a team catalyzes can be seen in Figure 3.1. e illustration
shows that as long as the
project is worked on by a group
of people who have not become
a Team, the relationship
between what is known and
unknown remains static. at
produces a significant “blind
spot,” where things that are not
known by the PM overlap with
things that are not known by
the team (i.e., the bottom right
quadrant).

e situation aer a team

Figure 3.1| Risk Before Team Formation catalyzes can be seen in the

44 AGILE ALMANAC: Single Team Projects & Exam Prep

 next illustration, Figure 3.2.
When a team environment
exists, everyone is committed to
being responsible for the
project’s success or failure. at
is because relationships formed
when the Team made the hard
commitment to the Iteration
goal (a process that will be
explained later). ose
relationships engage everyone to
remain vigilant, watching for
areas of risk “owned” by other
Team members – as naturally as
Figure 3.2| Risk Aer Team Formation soldiers covering each other’s
back in combat. Most
importantly, the automatic disclosure of observations, insights, and
information occurs.
is reduces the resulting blind spot, increasing the general level of
knowledge about the project. e way this happens can almost be described
as triangulation. As members of the team share what they know or have
learned, other members can integrate that with their knowledge base then
share observations and insights. In the process, risks that had been
unrecognized, and therefore unknown, are identified by triangulating their
position. is occurs much like the navigation of early mariners using a
sextant and the stars. Two data points are used to help identify a third.
Precisely because trusted, cross-functional teams supply a mix of skills, risk
and errors are reduced. So risk is diminished and the opportunity for success
is enhanced. In the Agile ethos, empowering teams is central to realizing the
goal of a successful project

Agile Micro-Dynamic Workflow

As noted earlier, the Agile domain can be divided into three levels. ey are
Single-team Projects, Programs with Multi- and Virtual-team Environments,
and finally, Portfolios and Enterprise Scaling. is book is focused on the
needs of individual practitioners working on Single-team Projects and that is
defined as the micro-dynamic environment. It provides detailed insight and
analysis on when and how to use the “Big 5” approaches. It does not extend
into the macro-dynamic of Programs, Portfolios and Enterprises.

CHAPTER 3: Agile Project Management and Lean Principles 45

Micro-Dynamic Team-level Workflow
Agile, at the team or micro-
dynamic level, starts with the
concept that all the
information about the project
is directed to the Customer-
Proxy (Figure 3.3), sometimes
called the “Voice of the
Customer” or the Product
Owner. e Customer-Proxy
is responsible for knowing
what the customer wants and
deciding on the Product
Roadmap that defines what is
most important and will be
developed first. us, all
information related to the
project is directed to them
and they use it to organize the
Product Backlog. e concept
of a Product Backlog in Agile
is similar to the concept of
requirements or specifications
in Traditional Project
Figure 3.3| Customer-Proxy Management.

It is worth noting that the funnel above the Customer-Proxy’s head that is
commonly used to illustrate this concept implies that there is some
organizational structure in place to direct that information to the Customer-
Proxy. Many Agile evangelists present Agile as if it exists in a world where the
organization doesn't provide structure and rules, yet that's just not the real
world. e funnel illustration directly disputes the belief that Agile and
organizational structure are incompatible.

e Customer-Proxy takes this information and creates the Product Backlog

(Figure 3.4). It includes information about the features, functions, and
capabilities that need to be developed in order to successfully deliver the final
outcome. Notice that the image of the backlog looks like a stack of index
cards. e intent is that one requirement, function or capability is on each
card so that the Customer-Proxy can prioritize them. e Customer-Proxy

46 AGILE ALMANAC: Single Team Projects & Exam Prep

 does so by sorting the
most important ones to
the top of the stack and
pushing the less
important ones to the
bottom of the stack. e
idea is that the
Customer-Proxy will
continuously groom the
Backlog. is sorting
process is an important
step that precedes the
planning session
occurring at the
beginning of each
Iteration or Sprint. at
planning session is the
next step in the process.
It determines what the
Team can and will be
responsible for building
Figure 3.4| Product Backlog as the next step towards
the final solution.

e Customer-Proxy submits what is most important for the customer to see

as the next piece of the puzzle to develop. e approach is a negotiation where
the Customer-Proxy and Team define an outcome that is both valuable and
doable. When they reach agreement it is called the goal of the Iteration or
Sprint. e goal is documented with Stories in the Iteration or Sprint Backlog
(Figure 3.5). It can be visualized as if the Customer-Proxy takes the top of the
Product Backlog stack, the most important stories for the customer to see,
and brings it to the Team and says, "is is what I think you can build as the
next subassembly of the puzzle, as the next piece of the solution, during this
next timebox.” e Team then asks clarifying questions like, "Does it include
wireframes or final forms? What about load testing? Does it need a security
audit?” If you’re developing soware, you know one of the questions that
always come up is, “Does it include documentation?” Because programmers
love creating documentation, right?

e clarifying questions make sure the Team gets a clear idea of what the
Customer-Proxy wants them to build. Sometimes the Customer-Proxy says,

CHAPTER 3: Agile Project Management and Lean Principles 47

Figure 3.5| Iteration Backlog

"What I want you to build is just a rough cut, a wire frame, of this part of the
solution because I need to show it to some customers and get their feedback.
en, while you’re working on other pieces that I am certain about in the next
two Iterations, I will define detailed Stories of what should or should not be
included based on the customer feedback.”

Another common occurrence during the discussion is that the Team will say,
"Wait a minute, Story number 3 is a good priority, but we can't build it
without that infrastructure piece that you’ve prioritized as number 19 and le
behind. So do you want to pull number 19 into this Iteration, and take
something the same size out of the proposed Iteration Backlog or do you want
to put number 3 back and wait until number 19 reaches the top of the stack?"
e discussion is a collegial effort to figure out what can actually be built
during the Iteration that will drive the most value because of the insight it will
create for the customer. We call that, “Actionable insight!”

is process of developing subassemblies of the solution for the customer to

see is particularly powerful with customers who do not understand perfectly
clearly what they need and want. ose customers who say, "I don't know
what I need, but I will know it when I see it." I will know it when I see it is
referred to as “IKIWISI” (pronounced, “icky-whizzy”). Customers are not
trying to be difficult when they say or imply IKIWISI, they are just being

48 AGILE ALMANAC: Single Team Projects & Exam Prep

human. ey don't know exactly so they are searching for the right answer
and seeing pieces of the puzzle helps them figure it out. Agile engages and
enables the humanity of each member of the triad – the Customer, the
Customer-Proxy and the Team.

Once a joint decision is made, the Team commits to what will be developed in
this next Iteration and the Customer-Proxy, on behalf of the Customer and
Organization, commits to not change the goal or size of the timebox.
Typically the process is done in two steps. Step One is where the Team makes
the “So Commit” and says, “Yes, we think we can do the proposed Iteration
Backlog.” en aer an hour or two of analysis where they tear apart the
Stories and break them into Tasks, if they are confident they can do it, they
make the “Hard Commit.”

e Hard Commit creates the Reciprocal Commitment. As noted above, on

behalf of the organization, the Customer-Proxy says, “We won't change the
time period, you get the whole four weeks. We won’t change the goal, we have
now set in stone what you are going to build, and we also won't molest, harass
or interrupt.”

During presentations to many hundreds of audiences with many thousands of

participants, two simple truths have surfaces universal. First, there is not one
best way to do every project. Not Agile, not Traditional, not any one way.
Second, for every project Team there is one best way to execute any particular
project based on the goal, the resources available, the constraints, and the
context of the project. e process goal is to figure out the one best way for
this Team to use the next Iteration to make measurable progress towards the
project goal.

Crystalizing and freezing the Iteration goal creates an environment where the
priorities don’t change weekly, which is the only way to succeed. One of the
reasons many teams love Agile is because they get to focus and deliver
something, a concrete outcome, and then stand up and say, “Hey we
succeeded!” For the Team, it feels like standing up in front of the room and
singing like rock stars, "We are the champions!"

So when that Reciprocal Commitment happens, the Iteration begins (Figure

3.6). During that timebox, the Team completes Tasks and has a 15-minute
meeting to stay synchronized. e meeting can be called a Daily Stand-up
Meeting, Daily Meeting or Scrum Meeting.

CHAPTER 3: Agile Project Management and Lean Principles 49

Figure 3.6| Iteration Begins

e meeting helps insure progress keeps moving forward by having each

Team member answer three questions. “What have I worked on since
yesterday?” “What will I work on today?” ose two answers synchronize the
team. en the third question, “What obstacles, if any, are impeding my
ability to move forward?” alerts the team facilitator about obstacles outside of
the team’s authority that are slowing or stopping progress towards the
Iteration goal. e team facilitator, usually a Scrum Master or Project
Manager, accepts responsibility for removing the obstacle.

One core Lean principle is that development processes have work periods and
wait periods, and wait periods are an avoidable type of waste. Work gets
completed by one person then waits in the next person’s inbox. Work period.
Wait period. Work and wait over and over again until it is finished. e daily
synchronization meeting limits, minimizes, or even eliminates a lot of wait
time, eliminating a lot of waste.

Consider this simple analogy. If you are running a Traditional project and you
do your Status Report meetings on the 15th and the 30th of the month, what
are the two most productive days of the month for your team?" e 14th and
29th, right?! If you do your status report meeting on Friday, what is the most
productive day of the week? ursday is the most productive without fail.
When you were a student in college, what were the most productive days of
the semester? Right before the exam and right before the paper was due.

So waiting is an innately human thing. When we do our status report

meetings infrequently there is a big spike then a lull, a big spike then a lull. It’s
a cycle. If Randy and I have our Status Report Meeting every Friday, and on

50 AGILE ALMANAC: Single Team Projects & Exam Prep

Monday I realize I need something from Randy, what do you think is likely to
happen? Whether his cubicle is a hundred feet down the hallway, a floor or
two away, across the parking lot, across town, or across country, I’ll wait until
Friday to ask for what I need. e further the distance, the higher the
probability that our project and my deliverable will stay in the inbox until
Friday and at Friday’s Status Meeting I’ll report, “I needed a thingy-bob from
Randy so I didn't get anything done this week." Now, the project schedule just
got hammered with a week of wait time!

Daily meetings eliminate a lot of wait time waste. ey are very effective and
can be done in 15 minutes with the right rules and techniques for managing
them. We’ll share those rules and techniques with you later.

e outcome of this process at the end of the Iteration is referred to as a

Potentially Shippable Product (Figure 3.7). Please notice the word Potentially.
It doesn't mean that it's actually shippable. But it does mean that we can show
it to the customer or present it to the stakeholders so they can give feedback
and input. at actionable insight keeps progress focused and on target. It
helps resolve IKIWISI. at's really where agility comes from. at’s really
what Agile is striving for, to eliminate waste.

As the Potentially Shippable Product is being developed, the Team is sharing

their progress with the Customer-Proxy. e final delivery of the Potentially
Shippable Product is not a surprise to the Customer-Proxy at the end.
Development has been receiving guidance from the Customer-Proxy during
on-going conversations with the Team. e Customer-Proxy is giving
feedback to questions from the Team. Questions such as, “Is this what you
meant?” “Did that fit?” “Is this right?”

Figure 3.7| Potentially Shippable Product is delivered

CHAPTER 3: Agile Project Management and Lean Principles 51

When the Iteration ends, the Customer-Proxy and Team are in agreement
that either the delivery is the Potentially Shippable Product promised during
the Iteration planning meeting or not. Sometimes a Story couldn’t be
developed, and even though that's an exception, everyone admits to that
being the outcome.

e Iteration ends with the Customer-Proxy and Team presenting the

completed deliverable at the Review Meeting (Figure 3.8). e Review
Meeting is a product-centric meeting where any interested or impacted
stakeholder can come and see what was just finished as the next piece of the
project puzzle. ey give feedback and ask questions that produce actionable
insight for the Customer-Proxy to use to groom the Product Backlog.

TEAM

Figure 3.8| Review meeting

Following the Review Meeting, the Team holds a closed-door meeting just for
them called a Retrospective Meeting (Figure 3.9). e Retrospective Meeting
is a process-centric meeting where the Team, with nobody else present, talks
about the development process. It is the application of the Lean principle of
continuous improvement. Essentially the Team asks itself, “How could we
improve our process so that we could deliver more results easier, faster, better,
cheaper, and have a few more laughs along the way?”
One way to understand the Retrospective Meeting is to compare it to a
Lessons Learned meeting done for a Traditional project at the end of 12, 18,
or 24 months. e meetings that are commonly referred to as a “Project Post-
mortem.” What a great term! It reflects the feeling that the Team will cut the
project cadaver open, find stinky stuff to blame on others, and stick it on
them and ruin their career. We all know that knowledge is power. But

52 AGILE ALMANAC: Single Team Projects & Exam Prep

 ITERATION

No Changes In
Duration Or Goal

RETROSPECTIVE
MEETING

Figure 3.9| Retrospective Meeting

knowledge is only power if it's applied and shared. Teams don't get applied
knowledge if they wait a year or two to do Lessons Learned. It does not
generate shared learning if it is understood as a blaming session. at process
simply doesn't work.

A process that does work is Retrospective Meetings. At the end of every

Iteration, usually every 4 weeks or less, while the Team’s memories are still
fresh, they have a Retrospective Meeting. ey identify, discuss and select
ideas that they like and think will improve the process and start using those
things the very next day. is creates a very big WIIFM. e big “What's in it
for me (WIIFM)?” for the Team is that they get to use those ideas
immediately to improve their environment.

Agile’s micro-dynamic Team-level workflow, as just described, is a model that

provides amazing power and results when dealing with project environments
containing high degrees of complexity and uncertainty. One simple, yet
brilliant, key that makes it powerful is that it creates and maintains a focus on
measuring actual progress towards the goal. It defines actual progress as
completed Potentially Shippable increments, so that is the unit of measure. It
avoids the trap of trying to measure effort or cost or some other variable as a
corollary of progress because other units of measure have all proven to be
unreliable and flawed.

A second, brilliant key to its success is that it maintains flexibility regarding

the logical flow being used for setting the order of development steps while

CHAPTER 3: Agile Project Management and Lean Principles 53

honoring the rigid boundaries of the contract and the need for a stable work
environment for the Team. is elegant integration of embracing change
while enforcing stability is oen misunderstood and poorly explained. But
that elegant integration is still a dazzling insight!

Micro-Dynamic Roles
To best understand the roles involved in the Agile micro-dynamic team-level
workflow it is useful to begin by comparing them to the various projects roles
in a Traditional project.

e highest-level roles in both Traditional and Agile methodologies are

Stakeholders and Sponsors. ey define the business case that sets the project
objectives, explain how it is aligned to the organization’s strategic intent, and
most importantly, control the funding.

At the next level down in Traditional methods the role is a Senior Project
Manager or Program Manager, which is comparable to a Customer-Proxy in
Agile methods. e roles are not exactly the same, but they have a rough
approximation of the same responsibilities. What the roles share in common
is the focus on answering the question, “What does the project have to do to
deliver value to the customer and to the organization?”

e third-level role in Traditional methods is Technical Lead or Team Lead,

which is comparable to a Scrum Master in Agile methods. Again, they have
approximately the same duties and interest. What the roles share in common
is the focus on solving the technical challenge, putting together the next piece
of the technical puzzle, and doing it one Iteration aer another. Focusing on
how to create the next Potentially Shippable deliverable keeps the work results
moving towards the solution.

At the fourth level in both Traditional and Agile methods, is the role of Team
members who are Subject Matter Experts (SMEs). ese are the people who
do the tasks required to complete the development work of the project.

Finally, below that is the role for anyone else who is impacted by or interested
in the project outcome, but do not set the objectives or control the funding.

Whether a project is being managed using a Traditional, Agile or Hybrid

approach, the people who inhabit the world of the project don’t change. And
since it’s really true that the people drive the complexity and the uncertainty,
learning to leverage and take advantage of that humanity instead of trying to
contain it is one of the biggest keys to success.

54 AGILE ALMANAC: Single Team Projects & Exam Prep

And that’s why the popular notion that everybody’s got to be a generalist not a
specialist, able to do everything and be perfectly interchangeable does not
pass the sniffer test. Can you imagine a National Basketball Association
coach, a Major League Baseball coach or a World Cup soccer coach saying,
“Just send in a player! ey are all the same. Any player will do.” In the real
world it doesn’t work that way.

What makes far more sense is not for a Developer to become a QA person,
and vice-versa, but instead to recognize that the Team is running a relay race.
In a relay race, strengthening the hand-offs is the key to success. is
leverages human potential instead of constraining it!

Take a moment and think of a relay race at the Olympics. It is not always the
team with the fastest runners that wins, but it is always a team that didn’t drop
the baton. So Developers and QA teammates need to be in enough
conversation about their process so that the depth and strength of the interface,
the point where the baton hand off happens, is being continuously improved.
As the Developer becomes more QA aware and the QA person becomes more
development aware, the strength and depth of the hand off grows.

People are hired based on their expertise and experience that can be defined
as tacit knowledge. e tacit knowledge in their head is an asset that we hire,
but then becomes a liability for the organization if that person wins the lottery
or gets hit by a bus and never comes back to work. at is especially true if
that person is an information hoarder.

When we treat the team process as running a relay race and the strength of
the hand-off, that is the depth of interface between the Developer and QA
person increases, then that tacit knowledge becomes tribal knowledge. Tribal
knowledge means that when a new Developer is hired, the QA person who
knows more because of the stronger interface can integrate and onboard the
Developer so the team returns to productivity more quickly. at tribal
knowledge reduces the liability that is otherwise inherent in the system. e
goal is not generalists, but better integrated experts.

Micro-Dynamic Environment
e need for an Iterative Development Framework and an integrated, cross-
functional team of experts is driven by the complexity and uncertainty that
fill the micro-dynamic environment. at high level of complexity and
uncertainty presupposes that an accurate understanding of the problem and
its solution cannot exist in advance.

CHAPTER 3: Agile Project Management and Lean Principles 55

Millennia of human experience have shown that complexity and uncertainty
also amplify the unavoidable and inevitable effect of time as planning attempts
to peer into the future. e farther into the future planning attempts to peer,
the more inexact, vague, and unreliable perceptions and forecasts get because
more and more complexity and uncertainty are unavoidably introduced.

Regardless of how much time and money is spent on creating highly precise
descriptions and highly engineered estimates, it all proves to be part of the
waste stream, as far as Lean is concerned, because it does not increase the
accuracy or reliability of planning activities.

Figure 3.10| Cone of Uncertainty

Despite the dire sounding challenge of the micro-dynamic environment,

there is an answer. e answer is to integrate the inescapable need for
discovery and learning into the development process. e process must be
designed to make progress through the unknown and unexpected challenges
of development that is called the Cone of Uncertainty (Figure 3.10).

Cone of Uncertainty refers to the concept of how unknown facets of a

problem decrease over time as customers traverse through an
unavoidable, ambiguous process where discovery and learning occur.

e Cone of Uncertainty shows that at the beginning of development, the

degree of uncertainty is very large and a straight line of development cannot
be defined. Instead, development must begin with what little is known for
certain and begin producing deliverables that can be inspected by the
customer or exposed to tests that will produce actionable insight into how to

56 AGILE ALMANAC: Single Team Projects & Exam Prep

 Figure 3.11| Narrowing the Cone of Uncertainty

make the next move towards the solution. is method of development
applies the scientifically validated empirical process control approach –
transparency, inspection, and adaptation.

e goal is to narrow the Cone of Uncertainty by leveraging discovery and

learning at each of the points marked with an “X” in Figure 3.11. Inspecting
and adapting at those points will pivot decision-making towards the solution
instead of continuing on the standard trajectory towards the outer limit of the
Cone of Uncertainty.

Conceptually this is quite simple to understand, but that does not mean that
the practical application is easy. It requires transparency in admitting what is
unknown or uncertain followed by sometimes-vigorous debate about how to
best inspect or test the deliverable. And finally it requires the courage to adapt
development or customer expectations to the reality that is discovered.

Evidence from many projects suggests that most customers need an

opportunity to interact with the solution in order to clarify their own
understanding of the problem and accurately define the best solution.

While customers interact with the periodic Potentially Shippable

deliverables, their understanding of the best solution moves from what they
thought at the beginning to what they really need. Stakeholders, because of
the limits of their humanity, need to be meaningfully engaged with the
deliverables in order to move through the Cone of Uncertainty and find the
optimal solution.

CHAPTER 3: Agile Project Management and Lean Principles 57

Micro-Dynamic Work Practices
Various Agile and Traditional frameworks have common Work Practices even
when they use a different lexicon to name or describe them. is section will
explain the most prominent ones and when each Framework is covered in
depth, this content will be referenced. By explaining it here and reminding
you later it will save you from having to read the same content over and over
in each Deep Dive section.

Stakeholders and Minimal Marketable Features (MMF)

Establishing the project goal focuses all the trade-off and resource
management decisions on making actual, measurable progress within a
reasonable time. e key Stakeholders and the Sponsor define the goal in
terms of the Minimal Marketable Features (MMF) that must be included.
Ideally, they also prioritize them so that customer value drives the
development schedule first, and efficiency of development drives it second.

For many Sponsors and Stakeholders a primary goal is to create a competitive

advantage, oen by being first to market. Being a first mover creates the
opportunity to capture massive market share, generate premium pricing
margins, and possibly enjoy cost savings. In order to achieve the goal of being
first to market it is oen necessary to tightly focus the project on quickly
delivering an important set of MMFs.

Identifying and refining the project focus down to the MMFs also provides an
early and important opportunity to engage Stakeholders in the participatory
decision-making style that is central to Agile.

Minimum Marketable Features are defined as the smallest set of

features providing enough functionality to fulfill the customer’s
expectations and create a desired level of engagement (i.e., consumer
purchases or constituent votes).

Consider this analogy. Ford could build and sell a car more cheaply by not
including a steering wheel or a transmission. But they probably wouldn’t sell
very many because, for most consumers, a steering wheel and a transmission
are part of the MMFs of any car they want to buy. Conversely, Ford could
produce and sell a car for less money if it had no body and no windshield. e
car would have a chassis, transmission, steering wheel, seats, and engine, but
no body or glass. It would function, but would they sell any? Interestingly,
such vehicles are called dune buggies and are used for riding in the desert. In

58 AGILE ALMANAC: Single Team Projects & Exam Prep

order to ride on the sand and not sink, dune buggies need to be light so not
having a body is part of the MMFs because it reduces weight.

e key to defining MMFs is to understand the market, understand who the

customer is, and help that customer define what is in their MMF.

e process that the Stakeholders and Sponsors use to define the MMFs oen
precedes and is separate from the project management process. However, in
both Traditional and Agile Frameworks, an initial activity is to integrate it.
at activity is called Project Chartering or Visioning, in Traditional and
Agile Frameworks, respectively.

e Customer-Proxy uses the MMFs, in part, to understand what the

customer wants. en based on that understanding, the Customer-Proxy
defines a Product Roadmap that expresses what is most important and
schedules it to be developed first because it is the most important. Depending
on the level of granularity, a Roadmap is equivalent to a Program plan or a
Project plan in Traditional Frameworks.

Identifying and refining the project focus down to the MMFs provides an
early and important opportunity to engage Stakeholders in participatory
decision-making.

Value-Driven Deliverables
Defining MMFs is one approach used to help stakeholders clarify and
articulate their goal. Another method used to help stakeholders identify
desirable objectives is Value Stream Mapping, a technique developed in Lean
manufacturing.

Value Stream Mapping is a process that analyzes, and potentially

redesigns, the flow of materials and information used to deliver a
product or service to the customer in order to reduce the total time
required from beginning to end of the production stream without taking
shortcuts at the expense of future opportunities.

While there are various permutations, the basic Value Stream Mapping
process consists of the following steps:

• Identify the Value Stream Target. e target is a particular product or

service (sometimes a product or service group, family or category)
where improvement can provide strategic and competitive advantage.

CHAPTER 3: Agile Project Management and Lean Principles 59

 • Define the Current State. Identifying the current state of the Value
Stream is accomplished by creating a “map” or diagram showing the
current process. e map illustrates the productive steps and
accompanying information inputs required to deliver the product or
service. It also identifies unproductive steps such as lead-time, delays,
queuing time, or holds. For tangible products, the flow will show
everything from acquiring the raw materials to customer receipt of the
product. For intangible products, the flow will show everything from
design concept to launch of the service or delivery of the product, such
as a financial instrument or soware.

• Clarify the Current Opportunity. Opportunities to eliminate waste

(e.g., waiting time, delays, queuing, or holds) and thereby raise customer
satisfaction and enhance competitive advantage with faster delivery and
better quality and fit are clarified by analyzing the current-state Value
Stream Map.

• Depict the Desired Future State. Once the current state has been
properly analyzed, a desired future-state value stream map is
documented. en that map is used to implement a plan to transform
the current workflow into the desired future state.

Value Stream Mapping is part of the recognized Six Sigma methodologies.

While in the past Value Stream Mapping was most oen associated with
manufacturing, it has begun to see widespread use in industries as varied as
logistics, healthcare, and soware development for establishing Value-Driven
delivery processes.

Value Stream Mapping can also be linked to high-level architectural outlines.

Such outlines may be needed to facilitate planning for the initial Iteration (aka
“Just Enough”), guide architectural and engineering activities during
subsequent Iterations (aka “Just In Time”), and meet any regulatory
requirements (aka “Just Because”). Architectural outlines must be adequate
to guide emergent design and incremental delivery of business value.

e test of Value-Driven deliverables is whether a releasable product reflects

the product vision and meets the acceptance criteria (and related metrics)
defined by the Customer-Proxy.

At Intel®, where such a process has been successfully institutionalized to

create a continuous flow of innovative breakthroughs for multiple decades,

60 AGILE ALMANAC: Single Team Projects & Exam Prep

they call it “MAPP Day.” MAPP stands for Make A Project (or Program)
Plan. It is so important that Intel® has dedicated facilitators who guide the
MAPP Day process.11

Intel® has demonstrated that establishing a Value-Driven delivery process,

while neither quick nor painless, is well worth the investment. While it is not
easy, it is amazingly effective when the right tools are employed and
accompanied by adequate training and process standards.

e purpose of a value-driven development process is to help stakeholders

clarify and articulate their priorities early in the project management process.
ree additional tools commonly used are the Product Vision Box, the
Project Data Sheet, and the Flexibility Matrix.12

Product Vision Boxes are a graphical expression of the solution that

includes whatever images and narrative content is necessary to convey
what the customer expects from the product. e content is expressed
in end user language and not techno-jargon.

Project Data Sheets (PDS) capture a project’s objectives in a one-page

summary of the key objectives, capabilities, and information needed to
understand the purpose and progress of the project. e PDS is a
minimalist document.13

Flexibility Matrices are a simple tool that help the Customer-Proxy

communicate to the Team how to handle the unavoidable tradeoffs
arising during solution development. e matrix clarifies which
constraints are flexible and which are not, hence the name. It is a top-level
decision-making tool for guiding tradeoff decisions when resource, time, or
cost conflicts arise during execution.

Test-Driven Development (TDD)

e experience of teaching thousands of students has shown that sharing a
couple of quick, common, everyday examples of Test Driven Development
(TDD) creates a useful mental map for applying it in greater depth. Of
course, the challenge with familiar examples is that they are not perfect
analogies. ey get your thinking started in the right direction, but they
inherently fall victim to the pitfalls of oversimplifying complexity.
Nonetheless, these three examples will help kick start the thinking process. If
you already understand TDD then you should skip these examples because
they might muddy the expertise you have already acquired.

CHAPTER 3: Agile Project Management and Lean Principles 61

 Example #1
You are considering going out to dinner with your friends. You define a
test such as, “Is my appetite satisfied?” For this example we will assume
the answer is no because you are hungry. Failing that test means you need
to do something. You decide to meet your friends at your favorite place
and have a meal. Aerwards you run the test again, “Is my appetite
satisfied?” and the answer is yes. You have passed the test so the solution
worked.

Example #2
You are considering buying a car. You define a test such as, “Is my current
mode of transportation satisfactory?” Since the answer is no, failing that
test means you need to do something. You decide to go car shopping and
aer 13 grueling hours of searching, negotiating and getting a loan, you
drive off in the perfect new car. Aerwards you run the test again, “Is my
current mode of transportation satisfactory?” and the answer is yes. You
have passed the test so the solution worked.

Example #3
You buy a book to study TDD and want to validate that you actually learn
something. To do so you create a quiz by writing questions on the
material you want to learn about TDD. Examples could include “What
does TDD stand for?” or “What profession typically uses TDD?” en you
take the counter-intuitive step that is at the heart of TDD. You actually
take the quiz you just developed. “Wait, what?” you say. at's right, you
take the quiz and fail, but that's okay (excellent even) because you weren’t
suppose to know the answers! Next, you read the book you bought.
Aerwards you take the quiz again and pass. Voila! You just used TDD
to learn about TDD. (And who said you aren’t one sharp cookie?)

For the average student, the most confusing concept of TDD is only confusing
because of the awkward way it is usually stated. When TDD is described it is
usually some form of, “Define a test, fail the test, and then write code until the
test is passed.” To which the average person says, “Huh?!? Come again! Write
a test just to fail it!?!”

e first two examples above showed TDD in familiar, everyday situations.

And the third example illustrated TDD using the formula [Create Well-
Defined Test] then [Take Test and Fail] then [Do Something] then [Take Test
and Pass]. Of course, if the step aer [Do Something] turns out to be [Take

62 AGILE ALMANAC: Single Team Projects & Exam Prep

Test and Fail] then you must [Do Something (Again)] until you reach [Take
Test and Pass]. (Figure 3.12)

PASS TEST; DEFINE NEXT TEST

ALL TESTS
CREATE WELL- TAKE FAIL DO TAKE PASSED;
DEFINED TEST TEST TEST SOMETHING TEST RELEASE TO
PRODUCTION
PASS TEST; FAIL TEST
DEFINE NEXT TEST
TDD PROCESS FLOW

Figure 3.12| Test-Driven Development (TDD)

Test-driven development (TDD) is a four-step process that begins with

creating a well-defined test, then invoking an operation to take the test
and having a “fail” outcome, followed by doing something to change the
operation, and finally invoking the modified operation to take the test and
having a “pass” outcome.
Once the common confusion just described has been overcome, the
challenging part of TDD comes to the surface. Applying it becomes
challenging in situations that seem to have a large number of variables, which
describes a great many projects. But TDD can be used for projects because it
can be extended as a series of tests in situations with high complexity. In
those situations, defining a testing architecture as a decision tree can be
useful. However choosing the first test questions can be very challenging. It
will require enough subject matter expertise to prioritize the tests so they
align with the overall project objectives and cost-effectively reduce risks.
Luckily, the power of self-directed, cross-functional teams helps a great deal.
As the possible schema for prioritizing the test questions is discussed, it is not
uncommon to hear someone say, “Why didn't I think of that approach as an
option?” Or, “Hey you can't use that tactic because of the F.D.A. regulations.”
e good news is that as the Team develops expertise in choosing testing
schema appropriate to their environment, TDD becomes rather intuitive and
moves the Team through the Cone of Uncertainty surrounding the project.
Drawing on its Lean roots, Agile Project Management takes the “Plan-Do-
Check-Act” (PDCA) cycle and implements it using test-driven practices. PDCA
requires teams to work using a defined plan of execution based on solid
principles, guided by experience, and continuously refined with lessons learned.
us, the most desirable solutions emerge from the disciplined process.

CHAPTER 3: Agile Project Management and Lean Principles 63

Test-driven practices support the emergent designs that validate or challenge
the accuracy of the assumptions about the work that were made during
planning. One key to get TDD adopted by an organization is to identify the
general and specific benefits expected from applying emergent design
techniques. Emergent design is the Team’s internal creative work process that
delivers design artifacts that are more than the sum of the parts.

Using an emergent design strategy aligns with the choice to acknowledge the
reality of a Cone of Uncertainty and the need for a dynamic team process to
move through it to find the best solutions. at is the starting point for
identifying the benefits of emergent design. How important is it to find the
best solutions and how much of a competitive advantage will that create?

Another source for identifying the benefits of emergent design is quantifying the
value of moving from quality control (QC) to quality assurance (QA). How
valuable is it to prevent defects not merely catch them? How many dollars and
days can test-driven practices save by minimizing or eliminating rework?

By moving QA to the front of the build process, the Team eliminates many of
the communication disconnects that cause delays, defects, and waste.
Understanding and applying TDD practices enables the team to design
change-tolerant architecture. Test-driven practices help developers recognize
how their work will perform and integrate into the final solution so they can
insure high quality results with minimal waste. Test-driven practices give the
Team the confidence to embrace needed, even aggressive, design changes
when circumstances demand it because they know the architecture can
support it. But, test-driven practices will also require the organization to
commit to automated testing tools in order to allow the extensive verification
and validation needed as changes emerge and adjustments are implemented.

Product and Iteration Backlogs

e Customer-Proxy, also referred to as the Voice-of-the-Customer or
Product Owner, is responsible for receiving, analyzing, and prioritizing
information about the features and functionality required to successfully
fulfill the customer’s expectations with the solution being developed. at
work is documented as the Product Backlog.

Product Backlogs are a prioritized collection of short descriptions of

features, functions and capabilities included in the solution being
developed.

64 AGILE ALMANAC: Single Team Projects & Exam Prep

e Product Backlog is equivalent to the product specification or
requirements list in Traditional Project Management. It is, however,
significantly different because the customer-proxy is continuously grooming
it based on information received from internal and external sources. As
priorities change, system features can be promoted or demoted within the
overall scope or contract governing the project. So, the total project scope is
stable, but the order of development within the Product Backlog is in a state
of flux because feature ranking can change.

At the beginning of each Iteration, Features from the Product Backlog are
selected for inclusion in the Iteration Backlog.

Iteration Backlogs are the specific subset of Product Backlog items the
Team has committed to develop in a particular timebox period. Once
the specific subset of items for the Iteration Backlog are agreed upon
and fully committed to, they are not changed.

As the goal of that Iteration, the Team has committed to doing whatever is
necessary to change the current condition of the Features in the Iteration
Backlog into the desired future state. at is their sole focus. e desired
future state of those Features is, by definition, the Potentially Shippable
Product increment, which is the goal of that Iteration. e team will focus all
of its energy on developing that part of the solution and at the end of the
Iteration will demonstrate it for all interested stakeholders during a Review
Meeting.

Grooming the Product Backlog

If we use a UPS delivery person as a metaphor, Product Backlog grooming is
the “steering wheel” insuring the “Agile truck” is headed in the right direction
and stops to deliver packages at the right time and location. Backlog
grooming is important because research indicates that, for example, the cost
of a $250,000 IT development project can have a negative variance of as much
as $130,000 to achieve targeted functionality. e amount of the variance
correlates to the maturity of the requirements14. Because Backlog grooming
continuously improves project requirements it has a direct, quantitative
positive financial impact.

Backlog grooming, sometimes referred to as Backlog Management, is a

process that prioritizes and clarifies Backlog items as they move from
the long-term edge of the time horizon into a time horizon that is more
near-term.

CHAPTER 3: Agile Project Management and Lean Principles 65

Backlog items typically start with descriptions that are large, low resolution,
identifiers of features, functions and capabilities. As they move through the
grooming process, they are transformed from low granularity descriptions with
Affinity estimates (explained in chapter 9) on the Roadmap, to Stories with
Story Point estimates on the Release plan, to Tasks with detailed estimates
when they are included in the Iteration plan. As they progress, they are refined
by the customer’s insight and learning during discussions with the Team.

e information about each specific Backlog item increases as it nears likely

development. Grooming avoids waste by only gathering detailed information
as it is needed and usable. As development progresses, design choices
emerge, and the customer gains insight, any resources spent prematurely to
create detailed information have a high probability of ending up as waste
because most items will change, some of them quite dramatically.

An important responsibility for the customer-proxy is to articulate the business

value being created by Backlog grooming in customer-facing, non-technical
terms. In order to do this, the customer-proxy will lead customer collaboration
by driving activities like product visioning exercises, focus group discussions,
and marketing studies. Using those experiences, the customer-proxy will
discern how to create both incremental and long-term value.

e Backlog is the tangible expression of the Product Vision and grooming is

a real-time, iterative process that guides the project through an evolutionary
requirements elaboration process.

A best practice for identifying and defining Backlog items is to have the
customer-proxy discuss each of the following elements with the Team.

• Process elements – e definition, usage, and management of

procedures discussed in the Business Case and Value Stream Map.
• Organizational elements – e infrastructure support for the current
business practices and the support needs that must be developed for the
future-state practices.
• Human elements – e knowledge and skills applied by the users in the
current business practices and the additional user training needs for the
future-state practices.
• Risk and Regulatory Compliance elements – What provisions are
needed “just because” of the need for risk mitigation or regulatory
compliance?

66 AGILE ALMANAC: Single Team Projects & Exam Prep

 • Automation and Technology elements – How will the organization’s
approach to fulfilling required value-creation processes use a different
model, such as queries replacing reports, pull replacing push inventory
management, or automated replies replacing manual responses?

Backlog grooming along with planning Roadmaps, Releases, and Iterations is

part of a bigger process goal. e goal is to transform a product vision into a
Product Backlog that can be estimated then measured to predict the timing
for delivering Releases.

Reducing waste is a Lean principle imbedded in Agile Frameworks. at

means the frequency and level of detail in estimates must be tied to the
business benefits of doing so. Elaboration for the sake of elaborating, or
estimating for the sake of estimating, is waste. Elaborating and estimating to
create insight, plan the future, and guide execution to create business value is
not waste.

Operational Ceremonies
Almost all of Agile’s various Frameworks use three core operational meetings,
commonly referred to in Agile as ceremonies. Some have additional
ceremonies not shared by others. e three common ceremonies are the
Daily Stand-up Meeting, the Review Meeting, and the Retrospective Meeting.
And yes, ceremonies could be called meetings, but as everyone knows,
engineers and technical professionals hate meetings!

Daily Stand-up Meeting

Daily Meetings are held primarily to synchronize the Team members’
activities and secondarily, to provide information for reporting work
progress towards the Iteration Goal. e Daily Meeting is sometimes
referred to as a Daily Stand-up or Scrum meeting.

Each day, each member of the Team is expected to make reasonable progress
towards the committed, agreed-upon Iteration goal. Sometimes discoveries
or insights will come out of the Daily Meeting. ose discoveries and insights
are used by the Customer-proxy to improve Product Backlog grooming.

Because the core purpose of the meeting is to synchronize the Team

members’ activities, the meeting has a lightweight structure. at lightweight
structure has only a few rules and they are intended to help adapt the
dialogue about development to meet the Team’s need to coordinate work.

CHAPTER 3: Agile Project Management and Lean Principles 67

It is commonly called a “Stand Up” meeting because of the practice of having
collocated teams stand around the Task Board for the discussion. e belief is
that standing up helps maintain brevity and keeps the discussion focused.

e structure for the meeting provides that it is self-directed by the Team and
done in a 15 minute timebox. For new teams, facilitation by the Scrum Master
or another appropriate person may occur until the Team becomes self-
directed. e structure also requires that it be scheduled at the same time and
place every day. Additionally, the structure makes it mandatory for every
team member to attend and participate. Although others can attend to
observe, they may not participate.

Finally, the structure provides a pattern for the ceremony where the Team
gathers around the Task Board, speaks to each other, and responds to three
questions. e three questions prompt and guide each team member’s
remarks. ey are:

• What have I done since the last daily meeting?

• What will I do before the next daily meeting?
• What obstacles are impeding my work performance?

Self-directed teams employ a variety of methods to decide who speaks first.

Some common approaches include Last In, First Up, “911” (aka I have an
emergency/impediment and need to go first), Round Robin, Pass the Token,
and Draw Straws. Using a variety keeps things from going rote and losing
focus.

e meeting dynamic is working well when the Team stays focused on the
work and not personalities, everyone arrives on time, and the meeting begins
and ends on time. e dynamic is effective when work progress is honestly
articulated and obstacles addressed are removed in a timely fashion.

Review Meeting
Review Meetings are product-centric meetings where any interested
stakeholder can offer insights and concerns about the deliverables, as
well as considerations for future enhancements.

Review Meetings occur at the end of each Iteration. ey are a forum to
present the most recently completed work products to all interested
stakeholders so they can give feedback on how well it aligns with their needs
and expectations. Secondarily, it provides transparency between the

68 AGILE ALMANAC: Single Team Projects & Exam Prep

stakeholders’ needs and the Team’s work, allowing adjustments to the order of
development to occur when needed.

Before the Review Meeting, the Customer-proxy approves or accepts the

completed components of the Team’s work. If all work is completed, the
Iteration goal is reached.

e structure for the meeting provides for an appropriate sized timebox and
facilitation by the Customer-Proxy. It is mandatory that the Team present
only work that has been completed and accepted by the Customer-proxy.

e Review Meeting is a collaborative, collective information-sharing forum,

as well as a review of project metrics and progress. e Review Meeting
requires minimal preparation because only products that are completed,
tested, and meet the acceptance criteria as set forth during Iteration planning
are demonstrated. No smoke, no mirrors, no PowerPoint presentations about
what it will do – just working, potentially shippable increments of the
solution.
e meeting begins with the Customer-Proxy briefly describing the Iteration
Goal and how it measures progress towards the project objective. e
Customer-Proxy is responsible for clarifying what was set as the Definition of
Done during iteration planning.

Definition of Done is the definition of all the activities to finish and

tests to fulfill before a Story or Task is considered complete. It is an
agreement between the Team and Customer-Proxy appropriate to the
context of a project.

e Team then provides a demonstration of the completed work and discloses

any of planned work that was not completed. Optionally, the presentation
may include a review of Burn Charts, velocity metrics, and testing results to
help the stakeholders get a clearer picture of the state of the project.

e attendees then ask questions of the Team about the work products. at
interaction results in product feedback, potential updates to the Product
Backlog, and sometimes updates to the Release plan.

Retrospective Meeting
Retrospective Meetings are process-centric meetings where the Team
identifies how it can improve its process of creating Potentially
Shippable Products. Typically, the Review Meeting and the

CHAPTER 3: Agile Project Management and Lean Principles 69

Retrospective Meeting are the first and second halves of a single day for the
Team. e Team and possibly the Customer-proxy, but no one else, attend the
Retrospective Meeting.

Retrospective Meetings occur at the end of each Iteration. e primary

purpose is to create a shared understanding of how the Team worked together
and how that interaction could be improved. Additionally, it provides the
Team with insight into the different ways they each saw things, how they had
different experiences, and ended up with different perspectives of the same
Iteration.

As a best practice, GR8PM advises clients to ask their teams to seek a one
percent improvement to their process. e reason for setting the “1%
Expectation” is that nobody is intimidated by that request. Making it very
approachable for the Team sets them up for success by reducing stress.
However, we oen find that clients are skeptical, initially, saying something
like, “Why bother? What's the big deal if it is only a one percent
improvement?” In order to understand, try to think about the “1%
Expectation” as a financial instrument. If you could put your money into a
financial instrument and it would earn one percent this month, two percent
next month, three percent the third month, four percent the fourth month,
and so on, would you put your money in? Would you keep it in? Of course
you would! You’d end up wildly wealthy, right? So the “1% Expectation”
leverages the magic of compound interest. And, by the way, sometimes the
Team will make a change expecting a one percent improvement, and lo and
behold, it unlocks a chain of events and turns out to be a five or ten percent
improvement.

We learned from Lean that continuous improvement is important. Many

Project Managers using Traditional approaches have had Lessons Learned
sessions fail for many years. e key recurrent mistake being made is waiting
too long to have the meeting and making it too serious. Agile approaches
overcome that recurrent mistake by applying Lean’s continuous improvement
dictate and doing Lessons Learned – that is a Retrospective Meeting – at the
end of every Iteration. at means that every 3 or 4 weeks, while it is fresh in
the Team’s mind, they review what they could do, starting tomorrow, to
improve results and have more fun! e focus on fun unlocks the power of
the prefrontal cortex at a physiological level and the immediacy of tomorrow
creates a huge WIIFM for the Team. Doing that drives a lot of the big value
Agile creates.

70 AGILE ALMANAC: Single Team Projects & Exam Prep

e structure for the meeting provides an appropriate sized timebox and a
meeting facilitator. While it is a common practice for the Scrum Master to
facilitate the meeting, the best practice is to have an outside facilitator, such as
a Scrum Master from a different team at the same organization.

In order for the Retrospective to avoid the pitfall of each person staking out
their territory to defend, it is critical that the meeting start with the best
available facts. Notice that it is the best available, not perfect, data about the
Iteration metrics. How many Stories were completed versus how many were
committed to? What was the Team’s velocity and how did it compare to the
average? Were there changes in team membership? Were any new
technologies tested or deployed? Was Daily Meeting attendance 100%? 100%
on time? 100% committed and participating? What do the Burn Charts
show? e point is to encourage the Team to refer to artifacts, creating a
shared picture of what actually happened. Creating a visual reference makes it
is easier to see patterns and identify linkages.

en, the Team will do the serious liing of interpreting the picture. How did
the event pattern impact their ability to strive for more productivity? What
feelings occurred – both positive and negative – because of specific aspects of
the pattern? How did the Team unite in productive ways or divide in
unproductive ways? When was the Iteration just a job versus exciting as hell
versus being caught in hell?

e observations are usually recorded on a whiteboard or flipchart in a three

column format. Some of the more common configurations are:
• What Went Well – What To Improve – What Could Be Changed
• Try – Keep – Stop
•
• Fears – Hopes – Expectations
• Do the Same – Do More – Do Less
• Enjoyable – Frustrating – Puzzling
e Retrospective Meeting is a cooperative, concerted effort to identify
opportunities for significant and incremental progress in the Team’s process.
Saying significant and incremental progress sounds like an oxymoron, but it is
the key to the power of the Retrospective. e meeting is an invitation to
experiment with changes during the next Iteration that can achieve a
figurative 1% goal. One percent is definitely incremental, but when it is
compounded every 3 or 4 weeks, it becomes an immensely significant return
on investment!

CHAPTER 3: Agile Project Management and Lean Principles 71

It is critical to master the science and art of Retrospectives. e worst possible
outcome is the “Ho Hum Nothing New” event. e basic structure of the
Retrospective is solid and predictable, but the delivery of the event has to be
refreshed oen enough to keep the Team engaged.
Before we can keep them engaged however, we must get them engaged and
that brings us to the topic of kicking off the Agile project.

Kicking Off Agile Projects

In Traditional approaches, most projects start with a kickoff meeting. With
Agile approaches, it is necessary to do likewise however, because of the
immediacy with which the Team must embrace and begin the work, the way
the meeting is conducted and its goal are more intense. An Agile project
kick-off meeting has several key objectives. e agenda is designed to develop
those key areas, typically including:
• Clarify the product vision and Roadmap. Best if presented by the
Sponsor or Customer-Proxy.
• Review the business case.
• Review (or document) the most important one- or two-dozen features.
• Establish ground rules (aka Rules of Engagement).
• Document a Release plan.
• Do (or schedule) the first Iteration planning session.
Clarifying the product vision and Roadmap is one rather interesting
difference between an Agile kick-off meeting and a more Traditional one
because the Team engages through discussions and important group
exercises. e exercises can include developing the Product Vision Box, the
Flexibility Matrix, and the Project Data Sheet that were described previously.
It might also include writing an Elevator Statement.
Elevator Statements are an uncomplicated way to define the
product vision in a short statement using language everyone can
understand.
Elevator statements are concise descriptions with a format driven by the
research first developed by Geoffrey Moore and included in his book Crossing
the Chasm. Elevator statements draw their name from the idea that they are
brief enough to be shared during a short elevator ride.

e goal of the kick-off meeting is to get every team member aligned with a
clearly defined scope documented at a very high level with a dozen or two key
features. ose features are all very large pieces of information with minimal

72 AGILE ALMANAC: Single Team Projects & Exam Prep

detail, but clear connections to one another and to the strategic objective
embodied in the business case. Typically, the farther out on the time horizon
the feature is, the lower the granularity in the description. e purpose is to
orient the new project team to the business reasons driving the project.

Roadmap and Release planning focuses on identifying any required proof-of-

concept work as well as laying out logical sequence Iteration goals. Defining
the probable number of Iterations required to achieve a Release allows the
Customer-proxy to make needed future planning decisions regarding the
priority of the various features, functions and capabilities.

When teams are not collocated, every effort should be made to bring them
together for the kick-off meeting. Agile emphasizes face-to-face
communication because of its many benefits. Despite the reality of remote
teams and budget constraints, this is the time for intelligent use of available
resources. e kick-off meeting should receive high priority because the
shared decisions will guide and focus the Team throughout the rest of the
project.

It is useful to link these ceremonies to producing actionable reports.

Actionable Reports
ere are many reports Agile uses to promote a value-oriented perspective
with the Stakeholders, Sponsor and Team. e reports refine and reinforce the
focus on prioritizing the highest value creation opportunities. Not every
report Agile uses conforms to the common definition that conjures up pages
of laser printed output. However, whether the report is being spit out of a
printer, hanging on a wall or included on a Wiki page, they are guided by two
key concepts. ose concepts are Information Radiators and Visual Controls.

Information Radiators are a visible display of the current work status,

typically in the project workspace, that consolidates key information so
stakeholders can evaluate it.
Visual Controls are a Lean manufacturing practice that uses a visual
signal card as a tool for managing the production process. In Agile,
Teams display current work status information as visual control
reporting.
Let’s look at some common ones.

CHAPTER 3: Agile Project Management and Lean Principles 73

Burn-Down and Burn-Up Charts
Burn charts come in two basic forms, Burn-down and Burn-up.
Burn-down Charts show the work remaining, like number of Story
Points in the Iteration. Burn-Down Charts are used most oen to
reflect the results of the Team’s Daily Meeting.
Burn-up Charts show the work completed, usually in terms of
completed Iterations in the Release. Burn-up charts are used to show
progress completing Features, Functions, and Capabilities so the
probability of on-time delivery of the Release can be assessed.
Burn charts rarely reflect smooth curves because they reflect the Team’s actual
progress. Because of breakthroughs or unexpected technical challenges, for
example, a Burn-Down Chart may show progress staggering ahead and falling
back during various portions of the Release or Iteration.
e two most common ways to create and manage a Burn-Down Chart are
manually, for collocated teams, and using Excel for remote, distributed teams.
e most common mistake made on Burn-Down charts is overcomplicating
them. A Burn-Down simply reports the sum of Story Points for the
remaining User Stories, typically on a daily basis.
e standard Iteration Burn-Down Chart plots time on the horizontal X-axis
and work remaining on the vertical Y-axis. (Figure 3.13)

Figure 3.13| Burn-down Chart

74 AGILE ALMANAC: Single Team Projects & Exam Prep

During the Team’s Daily Meeting each member reports if they have
completed any User Stories. When they do, the Story Points for that Story are
removed from the Work Remaining total and the Burn-Down Chart is
updated to accurately show the reduction in work remaining.

Because the work remaining is measured in Story Points, if the Team

identifies additional Tasks needed to complete the Story, that change will be
reflected in Actual Cost reports, not on the Burn-Down Chart. e Burn-
Down tracks work progress not work effort, cost or future expectations.
Likewise, if the Team discovers a breakthrough that substantially decreases
the hours required to complete the work remaining, it will be reflected in
Actual Cost reports. e Burn-Down Chart will simply show that more
Stories are completed because the remaining work on the chart will decrease.

e emerging work remaining line becomes a powerful visual communicator

of the Team’s progress towards the Iteration goal. e power of this simple
chart lies in the clarity with which it articulates the project’s two most
important numbers – how much work remains and the net-net rate of
progress towards the Iteration goal including all challenges, set-backs and
victories.

Alternately, typical Burn-Up Charts show the completed Features, Functions,

and Capabilities – that is deliverables – for the current Release, making the
math required to forecast the probability of on-time delivery of the Release
rather straightforward.

FFC, Story and Task Boards

All the various Boards contain information describing Features, Functions,
Capabilities, Stories or Tasks. at information includes elements such as a
description of the desired outcome (comparable to a Traditional requirement
or specification) at a correlated level of granularity, the relative size
(comparable to a Traditional estimate) also at a correlated level of granularity,
and conditions of satisfaction or acceptance criteria (comparable to
Traditional quality constraints). e information is critical because it is used
to determine the best approach for solution development.

Feature, Function & Capability (FFC) Boards contain information,

typically a collection of cards, describing attributes and traits with
low-level granularity and long time horizons.

CHAPTER 3: Agile Project Management and Lean Principles 75

 Story Boards contain a collection of User Stories describing specific
deliverables with medium-level granularity detailed to support effective
Iteration planning.
Task Boards hold a collection of cards with high-granularity
descriptions of the work that must be completed in order to develop
User Stories committed for completion during the current Iteration.
It is worth noting that the definitions for Story Boards and Task Boards are
very specific as far certification exams are concerned, in common usage the
names are frequently used as synonyms. Story Boards contain Stories and
Tasks and Task Boards contain Tasks and Stories.

Notice that the granularity of the details increases as FFCs are decomposed
into Stories and Stories are decomposed into Tasks. e Team uses Story and
Task Boards during their Daily Meetings to focus discussion on the topics
needed to synchronize their work efforts. e boards also provide a
convenient visual radiator of the Iteration’s work organization as well as how
much work is le.

Because the primary duty of the board is to enable team synchronization, it

must be designed with the flexibility to allow self-organization of the Team’s
work. When a team member finishes a Task, they select another Task to work
on. Typically they explain their planned choice so other team members can
express concurrence or make alternate suggestions until a mutually agreeable
decision is made. By being easily visible and flexible, the board helps the
Team see which Tasks are being worked and which are waiting.
e central design element of the board is the column. Columns define the
process steps or development stages that Tasks or Stories pass through from
Backlog to completion. Boards can be constructed on corkboards,
whiteboards, flipcharts, walls, windows, cubicle dividers or even the backs of
files cabinets with columns delineated using a marker, masking tape or any
other medium.

e Tasks or Stories are written on sticky notes or cards and they are fixed,
taped or pinned in a Backlog column. en they move, in the western or
American convention, from le to right as they progress towards completion.
If they encounter difficulties, they can be moved in the opposite direction and
return to a prior process step for rework.

Many enhancements can be added to the basic card convention including, for
example, color-coded cards to signify specific feature groups or development

76 AGILE ALMANAC: Single Team Projects & Exam Prep

swim lanes, noting Sizing or estimate information, and recording
prioritization information.

In Figure 3.14, the board shows columns for Backlog, Development, Test,
User Acceptance Testing (UAT), and Completed. e Development, Test, and
UAT columns contain the in-progress work. For this team and this project,
those categories enable proper synchronization and self-organized planning.
ey also represent a continuum of progress that the average Stakeholder can
decipher to understand the state of the Iteration and correlate it to the Burn-
Down chart usually displayed nearby.

Backlog Development Test UAT Completed

Figure 3.14| Story or Task Board

Because User Stories can have a one-to-many relationship with Tasks, some
teams will choose to have Stories in the Backlog, but more detailed Tasks in
the other columns. When they do this, some teams include numbering or
color-coding to identify the Task to the Story or person doing the work.
Other teams use nested naming conventions and initials on the in-progress
Tasks. e key is to create visibility into work that is not started (in the
Backlog), in process, or completed.

Electronic Task Boards for remote, distributed, and virtual teams accomplish the
same purpose as their physical counterparts, and can oen be facilitated using a
conference call and a spreadsheet such as Excel. Typically the Task list (i.e., Task
Board) and Story Point values are maintained on one tab and the graph is on a
second tab. e results can then be easily published as a daily PDF, posted in a
Team repository, printed if desired, and archived for future reference.

Of course, to have any value at all, the reports must contain accurate useful
data and that implies reliance on another Agile concept, Osmotic
communication.

CHAPTER 3: Agile Project Management and Lean Principles 77

Osmotic Communication
In order for a cross-functional team of experts to be self-directed and
productive it must optimize communication bandwidth. Agile maintains that
whenever possible, teams should be collocated in order to maximize
communication bandwidth because that greatly enhances the opportunity to
identify issues, find solutions, and reduce risk. High levels of osmotic
communication are strongly correlated to dramatically improving the
probability of a successful project outcome.

Osmotic communication means team members pick up pieces of

information from conversations occurring near them and link that
information to insights they can contribute to the discussion. e
name is drawn from the perception that the relevant information was
acquired in a fashion similar to minerals dissolving into a solution by
osmosis.

It is worth noting that osmotic communication is critical to problem solving,

an activity that is significantly more complex than synchronization or
coordination. Synchronization can be achieved with a 15-minute Daily
Meeting. Coordination of Task assignments can be achieved with periodic
working group meetings. Problem solving, however, requires significantly
higher idea transfer rates and collaboration time and that level of bandwidth
is oen only available when teams are collocated.

Agile acknowledges that projects benefit when people with a high need to
communicate are in close proximity where they can overhear
communications between all parties. is heightens awareness of issues that
are current and important so they can be responded to quickly. Osmotic
communication is powerfully good communication and it does not occur
automatically or by accident. It must be chosen and cultivated.

e key implication is that Team members should be collocated to take

advantage of the improved information flow. ere is an opportunity cost
associated with team members not asking questions. When a team is
collocated, their very proximity leads them to ask more questions and
discover unexpected answers. Direct communication lowers the cost of
information transfer and ultimately saves time!

is principle has been applied in Traditional Project Management for many
decades when critical projects become troubled. In those cases, the common
and best practice is to create a “war room” and collocate all the needed

78 AGILE ALMANAC: Single Team Projects & Exam Prep

experts to rescue the project or address the threat. In fact, the movie Apollo
13, a 1995 American docudrama film, pivoted on the tension that occurred
when the crew appeared doomed to almost certain death because a liquid
oxygen tank exploded unexpectedly. e crew is saved because Mission
Controller Commander, Gene Kranz, immediately collocates his team in a
war room and rallies them to get the astronauts home safely, declaring,
"Failure is not an option!"

Osmotic communication and collocation are not without some limitations

however. Foremost among those limits is team size. Both concepts work best
with relatively small teams, but that can be a problem if a large project is
involved. e next limitation is personal needs and preferences when doing
tasks that require serious unbroken concentration. A best practice for
mitigating this challenge is the workspace design concept called, “Caves and
Commons.” Most of the time the team members work in the Common area,
but when the need for privacy arises, an individual moves into a Cave. ey
may do this to concentrate on solving a problem, handle a personal matter, or
to complete legally mandated job duties or disclosures.

e forgoing does not mean that Agile denies the reality that many projects
are delivered by distributed teams. Instead, it recognizes the challenges and
risks associated with teams that cannot attain the high trust and
communication levels fostered by collocation.

Osmotic communication is just one of the key elements that must be

addressed in order to cultivate Agile leadership.

Agile Leadership
Amongst some, perhaps many, Agile aficionados, a grossly over-simplified
characterization contrasting leadership in Traditional and Agile environments
is popular. While it carries all of the drawbacks of any characterization, it
may be helpful with comparing and contrasting the two methodologies. And
for the purpose of passing the PMI-ACP® and CSP exams, it can be accepted
as true.

In Traditional approaches, the Project Manager is characterized as oen

utilizing directive, command-and-control tactics such as assigning tasks to
team members to administer the project and that is negative or bad.15 By way
of contrast, in Agile approaches, leaders seek to empower the Team to achieve
the Iteration goal. e dichotomy defines the Project Manager negatively, as
someone who controls the tasks, milestones and dates in the plan and resists

CHAPTER 3: Agile Project Management and Lean Principles 79

change while pursuing inflexible objectives. e same dichotomy defines the
Agile leader positively, as someone who pursues outcomes by influencing the
Team as it embraces ambiguity and change while pursuing desirable
outcomes. Both approaches have as their goal to deliver results effectively, but
each is based on a very different set of assumptions. e assumptions that
underpinned the Agile approach are embodied in what is commonly referred
to as servant leadership.

Servant leadership is a philosophy emphasizing awareness, listening,

persuasion, relationship building, and commitment to others’ growth as
the path to creating value. Servant leadership is embodied in practices
such as embracing the energy and intelligence of others, developing
colleagues, influencing teams, and inverting the power-pyramid.
One easily identifiable metric of how well an Agile leader embodies servant
leadership is the existence of an environment of personal safety.

Personal safety16 is when team members feel support for each

individual as they work through the productive tension and respectful
disagreements that accompany developing solutions to complex
problems when uncertainty is unavoidable.

Being a servant leader and cultivating an environment of personal safety

requires the Agile leader to develop a capability commonly described as
emotional intelligence.

Emotional intelligence is the ability to identify, assess, and manage

one’s own emotions, and also the ability to identify, assess, and
influence the emotions of others.

Jim Highsmith points out, “Management research shows that mood or

“emotional intelligence” in leaders has a much larger impact on performance
than we may have imagined.”17 So it is important for an Agile leader not to be
distracted by the use of a term that has become a cliché and instead embrace
the important issue it addresses.

Because the Team will experience both highs and lows during the Iteration,
quite oen with unexpected volatility, supporting appropriate responses and
discouraging inappropriate ones is critical. Being able to induce group
dynamics conducive to creating desirable, emergent results at the edge of
chaos, where most teams must work, is as fundamental to producing optimal
results as writing good User Stories. erefore, the Agile leader must

80 AGILE ALMANAC: Single Team Projects & Exam Prep

recognize that their emotional intelligence will dramatically impact the
Team’s success and takes the steps needed to refine and improve it.

Agile leaders help create an environment where emotional intelligence can

flourish by applying the best practice of having the Team define its rules of
engagement.

Rules of engagement establish norms and expectations for team

member interactions, and are sometimes referred to as ground
rules.
By demonstrating that the treatment of one another is an important area for
the Team to discuss, develop, and define, the Agile leader can guide the Team
to document common expectations and assumptions so misunderstandings
are avoided. By posting the rules in a prominent place to act as a reminder,
the Agile leader supports interdependent accountability even as the rules are
adapted over time to improve team self-direction.

e rules foster and direct the healthy and necessary contention of emergent
design in positive ways. Great teams feed on the energy of diverse ideas in
contention to produce the highest quality results. And at the same time, they
need positive guidance to avoid accidental negative interactions.

Examples of common Rules of Engagement include:

• Everyone participates
• Respect differences
• Attack issues, not people
• Everyone has an equal voice
• Everyone has a valuable contribution to make
• Honor confidentiality and privacy within the Team

Cultivating an Agile team spirit enables exciting productivity. It does so in

part because the healthy contention of emergent design brings important
risks into focus so the Team can mitigate and resolve them.

Servant leadership relies on a number of skills and techniques, all aimed at

developing and facilitating the Team. ey include:
• Mentoring team members on the Agile Framework as well as on general
management and technical skills.
• Allowing the cross-functional team to become self-directed and fully
accountable.

CHAPTER 3: Agile Project Management and Lean Principles 81

 • Facilitating team meetings including, Release planning meetings, Daily
Stand-ups, Demonstration meetings, Reflection Workshops, Review
meetings, and Retrospective meetings.
• Guiding the Team as they foster appropriate, value-based decisions.
• Removing obstacles that impede progress, or facilitating the Team to
do so.

As the Team matures, it moves along a continuum from being a highly

directed Traditional team to a self-directing, highly motivated Agile team.
When the Team reaches this state, the Agile leader acts largely as a consultant,
serving the Team as a facilitator only when called upon.

A best practice for the Agile leader is to avoid conducting individual

performance reviews for members of the Team as this creates a conflicting
frame of reference for the team members and the appearance of violating the
servant leadership role.

Another valuable thing to remember is that collocated teams enjoy a host of

communication advantages and require only normal levels of support,
whereas there is a very real challenge in supporting communication for
virtual teams. at challenge is part of Agile leadership.

Key factors that must be considered include:

• Synchronizing communication through Daily Meetings
• Supporting collaboration through working group meetings
• Aiding problem solving by providing sufficient communication
bandwidth to enable high-volume idea transfer rates

Remember that the foremost purpose of the Daily Meeting is to synchronize

the Team’s work, which requires clear communication. e most common
challenges for virtual teams are language and accent issues due to the lack of
visual clues. Because so much communication is non-verbal, the lack of
visual clues creates a huge risk of misunderstanding.

Two best practices address this challenge. First, invest in a good headset
because vocal clues are very subtle. Second, establish a Rule of Engagement
stating each team member will provide detailed written answers to the three
questions in an email preceding the call and that they will start by reading
their written answers, verbatim. Because English is the lingua franca of many
teams, but not everyone has a good “ear” for hearing past the accents of those
speaking English as a second language, having the read-verbatim-first rule

82 AGILE ALMANAC: Single Team Projects & Exam Prep

helps the other teammates by letting their “eyes train their ears” for the
spoken words. is simple practice vastly increases the quality of
communication.

Whatever tools or techniques are used it is a primary responsibility for the

Agile leader to ensure that true problem solving – not just synchronization or
collaboration – occurs.

at means participatory decision-making is critical.

Participatory Decision-Making
Agile leaders seeking to optimize team performance need to use a
participatory decision-making model in order to make sure each Stakeholder
and team member voice is heard.

Participatory Decision-Making is a creative process for finding

effective options and cultivating collective ownership of decisions so
that everyone can support those decisions.
Over the last ten years, Agile Frameworks have enjoyed a meteoric rise in
interest because of the way they improved operating outcomes for so many
organizations. One of the variables easily identified as a significant
contributor to that success is participatory decision making. Agile recognizes
that simply having human beings act like biological machines cannot solve
the significant, complex problems faced by most organizations.

Organizations need the creative, non-linear, and imaginative insights that

only come from fully engaged knowledge workers.

Knowledge workers are persons who combine various forms of

structured and unstructured data and use creative thinking to solve
mostly non-routine problems. ey are commonly described as thinking
for a living and examples include engineers, architects, scientists and lawyers.
Flexibility is an absolute requirement for achieving success on today’s
projects. Only the knowledge workers dealing with the challenges of
developing the Iteration goal fully understand how to solve the problem.
Remember the process is dynamic, always changing to meet an evolving
challenge, as the Team moves through the Cone of Uncertainty.

In 1999, Peter Drucker emphasized the need for organizations to empower

the knowledge worker to make decisions that they – more so than

CHAPTER 3: Agile Project Management and Lean Principles 83

management – are in the best position to make; and also to avoid having the
knowledge workers leave, damaging the organization.18 In Jim Collins’s
famous book, Good to Great19, the great organizations he describes engage in
rigorous debate, oen over extended periods of time, using dialogue, not
coercion, to interrogate the truth down to the brutal facts, in a way that
allows individuals to be extremely interactive, until the best solution is
identified. Lastly, Roger Martin’s article, The Opposable Mind: How Successful
Leaders Win rough Integrative inking20 , describes how real leaders, great
leaders, tolerate and embrace ambiguity as long as necessary during
discussion because they refuse to be limited by “either/or” choices.

e Agile methodology and its many Frameworks embrace participatory

decision making as the best alternative to old school industrial thinking.
Experience has also shown that it is difficult to develop the sophisticated
leadership skills needed to facilitate, influence, and coach a team into the
healthy, durable relationships required for participatory decision making, so
be patient with yourself and others.

Participatory decision-making either helps the Team operate smoothly or

mires it in a swamp of indecision, and the difference is largely dependent on
the actions of the leader. If the leader shies away from the discussion
necessary to get the structural engineer to challenge the architect, then the
building can’t be built cost-effectively. If the construction manager has to
attend too many meetings, in the name of “coordination”, the project gets
hopelessly behind schedule because the Team doesn’t have access to the
Customer-proxy when needed. e ends of the continuum – too little and
too much – can both cripple participatory decision-making.

Leadership is critical to effective decision making in an Agile project

environment where thousands of decisions must be made using information
that is oen vague. Customer desires are unclear. Technology is untried in
the exact situation. Eight or nine out of ten decisions can paralyze the Team
because the fuzziness makes them oscillate between choices. Oen times,
once the required, healthy, vigorous debate has occurred and the Team has
reached an impasse because the ambiguity engulfs them, the leader has to
step forward. An effective leader acknowledges the ambiguity, takes
responsibility for the impact of the decision – whatever it may be – and
enables the Team to resume productivity by making the decision.

is brings us to the basic assumption of participatory decision-making that

the right team is executing the project.

84 AGILE ALMANAC: Single Team Projects & Exam Prep

The Right Team
It somehow seems necessary to reiterate that Agile is not a magic potion or a
silver bullet because many Agile evangelists act as if it is. Without the right
skills on the Team, nothing can help, not even Agile. So the Agile leader must
communicate that it is not optional to have a cross-functional team with the
right skills. e common question however is, “How do we go about getting
that particular team?”

e first part of the answer is actually a reality check. If the project is number
103 on the company’s priority list, the Agile leader must frame the Team
requirements within that reality. e crucial key is to solicit the level of
sponsorship needed to clarify the tactical reality with the Customer-proxy.

e second part of getting the particular team the project needs is evaluating
(potential or assigned) team members according to key factors such as:

• Ability – What specific competencies do they provide?

• Availability – What is their availability and what are their competing
commitments? Are they local or remote?
• Cost – How appropriate is their cost given the budget constraint?
• Chemistry – How well do their work style preferences align with the
team culture and environment?
• Experience – What similar or related work have they done? Under what
time and quality constraints?

In many, if not most organizations, whether they use a Traditional or Agile

approach, one of the biggest challenges to getting the proper team is pre-
assignment.

Pre-assignment means that someone in the organization has allocated,

appointed, or designated the specific persons who will make up the
Team without the Agile leader’s involvement.
Pre-assignment is a common practice in large organizations and can actually
help when the project is dependent on specific expertise that is in short
supply and the correct person is pre-assigned. Sometimes pre-assignment
involves specific individuals who were identified as a part of contract
negotiation and so must be on the Team. But pre-assignment also happens
many other times when there is limited rationale for the choices made and

CHAPTER 3: Agile Project Management and Lean Principles 85

that is when the Agile leader must evaluate before accepting it. In those
circumstances, the Agile leader must carefully evaluate whether critical skills
are missing from the Team and take steps to correct the problem.

It may also be necessary for the Agile leader to act in order to insure the
project receives competent staff on a timely basis, and team members don’t
have their bandwidth constricted due to other work assignments. A
professional Agile leader must be willing and able to negotiate as toughly as
required to ensure project success.

e desired result is the right person in the right role at the right time. Until
the team has that result, the Agile leader must continue to negotiate to secure
those people for the project team.

Recommended Reading
• e Soware Project Manager's Bridge to Agility, by Michele Sliger and Stacia Broderick (Addison-Wesley
Professional; May 2008)
• Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in
Transition, by Lyssa Adkins (Addison-Wesley Professional; May 2010)

86 AGILE ALMANAC: Single Team Projects & Exam Prep

 30. When team members pick up pieces of information and link that
information to insights they can contribute to the discussion, it is
called OSMOTIC COMMUNICATION.
Osmotic communication means team members pick up pieces of
information from conversations occurring near them and link that
information to insights they can contribute to the discussion. e
name is drawn from the perception that the relevant information was
acquired in a fashion similar to minerals dissolving into a solution by
osmosis.

Answers – Terminology Matching

1:I, 2:D, 3:M, 4:B, 5:C, 6:H, 7:F, 8: G, 9:K, 10:A, 11:J, 12:N, 13:L, 14:O, 15: E

Chapter End Notes

10
Copyright© 2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave omas; this declaration may be
freely copied in any form, but only in its entirety through this notice.
11
One of the best known Intel© MAPP Day facilitators in Jeff Hodgkinson who can be found on
LinkedIn©.
12
Highsmith, J. (2010). Agile project management creating innovative products, Second edition. Upper Saddle
River, NJ: Pearson Education.
13
Ibid.
14
Source: 2009 Business Analysis Benchmark Report, IAG Consulting, 42 Reads Way, New Castle, DE
15
Sliger, M., & Broderick, S. (2008).e soware project manager’s bridge to agility. Upper Saddle River, NJ:
Addison-Wesley.
16
Cockburn, A. (2007). Agile soware development: e cooperative game, Second edition. Upper Saddle
River, NJ: Addison-Wesley.
17
Highsmith, J. (2010). Agile project management creating innovative products, Second edition. Upper Saddle
River, NJ: Pearson Education.
18
Drucker, P. F. (1999). Management challenges for the 21st century. New York: HarperCollins.
19
Collins, J. (2001). Good to great: Why some companies make the leap... and others don't. New York:
HarperCollins.
20
Martin, R. (2007). e opposable mind: How successful leaders win through integrative thinking. Boston:
Harvard Business School Press.

CHAPTER 3: Agile Project Management and Lean Principles 113

 PA R T TWO
THE “BIG 5” DEEP DIVE

PART 2: The “Big 5” Deep Dive 115

 CHAPTER

Scrum Deep Dive

Chapter Highlights
In this chapter you will find an overview of Scrum as well as a detailed
description of its key elements. ose elements are broken out as the Roles,
Workflow, Ceremonies and Artifacts. e people who work in the Scrum
Framework are identified by the Roles they fulfill. e Workflow details how
those people work together and produce the planned results. Lastly, the
Artifacts are the electronic or printed evidence of the results.

Overview of Scrum
e Scrum Alliance is the largest professional user group in the Agile world.
Its flagship certification, the Certified ScrumMaster® (CSM), has the highest
name recognition and largest market share of any Agile certification at the
time of this writing (July 2015). e Scrum Alliance also offers the Certified
Product Owner® (CSPO), Certified Scrum Developer® (CSD), Certified
Scrum Professional® (CSP), Certified Scrum Coach® (CSC), and
Certified Scrum Trainer® (CST) designations.

e vast majority of Scrum Alliance members and certification holders

are in the soware industry, and that is the greatest strength and
weakness of the Scrum Alliance. It generated a lot of the early energy
and interest in Agile as well as defining and documenting
most of the early ideas and practices however, its
credibility is somewhat limited as Agile moves into
other fields such as construction, shipbuilding,
medical devices and pharmaceutical organizations.

CHAPTER 4: Scrum Deep Dive 117

e seeds of Scrum were planted in 1986 when Hirotaka Takeuchi and Ikujiro
Nonaka wrote about a new approach to product development that increased
speed and flexibility.21 ey described a holistic approach of one cross-
functional development team moving through multiple overlapping phases,
similarly to rugby players passing the ball back and forth in a rugby scrum.

However, the Scrum name first appeared in 1991 when Peter DeGrace and
Leslie Stahl referred to this as the “Scrum approach” in their book Wicked
Problems, Righteous Solutions.22 But Jeff Sutherland, John Scumniotales and
Jeff McKenna were the first to refer to it using the single word “Scrum” as the
name of the approach they developed at the Easel Corporation.

In 1995, Jeff Sutherland and Ken Schwaber, another early luminary,

collaborated in writing, sharing experiences and suggesting industry best
practices. eir work became the first public presentation of what is now
known as Scrum. A third luminary who was significant in advancing Scrum
and is considered by many to be its most articulate thought leader is Mike
Cohn. e three of them have been the source of many of the practices and
processes related to the Scrum Framework.

In 2014, the Scrum Alliance announced its collaborative adoption of the

Scrum Guide created by Jeff Sutherland and Ken Schwaber. It documents
“Scrum’s roles, artifacts, events, and rules…”. e Scrum Guide also says, in
part, that those rules, “…are immutable…” and that “Scrum exists only in its
entirety and functions well as a container for other techniques, methodologies,
and practices.” at dogmatic position is both true and also the reason so
many organizations that start with Scrum grow beyond it and begin using a
customized approach referred to as Hybrid Project Management.

e most recent version of the Scrum Guide (2013) is available as a free

download. It defines Scrum as a “Framework within which people can address
complex adaptive problems, while productively and creatively delivering
products of the highest possible value.” It goes on to describe Scrum as being,
“Lightweight, Simple to understand, and Difficult to master.” Lastly, it says that
it provides the rules of Scrum and that, “Specific tactics for using the Scrum
framework vary and are described elsewhere.”

e Organization and the Development Team exchanging mutual

commitments as the gateway to progress is the central doctrine of Scrum. e
Organization agrees that the size of the timebox for all Sprints23, and the
Increment24 that is the Sprint Goal25 will be stable and not changed. In

118 AGILE ALMANAC: Single Team Projects & Exam Prep

exchange for the Organization’s promise to allow the Development Team to
work uninterrupted and without harassment to achieve the Sprint Goal, the
Development Team promises to produce the Increment regardless of any
obstacles, expected or unexpected, that it may encounter. In essence, the
Organization promises to be reliable, giving the Development Team a stable
work environment during the Sprint and the Development Team promises to
be as creative as necessary to solve problems and conquer the unknown.

Scrum relies on the power of self-organizing, self-directing teams to deliver

those results. Because of that dependence on team-power, Scrum strongly
prefers collocation of all Scrum Team members to enable immediate, direct
communication, as well as osmotic communication.

One key principle in Scrum is that customers are free to change their minds
about the importance of User Stories26 in the Product Backlog27. at
freedom is reflected in the Backlog Grooming process exercised by the
Product Owner. During Backlog Grooming, the Product Owner adds, edits,
removes and prioritizes the User Stories to define the logical order of
development work to reflect the customer’s thinking. Two important things to
note are that Backlog Grooming is applied to requirements that are within the
boundaries of the contract and that it does not affect the Sprint Goal or
Stories that have been committed to in the current Sprint.

is creates an environment that embraces emerging needs with flexibility

outside the Sprint timebox while providing stability for the Development
Team within the Sprint. Scrum accepts the principle that complex problems
cannot be fully defined in advance and are better solved using a scientifically
validated empirical process control approach – transparency, inspection, and
adaptation. at process focuses the Scrum Team on quickly delivering
results that proceed through the Cone of Uncertainty towards a solution in
the midst of emerging requirements.

Roles
In Scrum, the three roles are Product Owner, Scrum Master, and
Development Team. e three roles together are referred to as the Scrum
Team. e Development Team is self-directing and cross-functional. Self-
directing means it chooses how best to accomplish the committed work of the
Sprint Goal. Cross-functional means it has all the expertise needed to
accomplish the work and that is why Development Team members are oen
referred to as Subject Matter Experts (SMEs). is approach optimizes
flexibility and creativity, which in turn, enhances productivity.

CHAPTER 4: Scrum Deep Dive 119

Product Owner
e Product Owner (PO) is the “voice of the customer” representing
the stakeholders and the business, and setting the logical order of
development priorities for Increments. Certified Scrum Product
Owner® (CPO) is a designation granted by the Scrum Alliance.

e Product Owner’s primary responsibility is to maximize the value of the

product, for both the customer and organization, by optimizing the work of
the Development Team. e Product Owner is critical to success because
their decisions direct the course of development. erefore, the Product
Owner is always a person, not a group or committee, even if the Product
Owner represents a customer group or executive committee.

e Product Owner’s biggest tool for achieving the interrelated goals of

maximizing value and optimizing the work is managing the Product Backlog.
Backlog management requires defining the logical order of development with
Stories that clearly express the work the Development Team needs to perform.
erefore, the Product Owner controls all changes to the priority of a Product
Backlog item.

For the project to succeed, the entire organization must respect the decisions
made by the Product Owner.

Scrum Master
e Scrum Master (SM) ensures the process is understood and
followed, shielding the Development Team from outside interference
and removing impediments. Certified ScrumMaster® (CSM) is a
designation granted by the Scrum Alliance.

e Scrum Master’s primary responsibility is to ensure the Scrum Team

understands the principles of Scrum so they can properly apply its rules and
practices. As a servant-leader, the Scrum Master guides the Scrum Team’s
interactions to maximize the value they create and coaches stakeholders so they
understand how to interact with the Scrum Team in helpful and effective ways.

e Scrum Master’s effectiveness and efficiency is a result of interacting with

the Product Owner, Development Team, and Organization. e Scrum
Master and Product Owner work together to ensure desirable Product
Backlog management with clear and concise Stories that maximize value.
ey work together to communicate the empirical planning environment and
data to all stakeholders.

120 AGILE ALMANAC: Single Team Projects & Exam Prep

e Scrum Master and Development Team work together to create a self-
organized and cross-functional environment, construct high-value
Increments, remove impediments, and find ways to more fully adopt and
implement Scrum.

e Scrum Master and Organization work together to create an

understanding of Scrum with appropriate training and coaching. Together,
they work together to identify and plan opportunities to implement Scrum
and apply empirical product development best practices.

Development Team
e Development Team is a cross-functional group, which creates
solutions by analyzing, designing, developing, testing, and
implementing deliverables. It is assumed that it has all the needed
skills, is highly trusted and self-managing.

e Development Team’s primary responsibilities are to structure and manage

the development work of an Increment that fulfills the Definition of Done
committed to during Sprint Planning and to have that work completed by the
end of the Sprint.

e Development Team’s effectiveness and efficiency is a result of being self-

directed and cross-functional. Because they are empowered by the
organization to decide for themselves how to turn the Stories into an
Increment, their only limits are self-imposed. Because they are cross-
functional, they have all of the skills necessary to complete the product
increment by the end of each Sprint and are accountable, as a whole, for the
results, good or bad.

Developer is the only title that Scrum recognizes for members of the
Development Team. Regardless of the work the person performs they are
called a Developer without exception. Also, Scrum does not recognize sub-
teams or other divisions within the Development Team, again without
exception. ese rules are rigid and have both positive and negative
consequences. On the positive side, they create an environment of equality
intended to foster robust problem solving in an environment of personal
safety. On the negative side, they can cause confusion among stakeholders
with limited knowledge of Agile and Scrum, and also inhibit Scrum’s
scalability for larger programs, portfolios and enterprise initiatives.

CHAPTER 4: Scrum Deep Dive 121

e Scrum Guide says, “Optimal Development Team size is small enough to
remain nimble and large enough to complete significant work within a Sprint.”
e generally accepted best practice from the leadership body of knowledge is
that team size should be “seven plus or minus two”. In other words, the Team
should be between five and nine members. Since the Development Team, by
definition, includes a Product Owner and Scrum Master, they should have
between three and seven Developers.

On the positive side, that means they avoid having too much complexity for
an empirical process to manage. On the negative side, they sometimes lack
the skills and creative interaction needed to deliver Increments that the
stakeholders and organization recognize as important.

However, the Scrum Guide also says, “e Product Owner and Scrum Master
roles are not included in this count (i.e., team size) unless they are also
executing the work of the Sprint Backlog.” is seems to violate the generally
accepted best practice that it is risky and counter-productive to have anyone
mixing Developer duties with Product Owner or Scrum Master
responsibilities or even to have someone mixing the duties of the Product
Owner and Scrum Master. As one team we worked with said, “We didn’t
know if ‘Bad Dave’ the Product Owner was coming in to challenge us or
‘Good Dave’ the Scrum Master or Developer was coming to help us. We all
felt schizophrenic!”

Scrum supports self-organizing teams by preferring collocation of all Scrum

Team members to promote immediate, verbal communication between all the
subject matter experts on the Development Team. Sometimes this preference
is misinterpreted or misrepresented to mean that Scrum cannot be used with
remote, distributed or virtual teams, or that it cannot be used with team
members who are fractionalized across multiple projects. Both assumptions
are incorrect. However, both situations will raise the complexity and risk
associated with the project so using Scrum in those environments requires
more careful management and structure in order to set the Development
Team up for success.

Workflow
e Scrum framework is intended to be lightweight and contain a minimal
set of practices and roles that can be customized aer it has been learned and
implemented.

122 AGILE ALMANAC: Single Team Projects & Exam Prep

As described in Chapter 3, Scrum shares in common with all Agile
Frameworks, a theoretical approach founded on empirical process control
theory. e theory states that knowledge comes from experiential data and
decisions should be based on what is known from that data. Using empirical
data within an iterative, incremental process allows Agile approaches, including
Scrum, to reduce risk by optimizing predictability. Empirical process control
applies three concepts – transparency, inspection, and adaptation.

Transparency is defined as making important aspects of the process

visible using an understood standard, such as the Definition of Done,
for those making decisions about the outcome, such as the Increment,
to enable a shared understanding of what has occurred.

Inspection is defined as frequently examining work products, called

Artifacts, to detect undesirable variances that could negatively impact
progress toward a desired outcome, such as the Sprint Goal. It is optimal
to inspect as near as possible to the point the work is being done. Care must be
exercised to prevent the frequency from negatively impacting progress.

Adaptation is defined as adjusting a process input or the development

process to correct unacceptable deviations from the defined standard
that were detected during inspection. Adjustment should be done
quickly to minimize the negative impact
or the occurrence of further deviation.

In Chapter 3, the generic Agile micro-

dynamic workflow was described. In
Scrum, the specific description of the
team-level workflow starts with all
product information being directed to the
Product Owner (Figure 4.1). e Product
Owner is responsible for knowing what
PRODUCT OWNER the customer wants, putting it in the
Product Roadmap (reference Figure 4.2)
and deciding what is most important and
will be developed first.

Putting the information about the

features, functions, and capabilities into
Roadmaps and Release Plans prioritizes
Figure 4.1| Product Owner the Product Backlog. e Roadmaps and

CHAPTER 4: Scrum Deep Dive 123

 Release Plans show what
needs to be developed in
order to successfully
deliver the final
outcome. Each
requirement, function
or capability is recorded
as a User Story or Epic
so that the Product
Owner can prioritize
them. e Product
PRODUCT OWNER Owner continuously
grooms the Product
Backlog as an important
step preceding the
planning session
occurring at the
beginning of each
Sprint. at planning
session is the next step
in the process.
Figure 4.2| Product Backlog
e Product Owner
submits the next piece of the puzzle to be developed to the Development
Team and they negotiate an outcome that is both valuable and doable. e
outcome is called the Sprint Goal. e Goal is documented with Stories in the
Sprint Backlog (reference Figure 4.3). e Product Owner takes the most
important Product Backlog Stories to the Development Team where they ask
clarifying questions..

e clarifying questions make sure the Development Team and Product

Owner share a clear idea of what will be built. e discussion is a collegial
effort to figure out what can actually be built during the Sprint that will drive
the most value because of the customer insight it will create. It leads to a joint
decision about the Sprint Goal.

Typically the process is done in two steps. Step One is where the Development
Team makes the “So Commit” to the proposed Sprint Backlog. en, aer
analysis, if they are confident they can do it, they make the “Hard Commit” to
the Sprint Goal. e Hard Commit creates the Reciprocal Commitment.

124 AGILE ALMANAC: Single Team Projects & Exam Prep

e goal of the Sprint Planning process is to figure out the best way for the
Development Team to make measurable progress towards the Sprint Goal.
Crystallizing the Sprint Goal creates an environment where the priorities
don’t change every week, enabling the Development Team to succeed.

DEVELOPMENT
TEAM

PRODUCT OWNER

PRODUCT SPRINT SPRINT

BACKLOG PLANNING BACKLOG
MEETING

Figure 4.3| Sprint Backlog

When that Reciprocal Commitment happens, when the Hard Commit

happens, the Sprint begins (reference Figure 4.4). During the Sprint the
Development Team completes Tasks and has a daily, 15-minute Scrum
Meeting to stay synchronized. e meeting helps insure progress keeps
moving forward by having each Development Team member answer the

DEVELOPMENT
TEAM

DAILY
SCRUM
PRODUCT OWNER

SPRINT

PRODUCT SPRINT SPRINT

BACKLOG PLANNING BACKLOG
MEETING

Figure 4.4| Sprint Begins

CHAPTER 4: Scrum Deep Dive 125

three questions that were explained in Chapter 3. e Scrum Master
facilitates the Development Team and removes impediments.

e outcome of the Sprint is an Increment (reference Figure 4.5). As it is

being developed, the Development Team is sharing their progress with the
Product Owner. e final delivery of the Increment is not a surprise to the
Product Owner at the end. e Product Owner and Development Team are in
agreement that when the Sprint ends, either the Increment is delivered as
promised or not. Sometimes a Story couldn’t be developed, and even though
that's an exception, everyone admits to that being the outcome.

DAILY
SCRUM
DEVELOPMENT
TEAM

SPRINT
PRODUCT OWNER

INCREMENT
PRODUCT SPRINT SPRINT
BACKLOG PLANNING BACKLOG
MEETING

Figure 4.5| Sprint Increment

e Sprint ends with the Scrum Team presenting the completed deliverable at
the Review Meeting (Figure 4.6). e product-centric meeting gives any
interested stakeholder a chance to see the Increment, give feedback and ask
questions.

TEAM

Figure 4.6| Sprint Review

126 AGILE ALMANAC: Single Team Projects & Exam Prep

Following the Review Meeting, the Scrum Team holds a closed-door Sprint
Retrospective (reference Figure 4.7). is process-centric meeting is where
the Scrum Team talks about continuous improvement and their development
process. It generates a shared understanding and is not a blaming session. e
process occurs while the Scrum Team’s memories are still fresh so they can
identify and select ideas that will improve their process. ey start using those
ideas the very next day.

ITERATION

No Changes In
Duration Or Goal

RETROSPECTIVE
MEETING

Figure 4.7| Sprint Retrospective

Ceremonies
e Scrum Guide says, “Prescribed events are used in Scrum to create
regularity and to minimize the need for meetings not defined in Scrum.” Scrum’s
“events” include the Sprint as well as the three core operational meetings
commonly referred to in Agile as ceremonies.

e Scrum Guide also says, “Other than the Sprint itself, which is a container
for all other events, each event in Scrum is a formal opportunity to inspect and
adapt something.”

The Sprint
e Sprint is the core process of Scrum. It uses a timebox with a consistent
duration to create a cadence or pace for the Development Team throughout
development. Each Sprint starts immediately following the previous Sprint
with a Sprint Planning ceremony. During the Sprint, no scope changes are
made and the quality standard that was used for the Definition of Done is
maintained as the Sprint Goal is pursued.

CHAPTER 4: Scrum Deep Dive 127

e Product Owner may cancel a Sprint, but would normally only do so if the
Increment or the project as a whole became unneeded due to an
organizational decision to change strategic or tactical direction caused by
factors like competitive or technological conditions. When that happens, it is
referred to as an Abnormal Termination because cancellation is rare and
seldom makes sense. Sprint cancellations are traumatic for the Development
Team and should be avoided if at all possible.

e Sprint is planned in a creative, collaborative Development Team

ceremony called Sprint Planning. e Scrum Guide describes Sprint Planning
as not exceeding eight hours for a one-month Sprint. It also says the Scrum
Master facilitates Sprint Planning so that it answers two questions. First, what
can be delivered in the upcoming Sprint? And second, how will the
Development Team achieve the work needed to deliver the Potentially
Shippable Product? e answer to the first question defines the Potentially
Shippable Product. e answer to the second question is decided before the
Hard Commit is made.

Interestingly, the Scrum Guide states, “Scope may be clarified and re-
negotiated between the Product Owner and Development Team as more is
learned.” It continues with, “Each Sprint may be considered a project with no
more than a one-month horizon.” And lastly, “Sprints are limited to one
calendar month.” e first statement seems to violate the generally accepted
best practice that scope is fixed during Sprint. e second demonstrates a
major misunderstanding of the universally accepted definition of a project.
And the third clearly demonstrates a perspective limited to soware
development even thought Scrum is being extended into many other fields,
such as shipbuilding, where Sprints of six to eight weeks are not uncommon.
erefore, the wording in the Scrum Guide is somewhat vague and even
counter-productive to some people trying to understand and apply Scrum28.

Daily Scrum
Daily Scrums are time-boxed to 15-minutes. e Scrum Master and
Development Team use them to synchronize activities. Because the core
purpose of the meeting is to synchronize their activities, the meeting has a
lightweight structure. at lightweight structure has only a few rules and they
are intended to help adapt the dialogue about development to meet the need
to coordinate work.

e meetings are held at the same time and place each day. During the
meeting, each Development Team member answers the three questions

128 AGILE ALMANAC: Single Team Projects & Exam Prep

described in Chapter 3. What did I do yesterday? What will I do today? Are
any impediments preventing me from meeting the Sprint Goal?

e Scrum Master ensures Daily Scrum occurs, but the Development Team is
self-organized and responsible for running it. e Scrum Master coaches the
Development Team to keep the Daily Scrum within the 15-minute timebox.

One particularly effective technique that Scrum Masters can teach teams to
help self-manage the meeting and keep it within the 15-minute timebox is
e Seven-Second Rule29. e Seven-Second Rule states that the only
problems that are solved in daily meetings are ones that can be solved in
seven seconds or less. Since exactly zero problems can be solved in seven
seconds, the purpose of teaching the Development Team this rule is that
whenever the discussion diverts away from the three questions and into
problem solving, the first member to realize it calls out, “Seven-Second Rule!”
At that point the other members acknowledge that a working group or
problem-solving meeting needs to be scheduled and everyone returns to the
focus of synchronizing. A best practice for this rule is to teach it to teams at
the very beginning of their formation before it is needed so no one feels
singled out when it is used.

Each day, each member of the Development Team is expected to make

reasonable progress towards the committed, agreed-upon Sprint Goal.
Sometimes discoveries or insights will come out of the Scrum Meeting. ose
discoveries and insights are used by the Product Owner to improve Product
Backlog grooming.

Sprint Review
e Scrum Guide says, “A Sprint Review is … an informal meeting, not a status
meeting, and the presentation of the Increment is intended to elicit feedback and
foster collaboration.” It goes on to say, “is is a four-hour time-boxed meeting
for one-month Sprints.”

Sprint Reviews are product-centric meetings where any interested stakeholder

can offer insights and concerns about the deliverables, as well as
considerations for future enhancements. ey occur at the end of each Sprint
and are a forum to present the most recently completed work products to all
interested stakeholders. ey also provide transparency between the
stakeholders’ needs and the Development Team’s work, allowing adjustments
to occur when needed.

CHAPTER 4: Scrum Deep Dive 129

To start the Sprint Review, the Product Owner explains what has and has not
reached the Definition of Done. Next, the Development Team briefly explains
what went well, what problems occurred, and how challenges were resolved. It
then demonstrates the work completed and answers questions about the
Increment (i.e., Potentially Shippable Product). Finally the Product Owner
explains the state of the Product Backlog and may forecast likely completion
dates for the Release Plan and Roadmap.

With that understanding established, the participants discuss what the

priorities should be for the next Sprint Planning meeting and its relationship
to changes in the competitive marketplace or internal use of the product.
ey may also review the impact of changes to the forecast timeline on
budgets and customer expectations about features, functions and capabilities.

e interactions during the Sprint Review results in product feedback,

potential updates to the Product Backlog, and sometimes updates to the
Release plan.

Sprint Retrospective
e Scrum Guide states, “A Sprint Retrospective occurs aer the Sprint Review
and prior to the next Sprint Planning. is is a three-hour time-boxed meeting
for one-month Sprints. … e Scrum Master participates as a peer team
member in the meeting…” Sprint Retrospectives are process-centric meetings
where the Scrum Team identifies improvements it can make to its process of
creating Increments then makes a plan to implement those improvements. It
accomplishes this process by creating a shared understanding of how the
Development Team worked together and how that interaction could be
improved.

e Scrum Master encourages the Development Team to focus its inspection

on the actual process it has used and to plan adaptations it can implement in
the next Sprint. While it is a common practice for the Scrum Master to
facilitate the meeting, the best practice is to have an outside facilitator, such as
a Scrum Master from a different team at the same organization, do it.

e Retrospective is a formal application of continuous improvement,

imbued with the power of fun, to unlock the prefrontal cortex so it creates a
huge WIIFM for the Scrum Team. It is a cooperative, concerted effort to
identify opportunities for improvements in the Team’s process.

130 AGILE ALMANAC: Single Team Projects & Exam Prep

Artifacts
e Scrum Guide says, “Scrum’s Artifacts are specifically designed to maximize
transparency of key information so that everybody has the same understanding
of the artifact.” It then specifically describes the Product Backlog, Sprint
Backlog and Increment.

Product Backlog
e Product Backlog is a prioritized collection of cards or a list of all the
features, functions and capabilities that are envisioned as possibly needed in
the final product. It is a comprehensive expression of the requirements held in
a specific place, physical or electronic, by the Product Owner. Each item in
the Product Backlog has a description, prioritization, approximation of
development cost and assessment of customer value.

e Product Backlog changes dynamically during product development in

order to keep the product relevant and useful even as the external competitive
or internal operational context changes. e Scrum Guide says, “As long as a
product exists, its Product Backlog also exists.” However, it might be more
accurate to say that as long as a product remains in development, its Product
Backlog continues to exist.

Grooming, or as the Scrum Guide calls it, Product Backlog refinement, is an

ongoing activity facilitated by the Product Owner in collaboration with the
Development Team. Together, they increase the granularity of the details
about Product Backlog items as they move from a more distant time horizon
to a more current time horizon and the likelihood of understanding what will
actually be developed increases.

e Scrum Guide says, “e Scrum Team decides how and when refinement is
done. Refinement usually consumes no more than 10% of the capacity of the
Development Team. However, Product Backlog items can be updated at any
time by the Product Owner or at the Product Owner’s discretion.” e key idea
is that Grooming is an ongoing process that involves both the Development
Team and the Product Owner.

Product Backlog items for the upcoming Sprint must be refined enough to
have a clear and reasonable Definition of Done. Any item that has not reached
that level of refinement is not ready for the next Sprint and should not be
selected for inclusion in Sprint Planning.

CHAPTER 4: Scrum Deep Dive 131

e Scrum Guide says, “e Development Team is responsible for all estimates.
e Product Owner may influence the Development Team by helping it
understand and select trade-offs, but the people who will perform the work
make the final estimate.” is is an important and true statement. However, it
does not imply nor support the commonly heard assertion that Scrum only
estimates the work in the very next Sprint. As the details are refined during
Grooming and granularity is increased, so does the estimate associated with
it. e continuum goes from Affinity estimates to Planning Poker estimates
(explained in chapter 10) to final or engineering estimates30.
Lastly, defining the Product Backlog as an artifact is interesting because it is
in a continuous state of change as the product is being developed and only
becomes fixed, in the traditional sense of an artifact, aer development of a
specific piece of the product is complete.
Sprint Backlog
e Scrum Guide says, “e Sprint Backlog is the set of Product Backlog items
selected for the Sprint, plus a plan for delivering the product Increment and
realizing the Sprint Goal.” A common misunderstanding is to think of the
Sprint Backlog as only containing descriptions of the items to be developed. It
is also the Development Team’s plan for developing the Increment that fulfills
the Sprint Goal. However, it is not a plan in the sense commonly used in
Traditional Project Management because the Development Team is self-
directing and responds to change by integrating what it learns as it develops.
e Sprint Backlog creates transparency so the work that the Development
Team plans to complete is visible for all stakeholders. It also provides enough
detail to enable the Development Team to make adjustments during the Daily
Scrum as progress is better understood. e adjustments are part of the
iterative cycle of discovery where the Development Team modifies the Sprint
Backlog, causing a clearer understanding to emerge, and leading to additional
adjustments. is micro-cycle of plan, build, check and adjust is an
application of the empirical process control approach – transparency,
inspection, and adaptation – discussed earlier.
e Scrum Guide says, “As new work is required, the Development Team adds
it to the Sprint Backlog. As work is performed or completed, the estimated
remaining work is updated.” A common point of confusion caused by this
wording is that the scope of the work can be changed or expanded during the
Sprint. A more correct interpretation would be that the amount of granularity,
the depth of the detail, the exactness of the description of the work increases

132 AGILE ALMANAC: Single Team Projects & Exam Prep

and specific tasks are delineated and “added” to the Sprint Backlog. However,
the overall scope of the work that was committed to as the Sprint Goal does
not change or increase during a Sprint. at is why the Scrum Guide’s next
statement says, “Only the Development Team can change its Sprint Backlog
during a Sprint. e Sprint Backlog is a highly visible, real-time picture of the
work that the Development Team plans to accomplish during the Sprint, and it
belongs solely to the Development Team.”
Progress towards the Sprint Goal is tracked and monitored using Velocity.
Each day, as part of the Daily Scrum, the total work remaining is recorded by
summing up the quantity of work remaining for each uncompleted Backlog
item. at quantity is expressed in whatever unit of measure was agreed upon
and used to size or estimate the User Stories and Tasks. It is commonly
plotted on a Burn-Down Chart in order to see the probability of achieving the
Sprint Goal.

e Scrum Guide updated the phrase Potentially Shippable Product to the

word “Increment.” Potentially Shippable Product originated with Scrum and
became the generic Agile expression. Using the word Increment is, in our
opinion, an improvement on the older, more common term because
stakeholders in the industries in which Scrum is growing more easily
understand it.

Increment is defined as, “the sum of all the Product Backlog items
completed during a Sprint and the value of the increments of all
previous Sprints” by the Scrum Guide.

Potentially Shippable Product is defined as the deliverable(s) at the end

of the Sprint that adds value to the customer’s understanding
project progress.

e two terms are closely aligned and used as synonyms.

e Scrum Team works together with stakeholders to identify and create the
artifacts needed to increase the probability of successfully reaching the Sprint
and Release Goals. Because Scrum relies on empirical process control, the
need for transparency is very important. In order to maximize customer and
business value and reduce risk, every artifact must be as transparent as
possible. As transparency rises, so does the likelihood of making sound
decisions. e inverse is also true.

CHAPTER 4: Scrum Deep Dive 133

e Scrum Guide uses the phrase, “… an Increment is described as “Done”…”
in the same way generic Agile uses the more common phrase, “Definition of
Done.” It is also not uncommon at Scrum and Agile gatherings to hear
practitioners actively debating whether the idea of Done, Done-Done or the
4-Levels of Done is more correct. No matter what your position in that
conundrum might be, the Scrum Guide is absolutely correct when it says,
“When a Product Backlog item or an Increment is described as “Done”,
everyone must understand what “Done” means.”

Done, when used to describe the completion of an Increment, is

defined as a mandatory “shared understanding of what it means for
work to be complete, (and) to ensure transparency. is is the definition of
“Done” for the Scrum Team and is used to assess when work is complete on the
product Increment” according to the Scrum Guide.

Definition of Done is defined as the description of all the activities to

finish and tests to fulfill before a Story or Task is considered complete.
It is an agreement between the Development Team and Product Owner,
appropriate to the context of a project.

e two terms are closely aligned and used as synonyms. ey focus on a
single core concept. To succeed, everyone must understand and accept
whatever Definition of Done is being used to guide the work of the Sprint.

Although Scrum has not been explicitly extended from the micro-dynamic
team level into the macro-dynamic enterprise level, the Scrum Guide does
note, “If the definition of "done" for an increment is part of the conventions,
standards or guidelines of the development organization, all Scrum Teams must
follow it as a minimum.” As Scrum continues to grow, if it really wants to
fulfill its mission to transform the world of work, it will need more
practitioners to embrace more formalized standards as the above quote
implies.

Recommended Reading
• Agile Product Management with Scrum: Creating Products that Customers Love, by Mike Cohn
(Addison-Wesley Professional; April 2010)
• Exploring Scrum: e Fundamentals, by Dan Rawsthorne and Doug Shimp (CreateSpace Independent
Publishing Platform; July 2011)

134 AGILE ALMANAC: Single Team Projects & Exam Prep

Answers – Terminology Matching
1:G, 2:D, 3:E, 4:B, 5:C, 6:A, 7:F, 8:J, 9:K, 10:H, 11:I, 12:N, 13:L, 14:O, 15:M

Chapter End Notes

21
Takeuchi, H., & Nonaka, I. (1986, January-February). e new new product development game. Harvard
Business Review, 64(1), 137-146.
22
DeGrace, P., & Stahl, L. H. (1990). Wicked problems, righteous solutions: A catalogue of modern soware
engineering paradigms. New York: Prentice Hall.
23
Sprint is the Scrum-specific term for Iteration.
24
Increment became the Scrum-specific term that replaced the original Potentially Shippable Product and
approximates the Traditional term deliverables.
25
Sprint Goal is the Scrum-specific term that approximates the Traditional term milestone.
26
User Stories is the Scrum-specific term that approximates the Traditional term requirement or
specification and the PMBOK Guide® terms Work Package or Activity.
27
Product Backlog is the Scrum-specific term that approximates the Traditional and PMBOK Guide® term
Project Scope.
28
Or perhaps those dogmatic positions are why so many organizations that start with Scrum grow beyond
it and begin using a customized approach referred to as Hybrid.
29
e Seven-Second Rule was developed by John Stenbeck and has been taught to many thousands of
GR8PM students in classes around the world since 1998.
30
is same continuum in Traditional project management is referred to as Rough Order of Magnitude
(ROM), Budgetary and Definitive and is documented in the PMBOK Guide®.

156 AGILE ALMANAC: Single Team Projects & Exam Prep