Confessions of a Flow Junkie

1

Hello. My I’m Dave. I’m addicted to Flow.

I can no longer avoid the truth; I seek to maximize flow in all areas of life, not just software delivery.

2

The revelation came recently as I griped about how our dog and the kids were occupying the one area of our hallway that would completely choke off any flow to or from the door.

We had to get out and get to school, and they were blocking my flow!

3

I had started to suspect my addiction some time ago. I became conscious of being irritated upon entering the local Costco, when people in front of me would grab their flyer for the daily specials and immediately stop dead right inside the door.

Flow was again disrupted.

I was annoyed later when shoppers would stop in the middle of the aisle to look at an item rather than moving to the side, again blocking my flow.

When you pick a checkout line, it will automatically become the slowest line in existence! One bloody price check, and my flow is gone!!

4

This really isn’t a new addiction. I can look back over my life and see plenty of examples. Driving to work - well OK, to pretty well anywhere - is ripe with instances of disrupted flow slowing all traffic. Right near my home, there’s a traffic light where there is a left-turn lane but not one for right turns. So if the first car in the line is going straight through the light, all cars behind have to wait for green. My flow has been disrupted!

When I’m driving, I’d rather go out of my way in order to keep moving than sit stopped in traffic. Anyone else do that?

They say that in Canada there are two seasons – Winter and Construction, and both are wildly successful at disrupting Flow!

5

Even in my family life, I crave flow. I long ago avoided large dinners where all food was placed on the table and passed about. My eating flow was always completely and utterly disrupted by another family member selfishly wanting his share of the turkey dressing. Ah, there’s nothing like having cold leftovers... IN THE MIDDLE OF THE MEAL!

No, sir; when I was the host, I immediately established buffet style as the process in order to maximize flow.

Give me my potatoes... I mean Flow!

6

When I was a teenager, I even changed how I cut my parents’ lawn by rounding off the 90-degree corners to save 10 minutes of precious time since I wouldn’t have to stop moving at each corner.

I MUST HAVE FLOW! GIVE ME MY FLOW!

7

My name is Dave. I’m addicted to Flow.

8

Who else here is addicted to... er, likes Flow?

Tell me a quick story about your experience with Flow.

9

So, why do we care so much about Flow. Why is it so important?

Maybe I’m obsessive-compulsive, or have ADHD. I’m certainly impatient, and anyone who knows me will attest to that fact. But there must be more to it.

The truth is, outside of software development a lot of people care about Flow.

10

Traffic Management is a science of its own, that is completely dedicated to maximizing flow.

Multi-lane roads improved flow by increasing the capacity and minimizing the disruptions caused by differences in speed of different vehicles. Turning lanes reduce the disruption caused by cars that must wait until it’s safe to make the turn.

Restricted access roads – freeways, expressways, etc. – increase flow by eliminating intersections and replacing them with interchanges.

Ramp meters increase flow on the freeway by controlling the number of vehicles entering at any time.

Roundabouts reduce the necessity to completely stop at an intersection, thus increasing flow.

11

Airport check-in may seem to take forever, but in most cases Flow has been improved by implementing a single queue of passengers served by multiple check-in counters. This is a standard application of Queuing Theory, which ensures that if one counter is slowed down the others are still able to process passengers.

Contrast that with the single line per checkout model that most grocery stores use. Like I mentioned with the Costco example, one price check and the entire line at that checkout is disrupted. Of course, it’s always YOUR line that has the price check!

12

The classic example of maximizing flow is the Toyota Production System, which was developed over nearly 30 years. That length of time is an indication of the amount of introspection that’s required to be able to truly maximize the flow in a complex process.

Lean Manufacturing took the lessons learned from the TPS, but many believe that the elimination of waste is the primary goal. In fact, reducing waste is just a means to an end – maximizing Flow.

13

Those are all examples of process-level Flow. Flow also exists at the personal level.

Mihaly Csikszentmihalyi described a state of mind where you are in “a state of concentration or complete absorption with the activity at hand and the situation”. We also know this state as “in the zone”, “in the groove” or “on fire”. We lose track of time. We don’t notice that we’re hungry. Sounds and activity around us fade into the background. This is a state where we are, as individuals, most productive.

Sounds pretty good, right? It is, but only to an extent.

Let’s try a little game that illustrates Flow.

14

This is a variation of a game many of you will have already played. It will demonstrate both individual and team flow, and optimizing both.

• I need 9 volunteers – 1 CEO, 4 Managers and 4 Workers.• The CEO chooses the Managers and Workers.• Management gets the stopwatches• The Workers flip 20 coins• Each Managers times his or her Worker• The CEO times the entire process• The process is run 3 times, each with a different batch size:

• 1st round – flip 1 coin and then pass to the next person, repeating until all the coins have been passed• 2nd round – flip 5 coins and then pass to the next person, repeating until all coins have been passed• 3rd round – flip all 20 coins and pass to the next person

Note that the fastest individual times resulted in the slowest team time, and the fastest team time resulted in the slowest individual times. This is a key concept –maximizing Flow at the individual level results in a local optimization that adversely affects Team Flow.

15

Of course, we’re talking about the delivery of software systems. How do Traffic Management, Queuing Theory and Personal Flow fit into that context?

16

So what is Flow in software development?

It represents the delivery of something valuable to stakeholders for your system or product. Something for which they are willing to give you money to create.

17

Let’s examine Flow in some existing processes.

Here’s a Flow. Does it look familiar? It’s from Dr. Winston Royce’s 1970 paper that essentially defined the Waterfall Process. Cool! Water flows, right?! Remember, quite often there are rocks at the bottom of a waterfall!

