Updated: Nov 3
What kind of “flow” is that “flow?
When talking about “managing flow”, what “flow” are we referring to exactly?
There’s the aspect of flow that refers to personal productivity, and it’s achieved within the zone that intersects our perceived level of challenge with our level of skill: people (and teams) are said to be “in the zone” when they feel their work moves along with ease, as if time were suspended. This kind of flow certainly needs management, but its not the flow Kanban refers to with its "manage flow" general practice.
Let’s remember that Kanban encourage us to manage the work, not the workers. This work needs to move from the point where a delivery promise is extended to a Customer to that other point later when that promise is fulfilled and that value is delivered. Customers have expectations about how fast that delivery should be, and how predictable; we also know that regular (or smooth) delivery of value helps to build trust. Therefore, paying attention to how work moves (or flows) between those two points (from “I promise” to “here it is”), it’s important if we want to offer a fit-for-purpose service to our Customers.
Flow is not a team level concern
Agile teams are usually told about the importance of paying attention to flow, which is then interpreted as keeping work moving smoothly from "To Do" into "Done". How is all that different from movement from "I promise" to "here it is"?
First, the "I promise" moment often takes place upstream respect to the team, and very often earlier in time respect when the team gets involved. This suggests that even before the work reaches the team's backlog or the "To Do" column in their board, there must be some process that allows that movement to happen.
On the other end, the “here it is” moment is also often displaced in time respect to when teams declare work items “done”. Even when teams implement continuous delivery practices, it’s not uncommon that a minimum batch of features have to be “done” before customers can see them (often by the use of “feature toggles”). In more traditional environments, integration testing, certification, and release management procedures are commonly in place in the tail-end of a development process.
An additional factor to consider is that it is very unusual to find the space between “I promise“ and “here it is” occupied by a single team. More frequently, we can observe that multiple teams, groups, and individuals (often from multiple departments) need to collaborate in that space for value to be delivered to the Customer.
The implication is, then, that although flow within the confines of a team is something to pay attention to, in order to manage flow end-to-end to make it fit-for-purpose we need to look beyond the team and focus on the “white space” in between them.
This ability to look beyond teams to increase the effectiveness of end-to-end delivery requires the introduction of new behaviours that go beyond establishing well functioning, high-performance teams.
In Kanban we describe this widening of focus as a matter of increasing “organizational maturity”, as codified in the Kanban Maturity Model (KMM).
The KMM describes a sequence of "prototypical stages" organizations usually go through as they evolve their capabilities, and it can be used as a "road map" to help an organization transition between those stages, by adopting specific practices that have been observed to help propel and consolidate that transition. Transitioning, then, from one maturity level to the next, is achieved by incorporating new behaviours, through the adoption of specific practices, all that hopefully leading to better outcomes.
The road to higher maturity flow management
Assuming that your organization has reached the capability to organize people into relatively well-functioning teams, how do you go about widening your view to improve flow as perceived by their customers?
Looking at the KMM for guidance, first notice that a "Team Focused" organization (Maturity Level 1) has mastered the "teamwork problem", but those teams are usually "inwards looking": the emphasis on teamwork can easily lead to a situation where each team develops their own identity. They become highly cohesive, they feel they have a mission and they put all their energy towards that. The downside is that it’s very easy for these teams to be conditioned to think locally, rather than globally, and to develop an understanding of the work and the processes to manage it that are framed to attend more to their their internal needs, than those of their Customers.
Some organizations can persist at this stage for a long time, even indefinitely, but many eventually graduate to the next level: eventually someone takes charge and starts realizing that teams are part of larger value streams, or delivery systems, that need to be managed as first-class concern, rather than expect that the optimization of the whole will be the result of optimizing teams independently. Taking responsibility for that end-to-end system, this person tries to put the big picture back together. What happens here is that line of sight starts extending beyond the team and towards end-to-end value streams. The understanding of the work and the customer deepens and the organization becomes more "Customer Focused" (Maturity Level 2). As a result Customers start experiencing better service, although they will still describe it as unreliable and inconsistent.
In terms of new behaviours to manage flow, this maturity transition from "inwards-looking teams" to "customer-aware system of teams" requires:
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.
Once end-to-end awareness and visibility have been achieved, the next stage of evolution occurs when the whole value stream becomes focused on making the customer experience "Fit for Purpose" (Maturity Level 3). The main contrast between this stage and the previous one is that the service, as perceived by the Customer, becomes reliable and with consistent outcomes.
New flow management behaviours that move an organization from "customer-aware system of teams" to becoming a "fit-for-purpose" organization include:
Evolving more sophisticated understanding of the activities in the workflow;
Developing basic ability to shape demand;
Increasing quantitative awareness of flow;
Developing the ability to forecast; and
Understanding what makes your service “fit for purpose”
There’s a catch, though: at this stage it’s very easy to satisfy customers in ways that are unsustainable for the organization in the longer run. Think of the case of companies building products customers love, but leaving lots of technical debt behind, or by bending and circumventing some regulatory rules that now leave the company exposed to some legal risk.
To improve on this situation, the organization needs to develop the ability to manage work in ways that balance multiple needs and risks, becoming a "Risk-Hedged" organization (Maturity Level 4). Fundamentally, it's about getting to the realization that everyone is better off if the organization is sustainable in the long run: customers not only like reliable service, but they also dislike when services and products they have become accustomed to unexpectedly disappear. And that’s also good for stakeholders.
The flow management behaviours that enable this transition from "for-for-purpose organization" to "continuously fit-for-purpose" organization are:
Developing the ability to take explicit actions to smooth out flow within a workflow;
Increasing sophistication for quantitative analysis; and
Developing the capability to explicitly allocate capacity
(Note: The KMM recognizes additional levels beyond Level 4, but we'll leave them out in the context of this discussion about flow)
In the remaining articles in this series, we'll be exploring the specific practices associated with those behaviours in more detail.
Continue reading: Part 2, Looking beyond the Team