What is flow?

Flow is “a steady, continuous stream or supply of something”. On the highest level, it is all that happens between a stakeholder (like customer) request, and the actual delivery, so it can start creating value. The aim is to deliver maximum value in the shortest amount of lead time with minimal effort, while balancing the wants and needs of different stakeholders.

Many steps need to be taken to deliver value. To name of few: understanding the request, design, build, test, deliver. We can distinguish mainly 3 types of approach:

• Single piece: Working on 1 thing at any given time.
• WIP>1: Working on multiple things at the same time, switching back and forth, where start and finish are asynchronous.
• Batching: Working on multiple things at the same time, where start and finish are synced. Work starts when enough is collected and delivered all at once.

With guidance in place, we can now start managing the actual flow of value. A lot of this is based on the application of queuing theory as described by Don Reinertsen in his books ‘Managing The Design Factory’, and ‘The Principles Of Product Development Flow’.

Why manage queues?

In short: queues are all bad. They are the leading indicator (early warning sign) showing that, when growing, things aren’t progressing as expected and action should be taken. A growing queue is the sign that something (or someone) will be late, stress levels will rise and quality may suffer. In short, if we don’t manage the queues, we will get:

How to manage queues?

Where hardware is involved, several challenges pop-up:

• Make it visible – Due to high WIP and fragmentation due to specialization, there are many items on the board which all have to be managed and clog the picture (can’t see the forest from the trees). This results in resistance making it visible (people prefer using digital lists / gantt charts).
• Limit WIP – With long lead times and high level of specialization, we try to stay efficient by doing other work while we wait therefore increasing the WIP. This also causes asynchronous work and fragmented work further increasing the WIP.
• Reduce rework – To prevent rework quality needs to be built in. For hardware this often means using model based testing which has its limitations and requires investment which means that errors still pass undetected. The alternative, physical testing, is time, effort and budget consuming which leads to postponing/collecting work (increased batch size) which in turn leads to accumulation of errors and late feedback.
• Manage capacity – In hardware often highly specialized mono-disciplinary people are involved. This makes capacity less flexible and asynchronous. Also, the specialized work and/or scarcity of these people prevents them to be fulltime dedicated and co-located. The shear number of disciplines and depth of specialization limit the options for solutions like T-shaping.
• Reduce batch size – There are several reasons that keep batch size high with hardware. Some examples: cost (hours, production, materials, transport, etc.), time and effort (long lead times and slowest determines, manage dependencies with different suppliers and internal parties, physical distance to test location).
• Manage WIP limit – Again, highly specialized disciplines cause asynchronous but interdependent work which makes it for instance more challenging to ‘say no’ or ‘rescope’.
• Prioritize work – Similar to ‘make it visisble’
• Reduce bad variability – To purge repetitive work, one needs tooling capable of taking over. Although more tools are becoming available and tools are getting better, there’s still a lot that requires an expert. Besides that, hardware involves a lot of disciplines and internal/external parties (dependencies) which cause variation.

Defining value: Incremental and Iterative

If we want to deliver a flow of value, we should know what defines value. Especially in a hardware environment where lead times often provide a challenge, it pays to think in terms of “added value”.

The Cambridge dictionary defines added value as “an improvement or addition to something that makes it worth more”. Reinertsen has a similar definition “The value added by an activity is the change in the economic value of the work product”. In other words, would the customer be willing to pay more for the product after the activity has been completed?

We tend to think of value as added functionality, but that’s just one way of looking at it. In hardware, most value tends to come from gradually improving existing functions and features and reducing risks. Some examples: increase of fuel efficiency, increasing the lifetime expectancy of a bearing, lowering the risk of failure or safety incident, etc. In short, value comes in increments (a new minimum viable feature or function) or in iterations (an improvement of a feature or function).

Another way of looking at value is from the stakeholder perspective. What is something worth to them? In hardware development we find 4 main stakeholder groups: External Customers, Internal Customers, Employees, and Business. They are all important and it’s vital to find the right balance. What is meant by the internal customers is the group of stakeholders that’s usually at the receiving end of development also known as OPS, from marketing/sales, via supply/manufacturing to service.

