Many of our future planned posts will refer to a concept known as Flow. For as much as Flow is talked about in Lean-Agile circles, there really aren't many reliable definitions for what Flow actually is. Our inspiration for the definition we will use going forward is the definition of Flow that is found in the Kanban Guide (and by inspiration, I mean the document that we will shamelessly steal from).
What Is Flow?
The whole reason for the existence of your current job (team) is to deliver value for your customers/stakeholders. Value, however, doesn't just magically appear. Constant work must be done to turn product ideas into tangible customer value. The sum total of the activities needed to turn an idea into something concrete is called a process. Whether you know it or not, you and your team have built a value delivery process. That process may be explicit or implicit, but it exists.
Having an understanding of your process is fundamental to the understanding of Flow. Once your process is established, then Flow is simply defined as the movement of potential value through that process.
Flow: the movement of potential value through a given process.
Flow: the movement of potential value through a give process.
Maybe you've heard of the other name for process, known as workflow. There is a reason it is called workFLOW. Because for any process, what really matters is the flow of work.
Note: In future posts, I will often use the words "process", "workflow", and "system" interchangeably. I will try my best to indicate a difference between these when a difference is warranted. For most contexts, however, any difference among these words is negligible so that they can easily be used synonymously.
The reason you should care about Flow is because your ability to achieve Flow in your process will dictate how effective, efficient, and predictable you are as a team at delivering customer value--which, as we stated at the beginning, is the whole reason you are here.
Setting Up To Measure Flow
As important as Flow is as a concept, it can really only act as a guide for improvements if you can measure it. Thankfully for us (and thankfully for ActionableAgile™️), Flow comes with a set of basic metrics that will give us such insight. But before we can talk about what metrics to use, we need first talk about what must be in place in order to calculate those metrics.
All metrics are measurements, and all measurements have the same two things in common: a start point and an end point. Measuring Flow is no different. To measure flow, we must know what it means for work to have started in our process and what it means for work to have finished in our process. The decision around started and finished may seem trivial, but we can assure you it is not. How to set started and finished points in your process is beyond the scope of this book, but here are some decent references to check out if you need some help.
It gets a little more complicated than that because it is perfectly allowed in Flow to have more than one started point and more than one finished point within a given workflow. Maybe you want to measure both from when a customer asks for an item as well as from when the team starts working on the item. Or maybe a team considers an item finished when it has been reviewed by Product Management, put into production, validated by the end user, or whatever. Any and all permutations of started and finished in your process are allowed.
Not only are the different permutations allowed, it is encouraged that you experiment with different started and finished points in your process to better understand your context. You will quickly learn that changing the definition of started/finished will allow you to answer very different questions about flow in your process. If all goes well, expanding your started/finished points will get you down the path toward true business agility.
The point is--as you will see--that the questions that Little's Law will help you answer will depend completely on your choices for started and finished.
Conclusion
Assuming you care about optimizing the value-delivery capabilities of your process, then you should care about Flow. And it should be pointed out that it doesn't matter if you are using Scrum, SAFe, Kanban, or something else for value delivery--you should still care about Flow.
Therefore, if you haven't already, you need to sit down and decide--for your process--what does it mean for work to have started and what does it mean for work to have finished. All other Flow conversations will be dependent on those boundary decisions.
Once defined, the movement of potential value from your defined started and finished points is what is called Flow. The concept of movement is of crucial importance because the last thing we want as a team is to start a whole bunch of work that never gets finished. That is the antithesis of value delivery. What's more, as we do our work, our customers are constantly going to be asking (whether we like it or not) questions like "how long?" or "how many?"--questions that will require our understanding of movement to answer.
That's where Flow Metrics come in...
About Daniel Vacanti, Guest Writer
Daniel Vacanti is the author of the highly-praised books "When will it be done?" and "Actionable Agile Metrics for Predictability" and the original mind behind the ActionableAgile™️ Analytics Tool. Recently, he co-founded ProKanban.org, an inclusive community where everyone can learn about Professional Kanban, and he co-authored their Kanban Guide.
When he is not playing tennis in the Florida sunshine or whisky tasting in Scotland, Daniel can be found speaking on the international conference circuit, teaching classes, and creating amazing content for people like us.
Comments