Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles How a Flow Manager Helps Teams Deliver, Fast and Smoothly

How a Flow Manager Helps Teams Deliver, Fast and Smoothly


As agile software delivery practices and management evolve, so, too, do the roles. As we at Asynchrony have matured in our delivery over the last 15 years, we’ve incorporated extreme programming and Scrum, and, most recently kanban and the Kanban Method. Kanban has introduced us to the idea of managing flow, one of the method’s core practices. With talented developers, quality advocates and user-experience designers, our teams know how to deliver valuable software. But as we improve service delivery using kanban, who manages flow?

What is flow, and why do we need someone to manage it?

First, what is flow? Daniel Vacanti describes it simply as "the movement and delivery of customer value through a process” (Vacanti in Actionable Agile Metrics for Predictability). As such, it’s what most organizations are aiming for and trying to optimize, or at least trying to manage more quantitatively. David Anderson describes the core kanban practice of managing flow as measuring movement, emphasizing speed and smoothness: “Ideally we want fast smooth flow” (Principles of the Kanban Method). Mike Burrows elaborates that “Fast smooth flow means our system is both creating value quickly, which is minimizing risk and avoiding (opportunity) cost of delay, and is also doing so in a predictable fashion.” It is the goal of software delivery.

In our experience, though a delivery team may have an awareness of and individuals may have some interest in flow, their skillsets and focus are oriented toward the actual delivery of the work. An orientation toward the higher-level view or perspective of flow — at least for any prolonged period of time — isn’t what they do or even want to do. And yet teams do desire to understand the bigger picture and connectedness and meaning of their work (intrinsic motivation). So it’s important that someone provide that ongoing feedback within the team at a cadence that makes sense for the delivery team.

What about customers, stakeholders and executive sponsors? They care about flow, too, albeit from a different vantage point. Simply from an investment and risk-mitigation standpoint, our executive sponsors want to make informed decisions about the risk they’re taking on and how they can proactively help projects before it’s too late. For instance, if we take a delivery team with a $110,000 USD/month run rate (€100,000), that’s a big enough investment on both sides to warrant someone looking after flow. When you add the complexity of upstream and downstream services and teams, having someone manage flow is even more vital because those teams are often focused only on their own pieces of the pipeline.

And it’s likely not someone who simply drops in once in a while. As David Mann writes in Creating a Lean Culture,

… this [someone being available to respond right away] means focusing on the process as it operates from beginning to end, not only at the completed component or finished goods end. That’s why lean designs require so many team leaders to maintain the process, to spot problems in upstream intermediate or subprocess areas, and to respond right away… It requires a leap of faith not to scrimp on this crucial part of the system; having enough leaders available to monitor the process, react to problems, and work toward root cause solutions is an investment that pays off in business results. But at first, and from a conventional perspective, team leaders just look like more overhead.

Asynchrony’s Context

Asynchrony is a US-based information-technology consulting firm that specializes in application development for our customers. The product teams for those customers range from small collocated and cross-functional, teams of four to six to multi-team, multi-product programs. Because of the increasing complexity of our business, we need to be able to scale at the team and program level. So we’re experimenting with what we think is an emerging role in our particular context: the flow manager.

We actually got the idea from Christophe Achouiantz and his experience at Sandvik IT. He wrote in the InfoQ article 3 years of Kanban at Sandvik IT that the flow manager is the person taking leadership of the kanban implementation within the team:

The flow manager’s role does not actually exist in the Kanban Method (there are no prescribed roles whatsoever), but – in Sandvik IT’s context - we found out that there is the need for someone from within the team to take charge for the implementation to stick. The role has some similarities to a Scrum Master role, once removed from the project management aspects it often is loaded with.

The purpose of the flow manager is to make the team reflect and act: follows the policies it has created, create new ones when needed, discuss and act on exceptions (issues and opportunities), experiments to find creative solutions, etc. The flow manager inspires, challenges and coaches. This role really is an extension of the coach and is meant to take over when the coach phases out.

That was a great starting point for us: Our team model includes team leads, who are often tech leads laden with project-management responsibilities. But because we are a flat organization, we do not have the middle-management layer of many organizations where kanban is often best catalyzed. As a result, we have experienced the reality that David Anderson writes about: “Bottom-up initiatives tend to stall with only local improvements and boards that are best described as team (or personal) Kanban.” Without adding an entire middle management layer, we needed that “middle” support to improve service delivery to customers, without which we had little momentum to look at the whole workflow and focus on improving flow of work.