The external customers are mainly interested in: investment (initial purchase, operational costs, disposal), usability (suitability, performance, ergonomics, safety, documentation), and durability (robustness, reliability, maintainability, renewability, disposability).

The internal customers (OPS) are mainly interested in usability (marketability, scalability, manufacturability, supply-ability, assemble-ability, package-ability, transportability, install-ability, commission-ability) and Documentation/information (“the recipes”, availability, usability, reliability).

The Employees are mainly interested in Craftsmanship (technical level, newness, learnings, external quality and confidence level), Internal quality (level and confidence, architecture and design level, technical level, free of technical debt), and application (does it sell, users happy, OPS happy).

The business is mainly interested in Economics (generated value vs effort, technical debt, legacy, delivery rate, MMP, BET/BEAR, gross/net profit margin, cost price, lifecycle stage), and Responsiveness (speed, adaptability, extendibility, robustness).

Splitting for value

If we want fast and early feedback, we need to split the long-term objectives into short term goals and increments. Splitting makes it possible to focus on the stuff that really matters and deliver that first, to create a smooth flow (easier to plan, build and test in cadence), and to estimate effort and value.
Splitting takes place at different levels and preferably just-in-time: a so-called rolling planning where we add detail when it is needed. At the highest level (L0) we look at life cycle milestones like PoC, MVP, MMP, EOL (see Guide flow – Objectives) or other objectives like important events (like a trade fair, a major product launch). Next level (L1), we look from a stakeholder perspective. Can we split for type or subtype of stakeholder, role, location area, etc. and the specific wants/needs, risks and issues. Next level (L2), we look from a product perspective (features and characteristics adding and improving, subsystems/modules/parts). The final, level (L3) is splitting for development process (e.g. defer for trade-off, common enablers, defer via stubbing/reuse).

Due to the various hardware challenges, it is often considered challenging to split into objectives of a few months, and near impossible to split into 2 week goals or even 2 day stories. One problem for instance, is different disciplines unable to take over each others work (swarm). This often means that one or two people are working on something instead of the whole team which results in longer duration. This and other factors like long lead times cause that something, which could have passed for a story or goal, ends up as an objective or feature. To counteract, improve on t-shaping skills, shortening lead times, etc.

It is important to realize that the foundation for splitting is value and this comes in many different forms. Feedback on a paper mock-up is also value and therefore a valid goal or story. Of course, the more realistic and integrated something is build and tested, the more accurate and valuable the feedback will be. So, for a given situation there’s an economical trade-off decision to be made, and for the long term, improvements have to be planned so more value can be created in the future. Another useful approach is to use a deferred Definition of Done (DoD). This means that some work is done for every story (DoD for story), some only done when completing the complete feature (DoD Feature), and some only when actually releasing it to the outside world. Also here effort should be made to improve the process so more can shift from release to feature to story DoD.

Below you find an overview of ways to split features and stories. One common high level way of splitting is by MVP which is very much like life cycle gates (see picture below). In the picture you also see Epic, Feature, Story as is also used in Scaled Agile Framework. An Epic is a bigger objective, typically spanning multiple months and having a big impact (like financial or capacity) and therefore requiring a business case and approval. Features are smaller objectives, typically varying from several weeks to several months. Stories are the smallest and typically vary from a few days to a few weeks. For more details and template examples, read the in-depth article Epics, Features, Stories.

Kaizen, Kaikaku, Kakushin

Adding value mostly happens step-by-step (Kaizen). It’s the continuous every day hard work of all involved to make it better. Then every once a while, as David Lloyd George said “Anything can be achieved in small, deliberate steps.
But there are times you need the courage to take a great leap; you can’t cross a chasm in two small jumps”. When you’re reaching the limit (‘glass ceiling’) of a solution (mostly the effort outweighs the value), it may be time to take a different approach (Kaikaku).
Sometimes even this isn’t enough and a technological or paradigm shift may be needed (Kakushin). This is also known as disruptive innovation, a term coined by the late Clayton M. Christensen and explained in his book The innovator’s dilemma or start by reading the HBR article What Is Disruptive Innovation?.