How Well Does Your System Flow?

Photo by Mike Lewis HeadSmart Media on Unsplash

When working with a flow-based Kanban system there are a few statements that I would suggest most teams should bear in mind.

One of my class attendees labelled these as “Jose’s Rules for Flow”

Whilst I wouldn’t go so far as to say these are hard and fast rules, they are some suggestions for that often help team be more successful.

Rule 1?—?On Selecting Work

“Whatever selection process you have, make sure it takes significantly shorter time than the time it takes to do the work”

We invest a lot of time and effort finding formulae and processes to make our work selection activities as reliable as possible.

This makes sense, of course. We know that complex systems have limited capacity to turn all the demand they receive into valuable working products. We also know that a lot of the demand turns out to deliver very different results than what was originally expected. For example, there are features that all our pre-implementation research indicated were going to be in demand and then fall completely flat. While some minor features take off like a rocket.

All this uncertainty makes us very uncomfortable. So, one common approach has been to come up with increasingly complex ideas and processes to determine the potential value of the products and features we have in our upstream pipeline.

Yet, the results are no better. Why? The reality is that all these features are still “unknown unknowns” to us regardless of how much analysis, planning and thinking we put into understanding them.

The only way to validate, or invalidate, the potential value of a product or feature is by actually delivering it. There is no other way around this.

As Simon Reindl puts it “value is an assertion until tested in the marketplace”

So, whenever we are introducing *any* selection process to our work, we need to remember this. The process has to be very lightweight and it has to take a minimal amount of time compared to the time it takes to actually turn that idea into a deliverable that can be validated.

Rule 2?—?On Pulling Work

“Don’t just start work because you can. Start work because you think you can finish it”

We see this story time and time again. A Product Backlog Item is signalled to be blocked. We ask what’s happening and someone says that “Jane is away on holidays for 2 weeks and she is the only person that can do this”.

Another situation that we often see. We are in a PMO meeting and a PM raises an issue with one of the projects she is working on. It turns out that the Web Team has done the work, but there is a piece of functionality in another system that needs to be done for the feature to be done. The problem is that the only team that can do the work is already maxed out and can only do the work in 6 months. If everything else goes smoothly, that is.

These two examples, and variants of these, show exactly the same problem. Work starts because someone somewhere has the capacity to take on the work.

What both scenarios fail to check is that they are capable of getting the work done in the shortest amount of time. They fail to anticipate knowable impediments down the line that can affect the smooth and predictable flow of work.

We work in environments with dependencies and it is imperative that we look downstream from us and check what may impede work flowing nicely until it is completed. This is a fundamental tenet of Flow Management.

Likewise, teams about to start a piece work can also look upstream and anticipate what work currently being done by others is about to reach them and, as a result, make better pull decisions based on that.

Unfortunately, most of us are still working in environments operating in Resource Management thinking where “resources being busy” is considered to be a good thing. No, it isn’t. What needs to be busy is the work. It is the work that has to flow efficiently through its life cycle (or workflow).

So, before pulling in any work, first make sure that at the very least we believe that we, and everyone else needed, can complete the work as quickly as possible. If you know that something is going to get in the way, then don’t start the work yet. Basic checks like these avoid the enormous hassle companies face with dependency management. Incidentally, it increases the awareness and collaboration between people and teams, too.

Rule 3?—?On Wasteful Work

“Treat all the work in-progress as potential waste. Work only becomes valuable once it has met the needs of someone”

How many times you have observed this situation? It is the day before the end of a Sprint (or a Kanban delivery cycle) and, at the Daily Scrum, the testers are talking about working until 3am the previous night and how much work there is still to be done. At the same time, a developer is talking about starting a new ticket because she has “done” her previous work.

When we first introduce Kanban to many teams and companies, one of the first things we allow is for the current system to show all its existing dysfunctions. That’s part of the “start with what you do now” aspect of Kanban.

Why don’t we fix things straight away? First and foremost, because it is the team’s job to fix it. If we attempt to design a “better” Kanban system for them, we rob the teams from the opportunity of really understanding what is their existing system and we also rob them from the opportunity to drive their own changes.

For this reason, I often avoid introducing WIP Limits straight away. Unless there are already WIP Limits in place, that is! Let the system show itself in its true glory. Warts and all.

With that in mind, two of the most common things we first see with the introduction of improved visual management techniques are:

• Where the bottlenecks are (work tends to accumulate before the bottleneck and, often, there is scarcity of work after the bottleneck)
• Highlight the areas where the team is not collaborating well