This accurately describes many of our teams, who focus on the technical, software-creation aspect of delivery — something we do well — but typically don’t often make time to "look at the whole workflow and focus on improving flow of work.” We have busy executive leaders and busy delivery-team members — but generally speaking we have no one “in the middle” to focus on improving service delivery per se. Often, the best technical people are elevated to team leadership roles, when the reality is that too many of those people either don’t like to do team management work (preferring to code), aren’t able to do team management work or both. As one colleague says, that’s like taking the best managers and making them developers, only the other way around.

Enter the flow manager

Our teams understand kanban primarily as a visual-management practice (Nearly every team has a kanban board). But until recently most teams haven’t fully understood the values and benefits of the Kanban Method. Now new hires play The getKanban Board Game. But the learning sometimes fades away once they start work and they get busy delivering. After conducting a depth-of-kanban assessment for a few teams, we found that though people are indeed interested in improving, they don’t necessarily know where to start — or how to continue.

One of the foundational principles of the Kanban Method is to “agree to pursue incremental, evolutionary change.” One agreed to, who spearheads this change? In our experience, teams don’t evolve (which implies a kind of passive or natural course) so much as they mature toward bettering themselves and their delivery. It’s a matter of intentionality. We needed someone to provide that intentional and disciplined approach to improvement. The flow manager is a catalyst of change within teams that believe themselves too busy to focus on improving. Mann writes about how bad habits are less “broken" than they are “extinguished.” We see the flow manager as a bad-habit extinguisher.

What does the flow manager do?

With Christophe’s description as a starting point, we enumerated standard work for the role:

  • Conduct a depth-of-kanban assessment and educate team on kanban values, principles and practices
  • Work with the team, customer and stakeholders to identify the system’s purpose and fitness criteria for it.
  • Visibly publish as explicit policies shared expectations on work item selection and quality criteria
  • Track where blockages occur and conduct root-cause analysis when they do
  • Help team follow the policies it has created (e.g., WIP limits and work selection) and discuss and act on exceptions to policies (issues and opportunities) after standup meeting
  • Ensure that all of the team's work items are organized visually by type, state, parallel work stream and class of service
  • Help team to size and select work items to optimize economic outcomes
  • Work with executive sponsor to communicate and remove system-wide blockers
  • Oversee improvement experiments (clearly state hypothesis, measurements, timings) identified at retrospectives
  • Help team create new or revise existing policies when needed
  • Report and make visible progress, demand and capability externally, both to customer and the wider organization (cycle times, flow efficiency, percent accurate and complete)
  • Facilitate operations review within customer "division" or program
  • Work with customer relationship rep to use data to create forecasts (e.g., with Monte Carlo simulations)

The flow manager can play an important part across the seven Kanban Cadences, the cyclical meetings that drive evolutionary change and "fit for purpose" service delivery (Anderson in Kanban Cadences):

1. Standup Meeting (recommended cadence: daily): While reviewing the work board, replace the traditional “three questions” with “What is stuck today? Where are we seeing flow? Where and why are blockages repeatedly occurring?”

2. Service Delivery Review or Retrospective (weekly): Manage improvements as experiments.

3. Operations Review (monthly ): Review existing policies that affect service delivery, flow management, capacity allocation and demand shaping.

4. Risk Review (monthly): Facilitate blocker clustering (Leopold), one of the key collaborative activities to conduct during a risk review (Anderson).

5. Strategy Review (quarterly): Review of positioning, segmentation, go-to-market strategy, fitness criteria metrics, fitness for purpose and strategy versus capability assessment

6. Replenishment/Commitment Meeting (Weekly)

7. Release/Delivery Planning (Per delivery cadence)

“I don’t care about metrics”

“I don’t care about metrics,” a developer/team lead said to me the other day. It wasn’t the first time I’d heard someone on a delivery team say it, nor will it be the last. It’s simply another way of saying, “I merely want to focus on creating great software.” Not everyone needs to care about metrics. But all team members should care about flow: The flow manager can track flow metrics and translate them into actionable information to help team members make informed decisions about their work.

Daniel Vacanti notes that to manage flow, we need to closely monitor three metrics, in particular: Work in progress, cycle time (or what I refer to as delivery time) and throughput. He avers that most earlier methodologies, like Scrum, were not designed from the premise that managing flow is the best strategy for predictability, so their metrics are insufficient at best and cause us to focus on the wrong things at worst. The flow manager should become intimately acquainted with how to effectively use a cumulative-flow diagram, as well as the next generation of digital tools that support flow metrics. In addition to the metrics Vacanti suggests, we have experimented with flow efficiency and percent complete and accurate (the rate at which work items complete without defect, rework or blockage). Learning how to quantitatively forecast future work (e.g., probabilistic project sizing by Bakardzhiev) should also be in the flow manager’s tool belt; we’ve begun doing this with our account reps for subsequent phases of certain projects.

