Manage flow, not people!

Flow is King. Agility is a side-effect.

Flow is King! Succinctly put, Flow is the movement and delivery of customer value through a process. Without Flow, our organisations simply cannot endure long enough to deliver value to our customers. I will relate from my own experiences of how to see Flow in your organisation, as well as tips and tricks to identify and eliminate impediments to Flow.

I have worked as an Agile Coach for over 15 years now. More and more, I am seeing organisations that want to install The Agile! The promise is that we will get greater visibility, more delivery, better quality, delighted customers and happier more engaged employees. Sounds great! Sign me up!

The recipe for “installing The Agile” usually looks something like this:

1. Agile training for everyone — it’s important that people understand the principles and practices.
2. Reconfigure the workforce into small cross-functional teams — a cross-functional team doesn’t depend on others?
3. Each team works from a backlog of work items or stories, and tracks their velocity in story points; competing for the accolade of highest score!
4. The backlog of work-items is prioritised by a business person, who is often too busy with “business stuff” to spend any quality time explaining the “why?” with the team. I’ve been that person. I feel the pain!
5. Coach the teams to become more effective through the use of stand-up meetings and retrospectives — short learning cycles.
6. Sum the velocities of all the teams and we get the organisation’s velocity! A measure of productivity!
7. Continue coaching teams to increase productivity!

Is this good stuff to do? Maybe. Does this mean we are Agile? Sadly… not really. The upside typically results in small pockets of improvement around the organisation, but seldom if ever delivers on the promise of Agile. In fact, there are almost always undesired side-effects of change in this fashion e.g. losing experienced knowledge workers who don’t want to be “changed”, or disgruntled project managers.

If we view our organisation as a bunch of teams that deliver stuff, then we might be missing the bigger picture. Dr. Russell Ackoff coined the phrase,

“A system is never the sum of its parts. It is the product of the interactions of its parts.”

Ackoff suggests that there might be a bigger “ system of delivery” than the teams themselves. Ever heard of the “D” word? No, not “done”, although that is important. “Dependencies”. While we may have many teams effectively delivering pieces of value, it is near-impossible to have more than a few teams in an organisation without the existence of cross-team dependencies. Another word for dependencies is “waiting”.

Work items that are waiting usually require some kind of extra-team interaction in order to get unstuck. Meetings! Since we don’t trust that the teams will initiate these interactions, we employ Project Managers who try to ensure that the right teams are talking to the right teams at the right times. In large matrix organisations there is usually a many-to-many relationship between Project Managers and Teams which in turn results in teams receiving conflicting priorities a.k.a. “Everything is urgent!”

We know from Lean Thinking that “waiting” is one of the 7–8 deadly wastes. Waste, being something we do that contributes nothing towards delivering value to the customer. Perhaps, if we truly keep the customer in mind, we need to focus on more than just the delivery teams if we want to minimise the real wastes that exist in our organisations.

What is Flow?

One of the six practices of Kanban, suggests simply that we “ manage flow”. Sounds OK, but what does it mean? In Dan Vacanti’s book Actionable Agile Metrics, he suggests that:

flow is the movement and delivery of customer value through a process.

Think of a request that comes in, a new feature for development or a customer enquiry. If this was the only request the organisation had, it would probably flow quickly from team to team, person to person, activity to activity. It wouldn’t sit waiting, because people would be waiting, ready to contribute to getting the feature built, or the customer request fulfilled.

Notice the distinction above! Workers are waiting. The work is flowing. This is utopia for the customer, but often not for the organisation. Idle resources (idle “people” in my book) = waste. As we add more concurrent requests into the organisational system, the amount of time that workers are waiting to do something, decreases.

Good! Busy workers = higher ROI, right? Not necessarily. If we keep adding more work, we eventually optimise for 100% busy workers. A side-effect of this is that work queues start forming in front of teams and individuals (the proverbial in-tray). The work requests sit idle in these queues, and evidently take longer to deliver. So the corollary of the above statement is true, “ Workers are busy. Work is waiting.” — a somewhat counter-intuitive reality.

