Authored by Preetam De, June 19, 2018, a blogagility.com contributing author.
X: We have to improve our Flow efficiency & Lead time.
Me: How come? Our Flow efficiency is around 50% which is actually better than most development teams.
X: Yes it’s above average but still not reflecting on the revenue though. We need to improve it even more, some even have 80% which I think we need.
Me: I have my doubts. We have made the system as lean as we could. If we push too hard, we will start hitting bottlenecks. Also we are not a manufacturing company so we have no choice but to keep experimenting new features.
Neither of us above were totally wrong. We simply had different opinions towards what was important for the business under discussion. “Business” – what kind and why it exists is very important here. Not all businesses can achieve high flow efficiency as they have to experiment too much and fail many times to understand the end user’s real problem. Value is what we want to focus on. To make sense of this article let me define what efficient and effective means to me:
Efficient – Moving from A to B within a predictable system and defined route, repeatedly. (Manufacturing)
Effective – Starting from A with no idea where B is and identifying several options to get to B or C or D. (Development)
My views comes directly from few known facts –
“Nothing is less productive than to make more efficient what should not be done at all” – Peter Drucker
“Simplicity–the art of maximizing the amount of work not done–is essential” – Agile Manifesto, Principle #10
An Efficient system (simplified)
This (below image) is what we can think of when we talk about an efficient lean system with reduced waste. Vast majority of the system is being used to workwith a good Flow efficiency of around 80%.
There are few prerequisites that we often ignore. The most important one is “Predictable” work flow. We can plan to remove every muda (waste) we find and can end up in an extremely lean and efficient work flow that produces a desired output with perfection. Problem with that is, we assume the same Lean principle applies to every knowledge work which cannot be predicted at all. All we can really do is to project a trend based on historical data and come up with an average, which again may or may not be useful.
If the Business is about making predictable product with TQM and adherence towards a specific output repeatedly, higher Flow efficiency is a must. This is hence necessary for every manufacturing business where development (R&D) phases usually exist out of the structured and well defined lean system to meet the high demand of a predictable product.
A sudo-Effective system (simplified)
sudo-Effective: An efficiency focused system confused as an effective one while trying to use Flow efficiency & Lead time as their KPI.
This (below image) is what we can think of when we talk about a sudo-effective & partially adaptive system. Vast majority of the system is NOT being used to workwith a rather poor Flow efficiency of around 20%.
In the above example, the Discovery & Prioritisation is shown as a separate phase which is true for many companies. A request from a customer or stakeholder stays on a product backlog for quite a long time without getting prioritised for months. When it eventually gets prioritised, it might be too late and may have lost it’s intended value completely. I am pretty sure a majority will relate to this example as this is the naked truth of majority of so-called “Agile” departments of an organisation.
An Effective system (simplified)
This (below image) is what we can think of when we talk about a truly effective & highly adaptive (agile) system. Vast majority of the system is being used to workbut in extremely unpredictable fashion with overlapping development phases. The majority of the system is focused on doing the “right thing” and frantically experimenting all possible outcomes and collecting feedback on the go.
Are we building the right product?
This question is being asked, as the business regularly faces the challenge of changing requirements heavily influenced by continuously improving competition and their new products. It’s neither predictable nor has an option to make it leanby removing waste. In fact, it is full of wastes that the system is actively creating to learn what doesn’t work.
The Flow efficiency can be very hard to establish in such systems making the KPI irrelevant in this case.. working prototypes are the true measure of agility. We shouldn’t measure Flow efficiency when true effectiveness has to be achieved.
Agility is about continuous adaption, Lean is about perfecting an adaptation. Providing value is a common goal for both, in very different context.
Some recently posted wisdom from influential & respected community members around it:
Value – Define what it means for the Business in context!
Be it Lean or Agile principles, both defines Value as end user consumable products/services. Who the end user is, defines what the Value might be and therefore what principles to follow to provide that value.
Few example of industries and recommended focus
Product Development aka R&D – Based on current generation’s need we have seen time and again that being adaptive is what make or break it. If a development team focuses too much on lean principles to become super efficient, there is a good chance that they forget to consider whether they are really working on the highest priority value according to the customer’s need. They start focusing on processes, tools and intricate mechanics with a partial or complete disregard of the “WHY”.
Hence the recommended focus of such teams and organisation should be to follow Agile principles to become more effective while keeping the necessary efficiency which supports it.
Service Delivery – Any company responsible to provide a part of the system usually 3rd party service providers. consultancies, call centers etc. you name it. Every such industry have very different end users with very specific definition of Value.
For simplicity of explaining, say you are part of an IT consultancy who is responsible to migrate all data from a decade old infrastructure to AWS. There’s a good possibility that the steps necessary for the most part is a mix of finding unknowns and known facts about the migration. End user is the company paying for the service to get it done, a consultancy has quoted a price & date to make it happen. For the consultancy the value hence is defined as “Provide solution by <date> with a £x budget all inclusive.”
To Conclude
There is no right or wrong, just a variable business context and how we define “Value” as.
Sometimes we want to focus on efficiency and sometimes we focus on high effectiveness over efficiency. If you are measuring Lead time or Flow efficiency for a development team, be prepared to get a useless KPI which neither helps you nor the team developing. Measure what is needed to achieve the value rather than trying to fit the same principles everywhere. A simple rule to remember where to apply –
1) When we hear “development” assume obvious complexity, unknowns, learning and adaptation where Lead and Cycle time is very hard to establish.. and at best can be totally wrong. Be agile.
2) When we hear “production/manufacturing” assume predictable known steps with defined output at mass where Lead & Cycle time are extremely useful KPIs. Be lean.
blogagility.com 