BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles The Essence of Flow

The Essence of Flow

Bookmarks

Introduction

How do you get good flow in a process? Recently I attended a ”Lean Coffee”-meeting in Stockholm, Sweden. At the meeting there was a person that described their situation with one team of four developers serving the needs from four different product owners. She explained that the situation was scattered. This made me reflect on this situation that I think is pretty common, and how Lean and Agile can help out.

A process with bottlenecks

This a generic picture describing a process. It could be any type of process where requests come in to one end of the process and deliveries go out of the outer. Inside the process a number of value adding steps take place. If the process doesn’t add any value, these is no reason for its existence. All processes have limitations in the form of bottlenecks/constraints [1].

The ”most narrow” bottleneck determines the flow or throughput of the whole process. One key concept in Lean is kaizen, that means that you should work with continuous improvements to your process. When one bottleneck is fixed another will be the ”most narrow”, hence you need to continue your kaizen efforts that never ends. The process is the most valuable thing a company have, more valuable than its products and services (that will come and go over time). Improvements to your process hopefully stay forever!

Sadly, my experiences from the software development industry is that we care more of what we do (our products and services that are somewhat volatile), then how we do it (our process that will eventually define company success in the long run). Hopefully this can change to the latter in the software industry. To get flow you need to focus.

Too scattered is a common situation

This is a situation that I think is common in a lot of software companies. Focus is scattered ”all over the place”, on a number of different products and services that the company provides. We tend to do a little bit of this, and a little bit of that, not to ”loose out” on something that could be ”the next big thing”. Since we are doing many things at once we become too ”thin” and all the context switching between tasks [2] makes us produce less and less actual value. To not be able to predict when things can be done, we have to start things earlier to increase the work in process even more. Work in process means all the work you have ongoing at the same time. You end up in a vicious circle. In software development there are no natural limits to work in process (all the work takes place inside our heads or in servers). In a factory there are physical limits, for example limited floor space.

In fact, the lack of focus makes us more likely to be unsuccessful. In the ”Steve Jobs”-biography [3] there is a section that tells about an offsite meeting with all executives at Apple. If I remember correctly, the executives had like 100 different ideas that they thought would be ”the next big thing” and they wanted the company to support and finance. Comparing the ideas with each other and discussing them during days of meetings they finally boiled it down to three. The benefit now was that the whole company was behind those three ideas, and the focus they could get was tremendous.

We want to streamline and increase throughput

This is what we want to achieve:

• Streamline our business to focus on fewer things at the same time (i.e., have less work in process) and thereby increase throughput and shorten lead times

Kaizen, continuous improvement to the process to handle the bottlenecks and gain flow

• Deliver smaller increments that faster bring continuous value to our customers.

Example of good Flow - Relay baton

I’m a big fan of sports, athletics included. The 4 x 100 meters relay are usually very interesting and exiting events at the World championships or in the Olympics.

The current world records (for men):

  • 400 meters: 43.18 seconds, by Michael Johnson from Sevilla (26 Aug 1999)
  • 4 x 100 meters Relay: 36.84 seconds, by Jamaica from London (11 Aug 2012)

The relay time by the Jamaican team is 15% faster, but Michael Johnson is one of the best athletes ever lived. How can this be? There are two reasons:

  1. Each individual in the Jamaican team could run at maximum capacity (400 meters is not long, but it is not possible to run with the same speed as for 100 meters)
  2. No velocity loss in the exchanges of the relay baton

So in this case 1+1+1+1 don't become 4, it becomes something even more! How can we translate this to our context?

One piece continuous flow

In Lean the true ”Nirvana” is one piece continuous flow. Where one piece is flowing between the value adding steps in the work process without any waiting time or stocks in between. Like the relay baton! Which of the reasons above can we start to work with? Of course you can (and should) hire the most skilled people and make them perform at their best, but the most interesting thing are the exchanges between the runners. In fact a country with less skilled runners can compete and do really well in the Olympics or World Championships if they practice their exchanges to perfection. In the finals it often happens that one of the favorite countries will fail in an exchange and thus be disqualified.

