Photo by Stackie Jia on Unsplash

Improving Flow

Philip Rogers
A Path Less Taken
Published in
7 min readApr 8, 2016

--

Let’s start by recognizing something fundamental about the way the human mind works: we can focus on one thing at a time. I often hear people say, with great pride, “I’m a great multi-tasker.” What would be more accurate to say is “I can switch rapidly between tasks;” the fact of the matter is, when it comes to complex tasks, or what some would refer to as “knowledge work,” it’s important for us to recognize not only that we are working on one thing at a time, but also that there is a switching cost that we incur, each time we jump from one task to another.

The (Not So Hidden) Costs of Context Switching

Let’s say that we’re in a virtual meeting with eight other people, and that we’ve been discussing a particular topic for five minutes. A question comes up that requires input from a particular person; let’s call that person Mike. After a long pause, Mike chimes in with “could you please repeat <fill in the blank question>; I was multi-tasking.” In fairness to Mike, he might in fact be under a lot of pressure to finish something that is completely unrelated to what we’re talking about. That being said, this all-too-common situation illustrates the cost of context switching. In this particular example, the cost of context switching might seem relatively low, in that we might spend no more than a minute or two reframing what we’ve been talking about for Mike. Still, multiply that one or two minutes by the eight other people that are in the meeting, and the costs can accumulate quickly. And as soon as we start multiplying the cost of context switching across multiple people, and ultimately, multiple teams, it can become quite significant.

At this point, some of us might still be pushing back on the notion that we can’t successfully multi-task. And indeed, many of us multi-task frequently, for instance, when we are driving and talking on the phone at the same time, and maybe even having a snack while we’re doing both of those things. And yet, if we’re being completely honest, we are not as focused on driving if and when we are doing one or both of those other two things. That lack of focus can have tragic consequences.

Let me share a personal example. I was a volunteer firefighter and EMT for many years, and I still vividly recall the first time I was dispatched to an accident scene as an EMT. When I arrived on scene with my fellow first responders, what I saw were two people, and one bicycle, lying on the ground not far away from one of them. What had transpired was that one person, the pedestrian, was walking and reading a book at the same time, on the side of the road that faces oncoming traffic (walking on that side of the road is a common practice for pedestrians, and for good reason, so they can see oncoming traffic). To provide additional context, this was a lightly traveled road, and I would not be surprised if the pedestrian had a habit of doing this on a regular basis. Unfortunately for both the pedestrian and the cyclist, they happened to crest a hill at the same moment, and they collided with each other. It did not end well for either of them, and, as you might imagine, the pedestrian in particular had some significant injuries.

Achieving Flow in a Team Context

For any kind of work, and for knowledge work in particular, keeping the number of things competing for our attention to a minimum at any given time is absolutely critical. In an Agile team context, concepts and practices that tend to minimize disruption to flow include those that I describe below.

Setting Aside Uninterrupted Work Time

It’s important to recognize that we benefit tremendously from having blocks of uninterrupted time to get work done, whether we are working individually, in pairs, or with multiple people. Here are a few examples of things we can do to minimize interruptions:

  • It is common for teams to formalize the preservation of uninterrupted work time, most often via a “Team Working Agreement” or “Team Charter,” where common provisions include specifying a block of time when we agree we are NOT watching a Slack channel, Email, or anything else that tends to interrupt flow (even if it’s as little as one or two hours a day, it can make a difference).
  • Specifying a block of time when we agree we ARE reachable via Slack, Email, etc.
  • Setting aside one day per week (or more than one day!) when we do not schedule any meetings.
  • Getting as much mileage as possible out of the meetings we do schedule (and minimizing meeting quantity and duration).

Note: For help with creating an initial version of a Team Working Agreement, see my blog post The Team Canvas: Building Trust via Transparency.

Considering Flow When Scheduling Meetings