Waiting Work is the opposite of Flowing Work. The time that it now takes for value to reach the customer is increasing. I have seen organisations where time from request until time delivered is in excess of 700 days! Is delivery of items in this scenario even important anymore? But the teams are Agile! I don’t know about you, but this doesn’t feel very Agile to me, and it makes me sad.

Queued Work is Waste

We have agile teams, so why bother about queues? We have backlogs!

Backlogs are good — as long as they are small. The smaller the better! And, backlogs are not the only queues in organisations. The backlogs I see in organisations usually represent the work in front of a single team or at best, a number of teams working on a product. But where do backlogs come from?

Usually there are queues of big hairy ideas (BHI’s) like projects or initiatives that are forming ahead of the team/product backlogs. These are often invisible to teams busy with execution. Deciding which of these large items to start next can be a difficult task — remember I spoke of the business person who was too busy to spend quality time with the delivery team? Each BHI often has a senior stakeholder behind it, who carries weight and influence in the organisation i.e. all BHI’s become important.

So we start many of BHI’s at once. The more we start, the longer it takes for any of them to finish. But we continue to add more. Middle management, teams and individuals are 100% busy, but delivery is crawling! Queues are forming in-front of individuals, teams, projects, strategic initiatives. At all levels of the organisation. Longer queues mean less Flow. Everything is taking longer and longer to deliver. So…

Make the teams work Smarter! Faster! Better!

People need to take ownership!

We don’t have capacity! We need to hire more people!

The sooner we start, the sooner we finish!

If we follow these mantras instead of solving the real problem, we end up spending a lot of money and amplifying the pain, while decreasing job satisfaction and employee engagement. Or we move the pain to another area of the business. Typically, these attitudes towards improving delivery are far from sustainable in practice. I think you’ll find reference to sustainability in the principles of the Agile Manifesto. ;)

How am I contributing to the DOF — Death of Flow?

In your work do you, or have been asked to:

• regularly fast-track new items over completing planned work?
• spend time waiting for someone outside your team or organisation to unblock what you are working on? and then,
• start new work to keep yourself busy while you wait?
• work harder and get more done — burn the midnight oil?
• hire more specialists?
• structure the workforce into knowledge / skill silos?
• focus on the new features, and leave defects until later?
• transfer a call to another department (assuming you’re not the receptionist)
• code-freeze, stabilise and release once per year?

While at times we need to do these things, deciding to do any of them regularly will lead to snowballing queues of idle work items and a conspiracy to create longer wait-times for all work items — the death of flow.

So how do I manage Flow?

Consider the statement:

Starting work costs money. Finishing work makes money.

It would seem that the more work we start, without finishing, the more money and time will be held up. The more work that we are finishing, the more money is coming in.

1. Decide the level in the organisation where you are trying to improve Flow i.e. strategic, portfolio, programme, product, team, individual. The higher up in the organisation, the bigger the impact of the change. i.e. focusing with individuals or teams, has the lowest impact on the organisational Flow. Klaus Leopold, the author of rethinking AGILE and founder of the Flight Levels Academy, has a model to help you to identify the kinds of problems to solve at different levels of the organisation. The model is aptly named Flight Levels.
2. Visualise the work in flight at this level — Sitting with other people in the delivery system to co-create a workflow visualisation is an essential step to seeing where the problems are. Too often we rely on fancy tools, configured by someone clever, which serve a purpose, but are typically great at hiding problems.
3. Using the visualisation, identify the large queues, and flush them out — this will mean starting less work initially and will lead to more even flow (ageing of items) and therefore higher levels of predictability.
4. Measure the age of work items — we want to at least see if the average age of items in the work flow is decreasing over time, otherwise we haven’t fixed anything! Where specific work items are getting too old, catalyse conversations about how to finish them.
5. Measure the duration that work items spend waiting — If we want to increase flow, we need to decrease wait times (of the Work, not the people).
6. Stop starting, and start finishing! — pay more attention to finishing work that starting it.

Optimise your organisation to keep people busy if you want to get busy people. How about optimising for delivering value to customers instead?

Want more?

If you want to know more, feel free to

• Join Mike Freislich & Rochelle Roos on the upcoming Flight Levels And Kanban courses
• Join the WDC Collab group to contact the author and learn from others.
• Ask questions, and I’ll write some more! :)

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.