In your organization, will you practice the exchanges between the steps in your process? Or is your focus only within the process steps?

Let’s say that our ”runners” are represented by: Analyst, developer, QA & deployer. How is the exchange of the task (the requirement) happening between the analyst and the developer? Do the developer ”get up to speed” on the requirement before it’s handed over? Do the analyst ”run along” together with the developer to make sure that nothing is lost in the exchange? My guess is that in most of the cases the task is queued up in between (for example in a tracking system).

Learning from the relay baton example

What is there to learn from this example? First of all we need to practice on the exchanges to make them as smooth as possible. This can’t be done when we are ”in competition mode” (i.e. doing our daily work delivering to our customers). We need to take a step back, reflect on our behavior, and then make changes to get continuous improvements. Second is the focus and information sharing if you like. All ”runners” are fully aware of what to do and when to do it. They have all the information needed as they can oversee the ”whole race”.

How to achieve Flow

How do we achieve good flow in the software business? For many organizations a shift in mindset is needed. Today we tend to focus on high resource efficiency (people to be busy at all times). Opposite to high resource efficiency we have high flow efficiency (work moves fast through the process). What we must do is to temporarily ease the focus on resource efficiency, get ”slack” (resources becomes available) so that flow is prioritized and then improve your process (kaizen) so that resources can work more efficient. Usually only 1-5% of the time is value adding of the total lead time, 20% valued added is a high number [4].

What we want to do is to create teams that spans the full value stream including all functions/competences needed. By doing this we make sure that the hand-overs are as smooth as possible, they are happening between teammates that knows each other and works towards the same goals. The three things that makes a great team are: autonomy, mastery and purpose [5].

Examples how to get flow

Here are some examples on how to achieve flow in your process [6]:

  • Limit WIP - By limiting the work in process you will make sure that work moves faster through your process. Instead of a team member starting a new task when they are done with the current, they should always think ”Stop starting, start finishing”. This could mean helping out another team member with testing to get that task to done instead.
  • Reduce wait times - Investigate why tasks are waiting and work hard to shorten the wait times. Questions to raise:
  • Why are tasks queued up? Maybe its time to address the bottleneck that you already know of.
  • What will make the needed decision to happen? Call for a meeting with involved stakeholders to get things going!
  • Is there a way to temporarily remove the external dependency? Maybe you can write a simulator of the external system. Doing this you achieve flow but you have a ”technical debt” that you may need to ”pay” later (when the external system becomes available and is not working 100% as you anticipated in the simulator).
  • Cross-functional teams - As described in previous section we want to create teams that holds all competences needed to fulfill the whole value stream, this is called cross-functional teams. Having ”everything needed” within the team we minimize external dependencies and possibly eliminate hand-overs from other teams that can cause delays and prevent flow.

Summary

In this article I have talked about that all processes are constrained by bottlenecks. A common scenario in a software development company is that too much is going on at once, the work is too scattered and too thin. The relay baton in 4 x 100 meters Relay is a good example of flow. Finally a shift in mindset is described, to go from focus on resource efficiency to focus on flow efficiency and then some examples how to get flow are given.

About the Author

Tomas Rybing lives in Stockholm, Sweden and has been working in IT since 1996, starting as a consultant and programmer. From 2007 his focus has switched to team leading, project leading, product management and development methods. He has a wife and two kids. His main interests are sports, music and traveling. You can reach Tomas via his email, blog or twitter handle.

 

References

[1] Theory of constraints

[2] Context switching – Public Enemy No. 1?

[3] ”Steve Jobs”, Walter Isaacson, ISBN 978-1451648539

[4] The Busy Bee Paradox

[5] Drive: The Surprising Truth About What Motivates Us

[6] ”Kanban in Action”, Marcus Hammarberg & Joakim Sundén

Rate this Article

Adoption
Style

BT