It’s possible for us to recognize that at least some meetings are necessary, AND that there are steps that we can take to minimize the impact that meetings can have on flow, by taking steps such as:

  • If multiple meetings on the same day are necessary, schedule them for as short a timebox as possible (which requires meeting discipline — for instance, being very precise about meeting objectives and outcomes, and setting aside only as much time as is really necessary), AND;
  • Schedule meetings consecutively, where possible (to reduce context switching)
  • For Scrum Teams, for Sprint Planning meetings, for example, recognize that we want to be able to answer three questions when we’re done, the first two of which necessitate that the whole team, along with the Product Owner, be present: Why is this Sprint valuable? (converging on a realistic Sprint Goal); and What can be done during the Sprint? (achieving alignment on our forecast for much much we as a team can complete during the Sprint). To answer the final question, How will the chosen work get done?, there is a good chance that the Product Owner does not need to be present for that portion of the conversation, and teams often find creative ways to minimize how much time they need to spend in order to answer this question, for instance, by splitting into pairs or other small groups.

Keeping Track of Interruptions

In his book Toolbox for the Agile Coach: Visualization Examples, Jimmy Janlén offers a wonderful collection of ways to visualize work in a team context. An example of one of those techniques is Interruption Buckets, and here are some instructions on how to use this technique.

Purpose:
Identify who gets interrupted, and how often, then see whether there is a way to reduce interruptions.

Materials:
Writing materials, flip chart/white board (or, for distributed teams, make a digital representation)

Steps:

  • Draw a diagram similar to the one below, where each “bucket” (column) is the source of the interruption
  • Each time an interruption originates from a particular source, add a Post-it note (or similar identifier) to the applicable bucket
  • On a periodic basis (for instance, during Sprint Retrospectives), look for patterns in the data and see what can be done to reduce interruptions from one or more sources.
Interruption Buckets, from Jimmy Janlén’s book Toolbox for the Agile Coach

Kanban and Flow

The techniques above constitute a good start when it comes to reducing interruptions and improving team flow. Teams that pay close attention to flow ultimately choose to employ Kanban. There are plenty of excellent resources about Kanban, and here are some examples:

  • In the blog post Scrum vs Kanban: Management’s Explicit Invite, Paul Boos and Trent Hone offer insights into one of the most commonly misunderstood aspects of Kanban (and also Scrum) — the nature of the support that is needed from organizational leaders for teams to be successful with Kanban and/or Scrum.
  • In the blog post Improving DevOps Flow with Kanban, Trent Hone describes specific examples of how Kanban helped a team realize more predictable output and enhance the ways in which they worked together.
  • Of the numerous books that are available about Kanban, a couple of my favorites are Kanban in Action, by Marcus Hammerberg and Joakim Sundén, and Agile Project Management with Kanban, by Eric Brechner.

What Mihaly Csikszentmihalyi Has to Say About Flow

In his TED Talk, just before he closes, the author of the well-known book about flow displays a slide which summarizes what’s he’s found to be typical of achieving a flow state, the contents of which are shown below:

  1. Completely involved in what we are doing — focused, concentrated.

2. A sense of ecstasy — of being outside everyday reality.

3. Great inner clarity — knowing what needs to be done, and how well we are doing.

4. Knowing that the activity is doable — that our skills are adequate to the task.

5. A sense of serenity — no worries about oneself, and a feeling of growing beyond the boundaries of the ego.

6. Timelessness — thoroughly focused on the present, hours seem to pass by in minutes.

7. Intrinsic motivation — whatever produces flow becomes its own reward.

Conclusion

Achieving a consistent state of flow may seem elusive in many organizational and team contexts. Even in the absence of formal support, there are steps that we can take, both on an individual level, and on a team level, to help us stay “in the zone” for significant chunks of time. I hope that the techniques that I describe in this blog post serve as examples of experiments that we can run to increase our chances of preserving blocks of time for uninterrupted work.

--

--

Philip Rogers
A Path Less Taken

I have worn many hats while working for organizations of all kinds, including those in the private, public, and non-profit sectors.