These two are incredibly common in development teams. When we introduce an improved visualisation with a more descriptive workflow, we often see things like the developers working hard on new tickets, the testers swamped with lots of work and a significant number of tickets in the queue between those two activities.

In this case, this probably shows things like a lack of collaboration amongst the team members (developers develop while testers test), an imbalance in the team capacity to complete work (teams with 10 developers and 1 tester) and the practical sad reality that it is not a single team, but two uncoupled non-collaborative sub-teams.

So, one of the things I often try to reframe as early as possible is the “I have done my job” mindset. It is imperative that teams have a common and shared view of what “done” really means. And that they are fully aware that any work that is “not-done” is a potential waste. So, rather than adding more waste, people have the incentive to look at the board and identify what work has already been started that they can help finish it.

Scrum has captured this really well with the “Definition of Done”. Work is either done or not-done. It is a boolean state. There is not middle term. And our collective accountability is to get work to its “Done” state as soon as possible.

Kanban also has this very well covered with a range of common policies such as Readiness Criteria at each stage of the workflow and a board-level Pull Policy.

Finally, when you look beyond a single team and at wider complex organisation, this is even more relevant. Here we have the same things we see inside teams, but at organisational level. For example a sales team “closing a sale”, but the work that IT needs to do for that client taking 8 months to start. Or a development team having work “done” only for that work to languish in a Git repository for 5 months until another team releases it into production.

All these are terrible examples of very prevalent waste in our businesses. Search for versions of these in your organisation and tackle them. Everything we do is potential waste until there is a happy customer whose needs have been met.

Rule 4?—?On Incentivising Work

“Move all the rewards and incentives to as late in the end-to-end workflow as you can”

Building on the example I used in rule 3, a related issue that we often see is the fact that different people, teams and departments have rewards and incentives placed at different points in the end-to-end business workflow.

Typically, these are placed at “hand over” points between siloed departments.

The problem arises when what we need is collaboration across multiple functions. These incentives can actually act as detrimental “toxic loops” instead of being “virtuous loops” that nurture collaboration.

One common example is a sales team incentivised to “close as many deals as possible” regardless of the capability of the business to satisfy the needs of those new customers. The sales team can probably claim “their job is done” after each sale and, as a result, get its bonus. The problem for the business is that it probably has more new clients that it has the capacity to deliver to. It’s a textbook example of what we should avoid doing.

Now, imagine that the company has calculated that it can onboard 5 new clients per month. Wouldn’t it be great if, for starters, the sales team had this figure as a point of reference? Instead of trying to sign up, say, 20 new clients, they could instead focus on signing 5 *better* clients. Wouldn’t that make more sense?

How about if the sales team’s incentive was moved from the “contract signed” point to the “new customer fully onboarded” point? Can you imagine how different the interactions and collaboration across multiple teams and functions would be?

So, have a look at your current processes and look for the different commitment points, the different “Done” points, the different reward points, and so on. Consider how those different existing practices may help or hinder the delivery of great products or services.

Rule 5?—?On Business Agility

“Your biggest improvement opportunities are not at the team level”

I have spent years working with companies where the main focus is to improve the teams and only the teams. Companies invest significant amounts of time and money embarking on “agile transformations” that never go beyond the delivery teams.

Although agility at team level is fundamental and it can provide good business benefits, the reality is that, often, this is far too little and far too brittle.

Even mid-sized companies of 200 employees will exhibit enough complexity in how work is done to have significant issues managing the scheduling, coordination and dependencies of all this work.

As a result, I have spent years focusing on how to enable Agility beyond the teams and at a business level. These days, the term Business Agility is becoming very prominent as more and more business are finding ways to make a true and lasting impact on their results by expanding agility beyond the team.

These two articles by Edith Coenen describe the journey at her company and the impact that focusing at portfolio level had on their improvements.

Kanban’s focus on service delivery and flow management makes it a particularly useful approach for enabling truly transformative changes to organisations.

There are also remarkable pieces of work authored by colleagues such as Klaus Leopold, Daniel Vacanti and Patrick Steyaert that describe how the biggest opportunities for predictability, improvement, flow management and metrics are at business level.

I will just reiterate that even if you need to pay attention to how the teams deliver work, the biggest problems and opportunities are going to be elsewhere in the organisation and most likely at the coordination and portfolio level.

Business & Finance Articles on Business 2 Community

(62)