Let’s clear the air - Waterfall works. So much software has been delivered that way, it simply can’t be denied. What you can say is that Waterfall only works to an extent, and to be able to effectively work within a Waterfall process you must implement practices and policies that inhibit flow.

Each phase had to be completed before the next could start, requiring handoffs. Different people with different specializations worked on different phases creating silos of knowledge. Work was performed to a schedule that was resistant to changing business priorities.

18

It was those inhibiting practices, those disruptions of flow, that led to the lightweight development processes that fall under the umbrella of Agile.

At the core of each of the various methods, the common root of all Agile, is the goal of maximum flow.

Even now in 2010, Agile methods are continuing to evolve around maximizing flow. Kanban is an example of a process that avoids the traditional Agile iteration ceremonies, and works in a continuous planning and delivery mode. The conventional wisdom in Scrum a decade ago was that 1 month Sprints were good. Today, that seems like an awfully long time to go without feedback.

So, what do we do that maximizes flow?

19

Teams have a finite capacity for the amount of work they can be doing at any one time. My experience says that software delivery teams that don’t currently have a way of determining how much work they can do in a given time period are overly optimistic about their capacity. I don’t just mean software developers, but all people involved. Put simply, when you don’t know your real capacity, you will try to do too much.

You also need to build some flexibility into your determination of capacity. After all, a communications network at 100% capacity is at a failure point. Our brains are communications networks, and they suffer from the same problem. A good target is about 75 to 80% - this concept is known as Slack.

20

The only way to determine capacity is to break work items into small enough “chunks” that don’t take very long to complete but still deliver useful business value and have a known & measurable Done State. If you don’t know when you’re done, how can you maintain flow? How many have heard the term “Feature Complete” with software? That usually means that the really hard work is about to start, right?

Done MUST mean that the developers have completed their work and testing, the QA people have completed their work, and the business people have accepted the work as complete and suitable to the business task.

21

This is really simple. Don’t start anything until you have finished what you were working on. This applies at the task, story and even the project level.

• As a developer, do not select more than one task at a time.• As a team, work on one story until it reaches its Done State, then select the next.• As a manager, do not “schedule” projects in the portfolio – start new projects once current ones have completed.

It’s really that simple. Really.

22

This is a little known practice that maximizes the probability that people will achieve a state of personal Flow. It allows them to focus and to maximize their productivity during the period defined as Core Hours.

Team members work on their project only from, for example, 9 am to 3 pm. Yes, that's only 5 hours... it's also realistically how much people work in terms of actual time when you account for administrative tasks, dealing with family matters, working outside their main project, and so forth. We already know that multitasking is a fool's errand,so why not allow people to focus for a set period of time in order to maximize their productivity?

Adhering to core hours takes a little discipline initially. There is often pressure from "increase the hours a little," but again this is a reflection of the reality of all the work that people actually do during the day. Management also has a role in making it acceptable for team members to say, "I can look at that in a couple of hours" when an issue presents itself and is not critical. While the business may not initially like the change from an immediate response, the rewards for doing so are enormous.

23

Another way to maximize flow in the long term is to ensure that manual testing doesn't become a constraint. It's very rare to see teams have as many dedicated testers as there are developers*, and even then developers are typically able to churn out code (even with automated unit tests) faster than QA people can manually test it. This results in two possible scenarios:

1 - The whole team must slow down to accommodate the manual testing in order to get work to its done state.2 - The done state becomes more fluid (i.e., the testing effort suffers), and the number of defects found later in the iteration/sprint/cycle in which the work is performed starts to rise, i.e. Technical Debt increases.

Either way, the team's ability to deliver value begins to suffer.

* Although this is quite common in the hardware development domain.

24

While Pair Programming may be the single most controversial practice from Extreme Programming, it’s also one of the best for moderating individual and team-level flow. It helps to avoid the rat-holes that a single developer can find himself in when working alone, and it also promotes both people in the pair focusing on the work at hand.

There’s also a dirty little secret about Pair Programming that actually helps to increase Flow... It creates peer pressure. If you have someone working by your side, you aren’t going to be tempted to go check the news, poke around on Twitter or fire off an e-mail. You’re also going to be much more likely to work test-first, and even more likely to write tests in the first place. Many people have said that Agile requires considerable discipline on the part of the development team members, and pairing helps reinforce that discipline. In turn, there is better team-level flow.

When people pair well together, they can also achieve Csikszentmihalyi Flow. Theircollaboration becomes very fluid, almost as a single mind. However, that “single mind” of the pair can hold more context about their current work than either one of the partners alone. This also allows them to remain more focused on more work, and thus improving their flow.

25

The Project Community is comprised of everyone who has a hand in the delivery of a project. The golden rule of the project community is that it's always larger than you think. For example:

The Facilities group may need to be consulted in order to provide a common workspace for the team so as to maximize communication among all team members. Do you have all of the people you need for the project? If not, HR may need to be involved. Most organizations have a separate group that manages the production environment into which your system will need to be deployed; sometimes this group also manages the QA environment for testing.

Without their involvement, flow can be disrupted when these groups suddenly receive a panic request that must be addressed immediately!

26

So, what have we learned that will feed out Flow Junkie craving?

Limit WIP – determine your actual capacity and stick to it.Know your Done State – you can’t know your capacity unless you know when you’re done!Pull-based Work – work on one thing to completion, then pull the next available piece of work.Core Hours – allow yourself and others to achieve a state of personal Flow to maximize productivity.Automated Testing – grease the Agile wheel! Ensure that manual testing doesn’t become a bottleneck.Pair Programming – two heads really are better than one, and will result in better team-level flow.Project Community – engage everyone who will be involved, even if only peripherally, in the delivery of a project or product in order to avoid disruptions in flow.

27

My name is Dave. I’m addicted to Flow.

28