The day the Obama’s were at the white house for the unveiling of their portraits, I was four blocks away attending the Prodacity conference. The conference was awesome due to many amazing speakers and a single track focus. First time on an airplane in more than three years, and first time speaking on stage at a live event, filled me with both overwhelm and relief. It felt like I needed to learn how to speak again in person and I was relieved to talk with attendees after the talk.

Over the last ten years, I’ve worked with lots of large organizations to help them roll out flow metrics. And because flow metrics tend to change the way organizations look at and measure value, my work is consumed with advising managers and directors on how to effect change. It hasn’t been easy as people are resistant to change and managers are rarely set up to enable change successfully. This is a really important topic and what I chose to speak about at Prodacity.

Introduction

The uniform code of military justice specifies court martial for any officer who sends a soldier into battle without a weapon. There ought to be a similar protection for technology coaches, managers and directors, because they shouldn’t be made responsible for an initiative or transformation without being setup to effect change. That’s because change is inevitable and it’s good if it’s headed in the right direction. Quickly, as time is of the essence.

No company or organization can operate the same way forever. We all need to change at some point. How well your organization can change will be determined largely by three things:

1. Your ability to make work visible – so people can see how and what work delivers value.
2. Your ability to measure what matters – so people can understand the impacts based on data.
3. Your ability to build a coalition of the willing – so there’s a large enough group of people who actually want to change. Transforming organizations is not a one person job – no matter how competent they are.

Here are a few ideas for how to make work visible and measure what matters so your ideas can be valued and accepted – which can help you build a coalition of the willing.

Make Work Visible

Making work visible is one of the most fundamental things you can do to improve workflow. That’s because the human brain is designed to find meaningful patterns & structures in what is perceived through vision. Most people process information based on vision. For visual learners, if the right hemisphere is not activated and engaged, then attention will be poor.  It’s why meetings are more compelling for two thirds of your team when there’s something interesting to look at.

I like to start making work visible by looking at demand (at work item types). Because it answers the question, “What kind of work do you do?“. And because it drives conversations on prioritization, such as, “Should we prioritize features or security this quarter?“

In 2018 Mik Kersten prescribed four work item types to use in software delivery: Features, Defects, Risks, and Debt. These are used by many companies measuring flow. The benefit of categorizing work this way is that it allows for rapid understanding of demand (work type demand) with a single glance. It’s also an easy way to allocate capacity and see ratio per work item type.

55% of completed work items over this 30 day interval is defects. Talk about provoking a necessary conversion! Is this what we thought it to be? What’s our strategy? What should it be?

Looking at your flow distribution at the end of each month to compare what you had wanted it to be is a useful exercise. If you have existing review sessions such as Ops review, I recommend using some of that time to look at flow distribution – so you don’t have to add another meeting to your calendars.

If ended up being 80% features and 20% defects, then we know that the strategy didn’t match the way work was prioritized – and there lies an opportunity to discuss tradeoffs. Flow distributions is really a measure of tradeoffs. If 100% of the work completed was features and defects, then there’s no capacity for security or tech debt. If you continue to do more feature work, you can’t expect it won’t take away from doing risk or debt work. Business and technology leadership need to understand these tradeoffs.

Measure what Matters

WIP is a great metric to look at first. Why? Because it’s hard to effect change with people who are cognitively overloaded.

I’m currently working with an operations team with an average WIP of nine per person. I asked them how they juggle nine things at a time? Turns out they don’t really – they set work aside to work on other things and 40% of their WIP sits idle.

50% of their work is unplanned. Because unplanned work delays planned work, it’s a real problem for them. Measuring their WIP (Flow Load) to see how much work sits idle prompted conversations on “Start finishing and Stop starting” and why pulling new things into progress before finishing old work delays Flow Time.

Flow Time: The elapsed time to complete a request from the time work begins to the time the request is available for the customer.

There is a relationship between flow Load, flow time, and throughput – it’s called Little’s Law.

The gist of Little’s Law is that – on average – the more items that are worked on during the same time interval, the longer it will take to finish those items – on average. Changing any one of these flow metrics can impact the others.

This infrastructure team delivers 24 things per week (approx. 1 per day) and each thing took 36 days to complete (on avg). Given Little’s Law equation above, solve for “Avg WIP” to see what the WIP should be based on Little’s Law. Remember to use the same units of measurement (days).

Note that Little’s Law is based on assumptions such as, the arrival rate should equal departure rate, all work started will be completed, the average age of the WIP is neither increasing nor decreasing. Think of Little’s Law as a tool to help guide you toward a better WIP limit – which won’t be precise – because -assumptions.

In Summary

Most companies our team works with at Tasktop (now Planview) struggle to perform like high-performing digital natives. When we examine Flow time in the end-to-end process of turning a business need into a business outcome, it’s a very long process – 6, 9, 12 months if not longer.

We call this water-scrum-fall, where development teams typically have relatively fast flow, but the overall time-to-market washes out that success. The time spent on actual development is often between 2-12% of the total time-to-market. More than half the time is spent in heavy planning & funding processes. And beyond a few instances where DevOps has worked, for most applications, releases are slowed down by cross-product dependencies, brittle legacy systems and high ceremony processes.

Adding more people or resources is not always the solution – especially when people are already overloaded. Getting new people up to speed make take months. The key is to make priorities visible, reduce WIP, and equip leaders to successfully effect change using metrics that matter. From there, the work will show you what to do.