Play Now

Definitions provide several benefits. The first is that once a definition for an object or concept is agreed upon, it is far easier to have a discussion without getting confused. A second and equally important benefit is that definitions provide a platform for establishing attributes that can be used to describe the object or idea. Attributes are critical because even with a definition we need to communicate and measure nuances. Just think if you only had one word to describe rain or hot; a lot would be lost. Today we identify four basic attributes of flow. 

We will also have a visit from Tony Timbol who brings his “To Tell A Story” column to the podcast. In this installment, Tony and I talk about agile requirements. They really exist…really!

Focus On Flow

Definitions provide several benefits. The first is that once a definition for an object or concept is agreed upon, it is far easier to have a discussion without getting confused. A second and equally important benefit is that definitions provide a platform for establishing attributes that can be used to describe the object or idea. For example, if we were describing a flow of water, we could use direction, speed, and volume to describe and measure the flow. If we use Daniel Vacanti’s definition of the flow of software development and maintenance, “the movement and delivery of customer value through a process,” we can identify a common set of attributes that can be used to describe flow. Attributes are critical because even with a definition we need to communicate and measure nuances. Just think if you only had one word to describe rain or hot;, a lot would be lost.

Perpetuating the Metaphor

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


In the SPaMCAST 705 we stay with the basics and define the term flow. I recently listened to a conversation where the term flow was used 30ish times in 30 minutes. Each use of the term meant something different. Today we draw a line in the sand to improve communication. 

We also have a visit from Jeremy Berriault from the QA Corner.  Jeremy and I discussed the mistaken belief that Scrum Master and Coach can be translated to administrative assistant. 


When I started writing this blog entry I tried to remember all of the books that we have re-read (or read for the first time) on a weekly basis.  I couldn’t remember.  When I look at the statistics for the Re-read Saturday entries they are almost always in the top ten, month after month so it doesn’t matter whether I remember each of the entries (I added a task to my backlog to find them all) because you find and read them.  Two weeks ago I went on holiday, backpacking on Isle Royale. It was a total unplug. During that time I ran a poll to select the next two books to re-read.  The answer is: 


A New Copy!

Today we tackle Chapter 3 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 3 is titled Introduction to Little’s Law.  Little’s Law is incredibly clever and potentially life-changing if you are overly fixated on size.  Buy your copy today and read along!

We originally wrote about Little’s law in September 2014. Little’s Law brings WIP, Cycle time and Throughput (metrics discussed in chapter 2) into a relationship that can help deliver information that can be used to answer the basic questions of predictively. The basic configuration of Little’s law is stated as: (more…)


A New Copy!

Today, Chapter 1 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 1 is titled Flow, Flow Metrics, and Predictability.  Vacanti jumps directly into the deep end by suggesting a way to answer the age-old question, ”when are you going to deliver?”  Buy your copy today and read along! (more…)

Listen Now

Subscribe on iTunes

One last week in mixtape format! I am completing a trip that is a mixture of vacation and a board meeting but that does not mean you have to forego your weekly SPaMCAST.  In place of our normal format I am posting a mix tape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.  This week on SPaMCAST 393 we feature our top downloaded podcasts from the year 2010:

SPaMCAST 85 – Cory Foy on Agile Coaching

Cory used his wishes to discuss the obsession with certification rather than performance and bring user into making critical business decisions so that usability is maximized.

SPaMCAST 92 – Don Reinertsen on Product Development Flow

Don used his wishes to ask that people understand the economics of product development and then to use that understanding to measure and reduce WIP queues.

SPaMCAST 94 – Ivar Jacobson on SEMAT

Ivar discussed the SEMAT core defining software engineering and how SPaMCAST listeners can support the development of SEMAT.

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week we will return to regular programming with a thought provoking interview.

Functionality should flow like a river.

Functionality should flow like a river.

Kanban, which means signal card in Japanese, has been a staple of lean auto manufacturing for years through its application in the Toyota Production System (and in lean manufacturing environments).  Typical IT processes work by pushing work through steps, with work piling up at bottlenecks. Units of work stuck at bottlenecks are not gathering feedback as quickly as possible, which increases the likelihood that, when a defect is found, it will affect many pieces of work rather than a few. Kanban works by pulling work though the development process, also known as a value chain, so that work-in-process (WIP) is minimized. Kanban is a simple concept, but its application tends to challenge many of our previously held notions of how IT organizations should work.  Kanban fosters the delivery of a flow of individually prioritized work items rather than the delivery of large blocks of functionality all completing at once.  In a Kanban environment the delivered work items are generally grouped into periodic releases, which doesn’t fit the common definition of an IT project.

Alan Shalloway, of Net Objectives, recently suggested that Kanban has evolved into three streams of thought.  They are:

  1. Kanban Method (a branded method championed by David J Anderson)
  2. Kanban as a thought process to be applied with other Agile and Lean processes (championed by Alan Shalloway, Karl Scotland and others)
  3. Kanban as a method to manage workflow (championed by Corey Ladas)

These are all variations on a theme. Merging the core practices from each of these variations yields a broader set core practices for Kanban.  These core practices extend the usefulness of Kanban to most, if not all, IT delivery processes:

  • Work must be visualized. Kanban is nothing if it not a visualization of a work or value flow. The more public the visualization, the better. Visualization helps the team and stakeholders guide the work so that it provides the most value. Visualization also helps control work entry and interruptions.
  • The goal is to manage work so that it continually flows.
  • Each step in the workflow will have a limit to the amount of work that can be in progress (WIP) at any given time. WIP limits reduce multitasking, switching and “inventory.” WIP also reduces waste and increases flow.  The WIP in process limit should not be systematically violated.
  • All policies that guide work (definition of done, work-in-progress limits, work entry process, how work is approved and others) must be explicitly stated.  Explicit rules facilitate discussion and refinement which leads to greater flow and efficiency.
  • Implement feedback loops to ensure transparency and help regulate the process. For example, the team needs to know when work has to wait, so they can either swarm to the bottleneck, regulate work in preceding steps or to refine the process.
  • Kanban provides the information to improve as a team and evolve using models and the scientific method.  Begin slowly by implementing Kanban without process changes until data is gathered.

Below is a basic implementation of a Kanban board based on the core practices:

Kanban helps to visualize the flow of work.

Kanban helps to visualize the flow of work.

In Kanban work is pulled to the next step only when there is capacity for the work in that step to begin. When the work unit is pulled into the next step it will reduce the amount of work the sending step below its work-in-progress limit, allowing it accept another unit of work.  For example, if the analysis step had a work-in-progress limit of 4 units of work and 1 unit was pulled into development, 1 unit could then be pulled into analysis from the backlog. All work items that are in progress should be being worked on at all times rather than waiting in-between steps. When work sits it is considered work-in-progress or inventory (or waste, to use a lean term). Continuously measure the flow of work through each step until it is done. Challenge the team to maximize the flow through the process.  Updating the process to minimize wait states and WIP leads to evolutionary change.

Kanban represents is a significant paradigm shift in how IT works today. It is a shift from a push to a pull method. Using a pull method puts the focus on the improving the flow of work though the development process. Ultimately, it improves efficiency and delivery of business value.

Savannah River

The majesty of a large river can sometimes overwhelm the underlying message of flow.  When under control the continuous flow of water past any point is a metaphor for the flow of work through a process.  The flow of work is like that of the river continuously delivering value.

Constraints that impeded the continuous can introduce significant problems requiring rework  or scrap.  Just ask folks in Southern Louisiana about where the Mississippi really wants to go and the benefits and problems that redirecting the Mississippi has caused.  Engineer processes in a manner that provides as continuous a flow of value as possible!