Dan Vacanti, well known in the Kanban community, has just published the book Actionable Agile Metrics for Predictability, An Introduction. This is an amazing book which is very much relevant to TameFlow. I would have no hesitation to recommend this book as mandatory reading to anybody who is interested in TameFlow.

In fact, Dan Vacanti’s earlier blog posts and presentations explained a lot about Flow and Little’s Law. They had a deep influence on my own understanding about the topic and on how I evolved the way TameFlow deals with Operational Flow.

(Note: Operational Flow is one of the four flows that are part of TameFlow; the other three are: Financial Flow, Informational Flow and Psychological Flow).

Now (early March, 2015) Dan has collected, expanded and published his thoughts in this book. As soon as I skimmed through the table of contents, I knew this was a book I just had to read — so much of it resonated directly with my thoughts about how to manage (operational) flow.

Already the opening paragraph of the preface will come through as a shock for most people involved in managing knowledge work, who might be formally trained in project management or software engineering management. It reads like this:

Your process is unpredictable. What you may not realize, though, is that you are the one responsible for making it that way. But that is not necessarily your fault. You have been taught to collect the wrong metrics, implement the wrong policies, and make the wrong decisions.

The implication here is that many professionals will have to exercise a deep reflective introspection to understand why they engage in management practices that are really counterproductive. Dan’s description is colorful:

You, in effect, initiate a denial of service attack on yourself

I was pleased to read that Dan’s recipe is to collect the right metrics (which are different than those that professionals have been trained to use). Those metrics will both reflect the counterproductive effects of the traditional practices and policies in use, as well as suggest what changes can be made. This is exactly the same kind of approach I employ when looking at the Operational Flow of TameFlow — Dan had me hooked and I wanted to see how he would actually do it. So I delved into reading the whole book, and was eager to see how much of it was applicable to TameFlow; if there were any new ideas (to steal! :-); if I maybe needed to revise parts of TameFlow.

This series of posts is a recount of what I found. I will summarize the chapters, dwelling more on those I found more interesting, and elaborate on how Dan’s concepts relate (or not) to mine.

Chapter 1 — Flow, Flow Metrics and Predictability

Dan starts by elaborating on the topic of predictability and why it is so important. The first and most recurring question you hear from customers is “When will it be done?” Many agile practices simply avoid the topic altogether, stating that things will be “done when they are done”. While, in principle that is true, it is irresponsible to give that kind of answer to a paying customer. There must be better ways to provide that answer.

Dan invites us to reflect on the most common practices in use today to realize predictability. Then he offers a long list of questions that will reveal if you are deliberately or inadvertently employing practices that hamper predictability. Those questions will undoubtedly uncover if you are hurting yourself without knowing it. This list of questions is extremely valuable, and should be taken into account by anybody who is in charge of managing knowledge work. If you use those questions, and realize that indeed you are the source of your own problems, then the book will already have done you a great service — in the first few pages of the first chapter!

Dan then describes Flow and the Basic Metrics of Flow. He defines flow as the movement and delivery of customer value through a process. The priceless perspective here is that flow is not seen as mere movement of work, but of customer value. If that customer value can be quantified in monetary terms, this perspective is very close and supportive of the ideas of financial flow in TameFlow. However, at least in this book, Dan keeps to metrics which are more operational in nature.

The key doctrine of the whole book is presented here. It is about this realization: Unpredictability stems from poor flow! I couldn’t agree more!

Dan then lists a number of reasons why you might have poor flow. He observes that poor flow (or even lack of flow) is easy to detect: you need to keep an eye on the formation of queues. Yet, all traditional project management practices are simply blind to queues. Even Agile approaches, while having some mitigating practices that improve flow, are blind to queues too. That’s why both traditional project management as well as Agile approaches are inappropriate to manage flow. That’s why they are so bad at providing predictability.

