In Part 1 of this series, I pointed out that flow is not a team-level concern, to mean that the flow that really matters is the flow as perceived by the Customer, which usually needs to "weave" through multiple teams as it moves from "I promise" to "here it is". In this second instalment, we will describe some of the behaviours to acquire if we want to start managing flow beyond the Team.
Prelude: The "Team Focused" Starting Position
Also described in Part 1 is the concept of a Team Focused organization: one that has mastered the "teamwork problem", but that as result is now composed mostly of inwards-looking teams that tend to optimize locally rather than globally.
Flow management is not an exception, which is not to say that there aren't benefits for teams that achieve fluid movement of their work, even if it is within the confines of their line-of-sight. In fact, in order to achieve those benefits, some basic behaviours need to be adopted, which will serve as the baseline for more mature behaviours later.
The behaviours that allow a group of "unaffiliated individuals" become teams, within the context of managing flow, can be grouped in two categories:
The first category includes practices that enable the realization that not all the work is the same (personal tasks); rather, work items can be classified into higher-meaning categories (such as "user stories", "bugs", etc.), and they are collectively owned by the team (to various degrees of collective ownership).
This may seem surprising: classification categories and ownership conventions are not things that we might intuitively associate with managing the movement of pieces of work. However, before you can focus on that movement, there has to be some agreement on the object of that management, and who's responsible for it.
As this series progresses, I hope it will become apparent that this is a recurring pattern: within Manage Flow practices you will find not only techniques to deal with work that doesn't move, or to make it move more smoothly, but also practices that help establish preconditions to flow, or that address some lateral problem that will, when solved, facilitate better flow.
The second category of practices enables the agreement on a team-level workflow to represent the agreed upon process to deliver the work. A rudimentary "To Do/In Progress/Done" workflow is a common starting point, but often we see teams evolving it into something more sophisticated that starts showing the internal hand-offs between team specialties. Along with process step agreements, a team normally needs to also agree on basic policies to transition between them and how the team makes commitments.
Widening the View
As briefly alluded to in Part 1, the transition towards becoming a Customer Focused organization, leaving behind inward-looking behaviours, begins with the emergence of someone who explicitly takes on the responsibility of widening the view to start managing the end-to-end workflow, connected to a Customer on each end. This can take many forms (a discussion that it's outside the scope of this article), but suffice it to say that it can be a single individual or a group, from within the team or from the outside, and that this is the key act of leadership required for this leap in maturity.
Under that leadership, practices need to be established to enable three general behaviours:
Understanding who the customer is and what's meaningful to them;
Gaining basic awareness of end-to-end process; and
Taking action on systemic barriers to flow.
Who is the Customer? What do they care about?
If our intention is to optimize flow from the perspective of the Customers we serve, it's then important to know who those Customers are in the first place. Yet, it is surprisingly common to find teams who can't give a clear, unambiguous answer to a question like "who is your Customer?".
A second question to ask is "what kinds of work do you do?". Teams have an easier time answering this one, and replies will often include things like "user stories", "bugs", "tests", "tasks", etc. Regardless of the answer, here are two additional follow-up questions you can ask: "can you have a meaningful conversation with your Customer about them?", and "are these meaningful enough to them to be used as units of trade during replenishment?" (that is: "are these things they care about?").
One relatively simple way to start turning this around is to make sure we formulate the work from the perspective of the people who will benefit from it, using work types carrying names they will recognize. If we can have a meaningful conversation with a Customer about a particular piece of work, in a way that is meaningful to them and that can be used as a unit of trade during Replenishment, we then have we call a "Customer Recognizable Work Item Type". Typical examples of customer recognizable work types might include things like "epics", "features", "capabilities", "projects", "use cases", etc.
You might be surprised not to find "user stories" in the example list above. In fact, user stories can be formulated in such ways that comply with the customer recognizability criteria (and it could even be argued that this is "the way stories are meant to be used"). However, that is rarely seen in the real world: most often, user stories are written to satisfy needs to decompose a piece of work into manageable chunks, and in the process they either become unrecognizable for the Customer (like in the case of "technical stories"), or not meaningful enough to make trade-off decisions (like the story that simply adds a button to a screen), or both.
You might also be concluding that customer recognizable work items are then always "large pieces of work". It is possibly true that in general they are going to be bigger than individual team-level tasks. However, there's nothing preventing you to work with your Customer so that, through a process of mutual education and agreement, work can be sliced into smaller and smaller pieces that retain recognizability and value. Reducing batch size has always been recognized as a way to increase flow, therefore progressively reducing the size of "epics" and "features" (perhaps getting them to the size of what we'd simply call "a story") might be a worthy goal.
At the same time, modeling the work through customer recognizable items doesn't necessarily mean eliminating inwards-looking work types completely; it can be useful in some cases to keep them (at least initially) but as subordinate tasks that are part of delivering a customer-recognizable piece of work.
This switch of perspective can help raise awareness of the service nature of the work the group performs, and it's a very common first step in the transition from Team Focus to Customer Focus.
Gazing Far and Wide
What happens to the work before it's taken by your team? What happens to it after the team calls it "done"? Normally, you’ll discover that around the process the team acknowledges as their own, there is also some form of “elaboration” process required to get the work ready, and that there’s another “release” process required to put it out.
Part of the elaboration process actually happens within the team (often under names like "grooming" or "backlog refinement"), but it's seldom visualized. On the tail end, something similar happens to release activities: it's not uncommon to find that once work has been called "done", there are still a few activities required to release it (configuring feature toggles, running deployment scripts, writing release notes, etc.), but that work is often represented as additional "technical stories", or not visualized at all. In both cases, the result is that this activities are kept implicit and not acknowledged as part of the workflow.
I've written elsewhere in more details about how you can extend your line of sight to make elaboration and release more visible. The result is the emergence of an upstream and downstream workflow that starts raising awareness about the longer, end-to-end journey work needs to traverse.
Once line-of-sight becomes wider, it's often the case that it becomes apparent that the team is not alone inhabiting that end-to-end workflow: other teams and groups may be involved in those downstream and upstream activities, making then obvious that they need to be considered when attempting to manage flow at this level.
You can, of course, keep going, and expand the view even further upstream and downstream, as far as your sphere of influence permits.
Finally, a wider perspective on the workflow can enable a better understanding of commitment: at what point do we make promises to Customers, and what's the nature of that commitment? how far do we need to work in order to deliver in that commitment? With that understanding, we gain the ability to perform some rudimentary measurements of System Lead Time, taking the first steps towards quantitative analysis of flow.
Addressing Systemic Barriers to Flow
With all this foundation in place, we are now in a better position to understand what prevents work from flowing smoothly, and take corrective action: end-to-end visualization will allow us to see places where work piles up, while quantitative measurement (even if imprecise) can allow us to see how lead time distributes over time, and ask questions about those occasions when it tool too long for comfort. All this can help narrow down the focus of our attention when looking for improvement opportunities.
Aging WIP is a relatively simple indicator that can also be tracked to spot work that has stopped moving, and it can be as simple as just adding some "dots" to tickets with each passing day. This can then be combined with the definition of "trigger points" to take some action if a particular piece of work has stayed on the board for too long.
In addition to delays caused by multitasking on high WIP, typical barriers to flow include waiting on external dependencies, reliance on non-instant availability of resources, and waiting on queues and buffers.
It's important to realize that, while solving individual blockers affecting specific work items is an important aspect of managing flow, the discovery of systemic causes to those blockers can have a much bigger impact.
To do this we need to be able to detect general patterns that tend to reoccur. A useful technique to do this is blocker clustering, a technique pioneered by Klaus Leopold consisting on tagging work items with "blocker tickets" that are later collected and analyzed to discover how they cluster together over time and use that information to determine impact, likelihood and corrective options.
Comments