Flow is one of the most used words in agile and lean (and there are a lot of overused words in the field). Even though the word is used by nearly every practitioner multiple times a day there are very few solid definitions. Instead of definitions, most practitioners have a notional understanding of what the word means in software and software-related disciplines but often revert to metaphors when challenged. If I had a dollar for every reference to a river or traffic I would be able to outbid Elon Musk for Twitter. The term is used as a noun, verb, and adjective (I am sure someone has an example of flow used as an adverb but I have to hear it yet).
The OxfordLanguage website provides several definitions of the term flow used as a noun and verb. Definitions of note include:
Verb: move along or out steadily and continuously in a current or stream
Noun: a steady, continuous stream of something.
WordType.org supplies a definition of flow as an adjective (and suggests it can’t be an adverb).
Adjective: moving, proceeding, or shaped smoothly, gracefully, or continuously.
A few recent real life (ish – a word changed here and there to protect the innocent) examples of how people used the term flow:
Verb: Goals flow from the executives to middle management who craft initiatives.
Noun: We are responsible for the flow of problem tickets from the call center.
Adjective: Flow efficiency is a great metric that is really hard to measure for software teams.
There are many more, some that are far less apparent whether they fit any formal definition.
Why is this important? Teams are a central component of all software-centric organizations. Work moves through teams, across teams, and between teams to finally get to a point where it is done or canceled. Understanding both the steps that a stream of work follows and the pace of the stream is important. The structure of a team has a huge impact on how work progresses from the backlog to production. While doing research for an essay on team structure, I went searching for a published definition for the word flow in a software context. I reviewed a number of Kanban and measurement texts by authors including Steve Tendon, David Anderson, Jim Benson, Mike Burrows, Skelton and Pais, Capers Jones, and Tom Gilb. I found far less than I expected – FYI if you are writing textbooks, for God’s sake invest in indexing the book. In my research, I found two different versions of flow. The first was personal flow from the book Flow by Mihaly Csikszentmihalyi. This form of flow, also known as being in the zone, is defined as:
“The mental state in which a person performing some activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by the complete absorption in what one does, and a resulting transformation in one’s sense of time.[1][2]”
Important but not what I was looking for. The second, and more to the point for technical teams, came from Mik Kirsten’s Project to Product:
‘Software Flow: The activities involved in producing business value along a software value stream.’
Subsequent to the publication of the original version of this essay, Johanna Rothman pointed out that Daniel Vacanti defined flow in Actionable Agile Metrics for Predictability. Quoting Mr. Vacanti
“Simply stated, flow is the movement and delivery of customer value through a process.”
(Actionable Agile was featured as part of the Re-read Saturday feature. Great book but not indexed and I only have the print edition). Ms. Rothman thinks this is a great definition and I agree as it covers both the activities and movement of value. Given we have a definition, we can turn our spotlight on the attributes used to describe flow in the next installment.
