Daniel S. Vacanti - Actionable Agile Metrics for Predictability: An Introduction

Yourprocess is unpredictable. What you may not realize, though, is that youare the one responsible for making it that way. But that is notnecessarily your fault. You have been taught to collect the wrongmetrics, implement the wrong policies, and make the wrong decisions.Together, we can do better.

Up until now you have probably assumed that the reason your process isunpredictable is due to circumstances completely outside of yourcontrol. However, you have much more control over the way you work thanyou think you do. Whether explicit or not, you have put policies inplace that specifically prevent you from being predictable. Amongstother things you start new work at a faster rate than you finish oldwork, you work on too many items at the same time, you ignore systemicdependencies and impediments, and you expedite requests that do not needto be expedited. You, in effect, initiate a denial of service attack onyourself, and then wonder why it takes so long for things to get thingsdone.

But all of those policies are under your control.

If we, as knowledge workers, want to get to a predictable world, we mustfirst start by controlling the policies we can control. Taking thiscontrol will seem uncomfortable at first. It will mean saying no tocustomer requests to start new work immediately. It will mean placingmuch less emphasis on upfront estimation and planning. It will meanlooking at a different set of metrics than the ones you have beentrained to track. Those metrics will tell you how predictable you areand what actions to take to improve. If you choose to collect themetrics suggested by this book, you will see that the data provided bythem will immediately reflect policies you have in place. That data willin turn suggest the changes to your policies necessary to be morepredictable. Those policy changes will themselves be reflected in thenew data you collect after the change. And so on and so on.

Yourprocess is unpredictable. You know it. Your customers know it. Now it istime to do something about it.

Because our customers demand predictability. Because you need someone onyour side who has been asked tough questions and has found a way to givemeaningful answers. Because most organizations that I visit are eitheruninformed or have been misinformed about what metrics and analyticsthey need to track to be predictable.

But to get you where you need to be, I am going to ask you provocativequestions. I am going to challenge your assumptions about what trueAgility is. I may make you uncomfortable with some of the conclusionsthat I draw. I hope you will forgive me for all of these as my onlyintention is to make your process better. After all, as I just said, Iam on your side.

Anyone who has ever been asked to give an estimate should read thisbook. Likewise, anyone who has ever asked for an estimate should readthis book.

Analysts, developers and testers need to know how to stop givingestimates and how to start making accurate predictions.

Product owners, project managers, and executives need to know what makesfor a meaningful prediction and how to hold teams accountable to makethose predictions.

All metrics and analytics will be capitalized. For example: Work InProgress, Cycle Time, Throughput, Cumulative Flow Diagram, Scatterplot,etc.

I am also going to capitalize all methodology names. For example: Agile,Scrum, Kanban, etc.

Lastly, I am going to use the words process and systeminterchangeably. I will try to make the distinction clear when adistinction is necessary.

This book is intended to be read in order as the concepts in laterchapters are built on the concepts developed in earlier ones. However,each chapter can stand alone, and, where possible, when I re-examine aconcept that has already been explained, I will try to reference thepart of the book that contains the more detailed explanation.

PART ONE FLOW FOR PREDICTABILITY

Chapter 1 defines my notion of predictability. It introduces themetrics that are necessary to track to become predictable, and it willexplain what it means to turn those metrics into actionableinterventions.

Chapter 2 is a detailed discussion of the basic metrics of flow. Therest of the book will assume knowledge of what those metrics are and howthey are defined.

Chapter 3 is an introduction to Littles Law. If you want to bepredictable, you have to understand why Littles Law works. Period.

PART TWO CUMULATIVE FLOW DIAGRAMS FOR PREDICTABILITY

Chapter 4 is an in depth explanation of what Cumulative FlowDiagrams (CFDs) are and what they are not. This chapter is a must readbecause most previous agile publications that deal with CFDs areerroneous and most agile electronic tools build them incorrectly. I willattempt to remedy all of that.

Chapter 5 explains how to read all of the basic metrics of flow offof a CFD. The ability to read these metrics is one of the biggestreasons to use CFDs in the first place.

Chapter 6 explains how to interpret the results of a generated CFD.Many common patterns that appear in CFDs are explained.

Chapter 7 begins the exploration of the assumptions behind LittlesLaw and CFDs by looking at process arrivals and departures. If you getthese right then you have gone a long way toward predictability. Notinconsequentially, arrivals and departures represents the first part ofa principle known as the Conservation of Flow

Chapter 8 continues the discussion of Littles Laws assumptions bylooking at the second part of the principle of Conservation of Flow.This second part explains why just-in-time commitments and just-in-timeprioritization is possible and necessary for predictability.

Chapter 9 introduces the little-known concept of Flow Debt, how tosee it on a CFD, and why it kills predictability. What actions to takewhen it accumulates are also discussed.

PART THREE CYCLE TIME SCATTERPLOTS FOR PREDICTABILITY

Chapter 10 is an in depth examination of the second most importantanalytical chart: the Cycle Time Scatterplot.

Chapter 11 explains how to interpret a Cycle Time Scatterplot. Manycommon patterns that appear on Scatterplots are explained.

Chapter 12 introduces one of the least known and least understoodpractices needed for predictability: the Cycle Time Service LevelAgreement (SLA). Some thoughts on how to set SLAs and manage to them areexplored.

PART FOUR PUTTING IT ALL TOGETHER FOR PREDICTABILITY