Flow


There are several assumptions that are part of the conversation about neglected WIP. I have had a lot of training in math and quantitative methods which means I recognize that assumptions are important. Four of the critical assumptions are:

(more…)

One of the most common problems teams face is starting more work than they complete. The reasons this occurs are both myriad and legendary. The impacts of teams starting more work than they complete, range from quality problems to increased support costs. Maybe the most critical outcome is lost trust. All these problems stem from letting work sit around once started while you do something else. No one can work on two items at the same time. You have to put one down, change your mental model and then work on something else. Neglected WIP is the gap between all the work you say you are working on and the stuff you are actually doing. While all neglected WIP is a problem, all teams have a few items on hold. TaskTop, the company Mik Kersten author of Project to Product founded, suggests that up to 25% neglected WIP might be acceptable. While I feel that is a high hurdle, the natural vagaries of office life can cause an item to get stuck due to someone being out sick or because your co-worker hit the lottery – stuff happens. When neglected WIP passes that hurdle, real flow time will increase and velocity will slow. The combination of getting less work done and taking longer at it is a prescription for your stakeholders to start looking for torches and pitchforks.   

(more…)
Play Now!

One of the most common problems teams face is starting more work than they complete. Neglected WIP is the gap between all the work you say you are working on and the stuff you are doing. The natural vagaries of office life can cause an item to get stuck due to someone being out sick or because your co-worker hit the lottery – stuff happens. A little might be ok, but more is bad. When neglected WIP passes that hurdle, real flow time will increase and velocity will slow. The combination of getting less work done and taking longer at it is a prescription for your stakeholders to start looking for torches and pitchforks.   

We also have a visit from Jeremy Berriault who brings his QA Corner to the podcast. In this installment, we discussed the QA Lead’s role in agile teams. So just what does a QA Lead do in an agile team . . . Jeremy has some ideas.

(more…)
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.

(more…)
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).

(more…)
SPaMCAST Logo

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. 

(more…)

Continuous improvement through inspecting and adapting is a core tenant of an agile mindset, which dovetails well with every executive’s need to deliver the most value possible.  Measurement is an important tool to help teams and organizations ask the right questions at the right time. Flow metrics, not burndowns and velocity, need to be a big part of any IT organization’s approach to measurement. 

We also have a visit from Jon M Quigley who brings his Alpha and Omega of Product Development column to the podcast.  Jon discusses the complicated relationship between time, work entry, and promises. 

(more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 434 features our essay on Change Implementations – To Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams.   (more…)

Image

Subways are great things!  I am not sure I understand how large cities operate without some sort of train system.  However, a subway is not a great metaphor for process improvement projects (or any other kind of project).  Trains barrel into each station, slam on the brakes and then whisk themselves back out.  If the your goal is to get off at a specific station then the starting and stopping at each station is important. Just try getting off or on in between stations.  If your goal is to get to the end of the line (the end of the project) then starting and stopping is less than optimal.

Also if you are reading a book on your electronic device the start and stopping can lead to getting off at the wrong station . . . again.