paint-brush
Know Your Flowby@jonathansmart1
1,501 reads
1,501 reads

Know Your Flow

by Jonathan SmartSeptember 16th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Picture this. A gaggle of CIOs from various industries meeting to discuss digital transformation and business agility. About 20 in the room. I ask <strong><em>“how many of you know a flow metric for your organisation?”</em></strong>. Any data point of any flow measure would have done. Lead time, cycle time, throughput, release cadence, averages, percentiles, median, a flow efficiency measure, percentage of strategic products in their organisation with the 80th percentile Lead Time consistently less than 4 weeks for the past rolling 6 months, a vector metric trend of any of the above,&nbsp;etc.

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Know Your Flow
Jonathan Smart HackerNoon profile picture

Picture this. A gaggle of CIOs from various industries meeting to discuss digital transformation and business agility. About 20 in the room. I ask “how many of you know a flow metric for your organisation?”. Any data point of any flow measure would have done. Lead time, cycle time, throughput, release cadence, averages, percentiles, median, a flow efficiency measure, percentage of strategic products in their organisation with the 80th percentile Lead Time consistently less than 4 weeks for the past rolling 6 months, a vector metric trend of any of the above, etc.

How many CIOs out of 20 do you think knew at least one data point on Flow for any part of the organisation that they are the technology lead for?

Not one CIO knew even one flow metric for their organisation

This is irresponsible.

I am sure that each CIO will know What, When and How Much. Or think they know. What the high priority items in the book of work are, a set of milestones for them and how much they are going to cost. And I’m sure that the majority in the room would view these as knowable and predictable up front. ‘Project Greenfield Silver Bullet, go live date 2nd April next year. The success of business line X depends on it’.

But, not one of them knew How. How efficiently, how effectively, how quickly they can learn, how quickly feedback can be generated, how quickly hypotheses can be tested, how quickly customer’s needs can be met, how quickly value can be monetised, how quickly teams can stop, pivot, go again, how quickly customer feedback can be acted on, how manual activity has been supplemented with automation removing waste and manual error, how value can be maximised by cutting the tail on low value add features.

Not one could see if a frequent release cadence is facade of agility, due to long lead times and multiple release streams of work running concurrently with a high cost of context switching (for example, monthly releases with 6 streams running concurrently, each with a 6 month lead time, each staggered by one month). From the perspective of the recipient of the change, the lead time is not agile, it’s 6 months from the point of commitment (never mind how long it’s been in the wishlist for).

Or the movement over time. How better or worse their areas are at How they do What they do. A vector metric, showing a trend. How well a process of constant improvement is removing constraints in the system of work, how limiting work in process is reducing lead time and increasing throughput of the most valuable features.

Not one was able to correlate an improvement action to a flow metric. Or conversely to see the impact of a cost cutting initiative, the increase in hidden costs, slowing time to market, increasing lead time, slowing responsiveness, reducing throughput.

Focus on Flow, Quality and Happiness

Focus on Flow and everything else tends to fall into place. That is, sustainable Flow by addressing the system of work, not unsustainable flow by working people harder, at the expense quality or happiness.

‘A bad system beats a good person every time’, W. Edwards Deming

Costs tend to drop away, as impediments, inefficiencies, constraints in the system need to be resolved to achieve flow. Bureaucratic processes need to be made lean. Quality tends to rise, as repetitive tasks are automated, as quality shifts left and as the change deltas become smaller, it’s complexity that can fit in your head. To enable flow, blue-green deployments are implemented. There are more independently deployable components with bounded contexts. The blast radius is smaller.

Sustainable Flow with high Quality, engaged Colleagues and delighted Customers

The goal is to sustainably reduce lead times, increase quality and increase colleague & customer happiness (measured via surveys and Net Promoter Scores). These should be measured as trends, as everyone’s context and starting point is unique. And made visible to as many people as possible, especially senior leaders in the organisation. It leads to the right questions being asked.

A focus on a positive trend, then also tends to lead to a Kaizen process of constant improvement. Inspect and adapt. What level do we pull now to improve, is there a broader organisational impediment which we can shine a light on with data.

A great thing about Flow metrics such as end to end Lead Time, a Cycle Time per step in the process, Throughput, Release Cadence and Flow Efficiency (time work is worked on / elapsed time) is that they are aggregatable, they are distributions, can be averaged, percentiles can be calculated and vector metrics calculated. And it is hard, empirical data, which is difficult for leaders with their heads in the sand to argue against. It shines a light on the reality.

Note that I don’t include story point based velocity in the category of Flow metrics, as it is meaningless outside of the team and even then is of questionable value over story counting, where all stories are approximately the same size and will have regression towards to the mean.

Anything can be done badly. Flow done badly is unsustainable, it’s working people harder, it’s not quality-first, it’s not limiting work in process, it’s asking teams to increase flow without fixing the broader system of work. This was evidenced in the 2017 State of DevOps Report showing that lower performers had increased release cadence and reduced lead time from the 2016 survey, however had slower recovery times and higher failure rates than the higher performers.

Empower Teams and Leaders to Continuously Improve

In addition to shining a light on the Flow, Quality and Happiness and the trends of them over time, and ensuring that this data is transparent and visible, teams and leaders should be empowered and expected to have a Kaizen process of constant improvement. Progress is evidenced via the Flow, Quality and Happiness vector metrics.

Empowered & expected to dig into the data, to visualise the work in the system at many levels, to run experiments, to pull one lever (for example, CI, TDD, co-located feature teams, a less bureaucratic portfolio management process, less WIP) and to see the impact on Flow.

Empowered & expected to run Observe, Orient, Decide, Act (OODA) loops and Improvement Katas.

‘Valuetivity’

There is one more measure which is critical which is Value.

A team or a department or a business can have great Flow, Quality and Happiness, within their constraints of budget and location, but they are doing a great job of producing something which is of little value.

Productivity is defined as “the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input”

But, we don’t just want output being churned out. Sometimes we want to reduce productivity in order to innovate, to do a gemba walk, to sit and talk with customers, to learn, to reflect.

We want ‘Valuetivity’. We want to maximise the value curve, most value first, then cut the tail. This will be a topic for a future post.

In summary, make sure you Know Your Flow.

Flow. Quality. Happiness. Value.

See also: Agile Manifesto Values add on for large enterprises