I have worked as an Agile Coach for over 15 years now. More and more, I am seeing organizations 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 prioritized 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 organization’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 organization, 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 organization 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 organization 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 organizations, 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 minimize the real wastes that exist in our organizations.

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 inquiry. If this was the only request the organization 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 organization. Idle resources (idle “people” in my book) = waste. As we add more concurrent requests into the organizational 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 optimize 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 organizations 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 organizations. The backlogs I see in organizations 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 organization 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 organization. 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 organization 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, stabilize 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 organization where you are trying to improve Flow i.e. strategic, portfolio, program, product, team, individual. The higher up in the organization, the bigger the impact of the change. i.e. focusing with individuals or teams, has the lowest impact on the organizational 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 organization. The model is aptly named Flight Levels.
2. Visualize the work in flight at this level — Sitting with other people in the delivery system to co-create a workflow visualization 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 visualization, identify the large queues, and flush them out — this will mean starting less work initially and will lead to more even flow (aging 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, catalyze 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.

Optimize your organization to keep people busy if you want to get busy people. How about optimizing for delivering value to customers instead?

Want to learn more!? Join Rochelle Roos & Mike Freislich on Flight Levels Board Design (FLBD) remote training from 2-5 June 2020 (13:00 – 17:00 CET each day).