Servant leadership and the flow manager

The flow manager can model servant leadership because the role is about helping the rest of the team succeed through practices like making work visible and policies explicit, using feedback loops and collaboratively experimenting to improve. By serving the team in this way, the flow manager helps teammates grow: they make informed decisions directly related to the flow of work. This promotes the kind of autonomy that enables “leadership at all levels.” (Contrast this to the close-holding of information and the long or unclosed feedback loops associated with authoritarian management.) This won’t always be the case, but the work of the flow manager can model and bring about the kanban values of respect, transparency, understanding, collaboration, customer focus and, of course, flow.

As Mike Burrows writes in Kanban from the Inside, leadership can be as simple as looking at the work board and asking about flow. Mike asks, “What if this kind of leadership doesn’t come naturally to your organization?” This is where the flow manager helps. As our teams transition from timeboxed delivery to more flow-oriented delivery, the flow manager can bridge the gap and help the team understand delivery speed and smoothness where timebox-style metrics, like velocity, are no longer applicable.

In our experimenting, we’ve found that flow manager work is more than a few hours per work job. In our context, depending on team size and existing roles, flow management is a half- to full-time role per software delivery team (e.g., four to ten people) or service. We’ve also found it work best when the flow manager is co-located with the team and is integrated as a regular team member, for two reasons. First, much of the need for flow management occurs between formal feedback loops like standup meetings and replenishment meetings. Second, it’s easy for the flow manager to become perceived as an outsider, someone who is merely checking in on the team, rather than someone working as a teammate to help them. In this way, the relationship is similar to integrated QA or operations team members.

Isn’t a flow manager the same thing as a scrum master, just for teams doing kanban?

Yes … and no. The flow manager is like a scrum master in that it’s a servant-leadership role and in the pursuit of continuous improvement . But it’s not about ensuring that everyone is doing his job or so focused on delivery of the product or on learning a methodology ("adhering to practices and rules"). Rather, it’s about catalyzing change and leading continuous improvement in the team, both up and down the organization.

At Asynchrony, the flow manager role isn’t a substitute for the scrum master, simply because we don’t have scrum masters. Rather, the flow manager addresses an emergent needs and activities not currently covered by our existing team model. One customer with whom we have worked to implement the flow manager role has both flow manager and scrum master roles on their teams, so the two roles aren’t necessarily mutually exclusive. That’s because scrum practices (the domain of the scrum master) aren’t necessarily mutually exclusive to Kanban Method (the domain of the flow manager). Also, a scrum master is focused at the team level, whereas a flow manager is concerned with services which may comprise or span multiple teams and interdependent kanban systems.

A role by any other name…

Why “Flow Manager”? Very simply, “Manage Flow” is one of the Core Practices of Kanban Method. Also, we like the new title because, for us as we evolve using the Kanban Method, it’s a new group of activities. Further, in our environment in which we have few formal and traditional people-manager roles, it makes sense to emphasize that the role manages the work (i.e., flow) rather than the workers.

Ultimately, the name of the role is less important than the work activities and value that it provides. Some call this type of role “service delivery manager.” Christophe Achouiantz stresses the “in our context.” As with any kanban implementation, you need to respect current roles -- you do not need to change people’s titles, at least not initially. Flow manager may not be helpful in your context; it may actually be harmful!

You may be intrigued by the idea of the flow manager role, either from an organizational perspective or personally. But you may be in an environment that resists new roles -- especially strange titles like “flow manager.” That’s okay. We, too, deal with customers (and even sometimes people in our own organization) that are change-averse. One way to introduce the flow manager role is to focus on the activities and responsibilities of the role first, regardless of the title of the person doing it. For example, project managers are often in a perfect position to evolve into flow-management work.

If you’re like us -- maturing into a more kanban way of managing software delivery -- you may want to consider rethinking roles. Whether explicitly calling someone a flow manager or simply having someone (or some people) doing the work of managing flow, it can be a vital role for improving the flow of value through your delivery system, from a simplicity of a single team to the complexity of a program or multiple interrelated services.

About the Author

Matt Philip is the Director of Agile Coaching at Asynchrony. He has worked in software development as a coach, trainer, quality advocate and facilitator, helping organizations and teams to improve themselves and business outcomes. He is especially passionate about continuous improvement, motivational design and the "Kanban Iceberg," on which he will be speaking at the upcoming Lean Kanban North America conference in Miami.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p