The insight that there is an alternative, better way to manage knowledge work — which is different from both traditional project management as well as Agile — is very important, and one of the motivating factors that brought me to develop TameFlow. Once again, I am in complete agreement with Dan’s reasoning.

Actionable Metrics for Predictability

So what is this better way? In a simple word: metrics. But not any metrics, and especially not the metrics used by project managers or by agile practitioners. What is needed, instead, are actionable metrics for predictability. They must be “actionable” in the sense that they will trigger actions, and specific interventions; and such actions and interventions will improve the underlying process (and hence its predictability).

Collecting the metrics is really easy, and can even be done manually without any special tools. It can start very simply by measuring queue sizes; in other words, by counting the number of items in the queues. The sum of all the items in those queues are the Work in Progress (WIP). Then we need to look at the time it takes for any piece of work to go through the process, from start to finish. That is the Cycle Time (CT). Finally, the last fundamental metric is Throughput, or how many items are completed per unit of time.

These are the exact same metrics that we favor in TameFlow. The only difference, in fact, is in terminology, but the underlying concepts are the same! In TameFlow I prefer to describe the sum of all work as Work in Process. While work in a queue is standing still, it is still inside the process; yet when it is standing still in that queue it is not making any progress! Likewise, in TameFlow I prefer to use the term Flow Time instead of Cycle Time — see Replacing Cycle Time with Flow Time for the reasons why. Dan acknowledges that there are different terminologies, but what matters is not what we call things, but that we understand what they mean and what impact they have on our methods. Therefore, to be consistent with the book’s preferred terminology, throughout this series of posts I will henceforth use Dan’s terms: Work in Progress and Cycle Time. (Be aware, though, that if you read other material pertaining to TameFlow you will most likely find Work in Process and Flow Time instead.)

These metrics, in addition to supporting predictability have another distinguishing feature that make them qualitatively very different from other Agile or traditional metrics. Unlike the abstract Story Points, Velocity, Man-hours, Effort, these metrics speak the language of the customer. Customers have a good understanding of lead times and number of items ordered (“When is it ready?”, “How much do I get?”). Recalling the Agile doctrine of favoring “Customer Collaboration”, paradoxically these metrics are more agile than the Agile ones!

While gathering flow metrics is easy, deciding to adopt them is a huge challenge in most organizations. It requires a shift in thinking in addition to a shift in the performance variables considered. The shift in thinking is always difficult. Moreover, to have reliable flow metrics, it is necessary to have a stable process. Yet in order to make that happen, it is necessary to perform a shift in the actions that the organization customarily undertakes. In other words: ** Predictability depends not only on what you measure but also on what you do! **

The aspect of speaking the language of the customer is very interesting. It can be interpreted positively from the TameFlow perspective. In TameFlow we often refer to the noble patterns and transformative social forces of Unity of Purpose and Community of Trust. These actionable metrics are fully aligned with them. Focusing on Cycle Time reduction becomes a common objective for both the customer and the provider — unlike the adversarial relationship that often crops up from fixed scope or times and materials contracts.

Furthermore, focusing on a vocabulary that both customer and provider can understand and interpret in a common way, is a way to build trust which is so much more effective than the provider having to use hocus pocus language and then proclaim “Just trust me!” ** By employing actionable metrics, the Unity of Purpose and the Community of Trust of TameFlow actually expand beyond the boundaries of your own organization, and touches the customer too.**

This is a wonderful insight that will be added to TameFlow. Thanks, Dan, for prompting this!

Naturally, having a more predictable process — which is enabled by using these metrics — will go a long way in making the Community of Trust between provider and customer much more solid. If the provider is consistently able to communicate commitments clearly, and consistently keep what is promised, naturally the customer’s trust will increase.

These are all arguments that further support using flow metrics on the basis that they support two of the elemental patterns of TameFlow: Unity of Purpose and Community of Trust — and they do so in a way that actually includes the customer too.

For being just the first chapter, this is already a great contribution to the world of flow! What a great start!