(Slides and Notes from Agile 2010) Vehicular traffic, grocery store lines, and even making dinner in your kitchen all need require Flow in order to work effectively. In software projects Flow is equally important and the same dire consequences result when disruption occurs. The fact is that Flow is a core concept behind all Agile approaches, and needs to be maximized at several levels.

1. Confessions of a Flow Junkie
1

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

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

9. Who else here is addicted to... er, likes Flow?
Tell me a quick story about your experience with Flow.
9

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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. Their
collaboration 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

26. 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

27. 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

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