Develop Physical Products under VUCA

Today’s development world is characterized by VUCA which stands for Volatility, Uncertainty, Complexity, and Ambiguity. In other words: regular change is a given, we often face unknown unknowns, most of the time many people and parts are involved, and the real world is kind of hazy. Some examples of VUCA sources:

• Market Fast delivery expectations, decay of value, unclear needs, quickly respond to fast changing needs or regulations/politics, mass customization, loss of market share (fast fish eat slow), …
• Technology New technology, unclear fit for purpose, technology decay/obsolescence, digitalization, IOT, industry 4.0, system complexity, …
• Other Development involves a lot of people resulting in a lot of dependencies/communication/opinions/etc., good people are hard to come by and it’s important to keep them motivated and engaged, dealing with dependencies to other departments or external parties, preventing snowballing and planning variability, Investment (inventory) debt, bleeders and snowballing, …

These aspects lead to increased VUCA and hardware is, more than ever before, part of a complex system being built by a complex adaptive system. And when things get complex, we have to accept that simply following a plan is no longer going to work. Innovation and product development thrive on complexity (or even chaos) so it’s part of the job and we better deal with it. However, some of it we can do without and it helps if we rid ourselves from it. For more information on complexity, please see Product Development Complexity.

To make it more tangible, we can put a price tag on each of these aspects. This results in a so called Cost of Delay which basically is the cost we ‘pay’ if not acting. The accumulated (total) Cost of Delay provides a good indication of the importance of speed and agility, and a sense of urgency to accelerate. For each enterprise and even each product, this graph may look different and require a different speed and agility.

Thrive or survive?

The purpose of FlashDev™ is to help organizations flourish into a more rapid and responsive organization with respect to hardware development. This means transforming the organization which basically means transforming its culture. And transforming a culture, particularly one that has stabilized, is not an easy feat. In short, we need strong motivation…

Motivation to take on such an endeavor can originate from feeling inspired (thrive) or feeling threatened (survive). When we see opportunities with an expected outcome that matches our wants and needs, and outweighs the expected effort, we feel motivated to take them on. Similar, when we see threats and fear the consequences, it makes us uncomfortable, and we want to reduce that discomfort. Where inspiration leads to something better than before, responding to fear is mostly about trying to prevent from getting worse.

There are quite a few disadvantages to going in survival mode. It causes negative stress which makes people perform less, undermines motivation, and creates analysis paralysis or even overall paralysis. Also, it leads to rushing or panic reactions causing quick and dirty fixes based on current mindset (not really making a step), lots of unproductive mistakes. 
So, if we would prefer to use the positive, inspiring approach over the negative, fear inducing approach, then why is it that we mostly do the opposite? For one, in general it can be said that fear is stronger motivator, easier to create, and is contagious. It directly aims at the lowest parts of Maslow’s hierarchy of needs. Also, remaining inactive under threat will likely result in bad outcome, whereas for failing to pursue an opportunity we don’t directly see strong negative consequences. And as we’re usually very very busy, we tend to postpone to the point where an opportunity becomes a necessity, or we fail to see it in the first place. It can also happen that we are faced with an immediate threat we couldn’t have foreseen.
So when should we launch a transition with highest probability of success? Too early and most people do not understand or see the need, too late and you may be too busy putting out the flames of your burning platform. So, depending on the current organizational culture and other circumstances, your sweet spot may be near the opportunity side or the threat side. 

Thrive

Below you find some examples of what a thriving rapid and responsive hardware development organization could like like from the perspective of the three main stakeholder groups. It could serve as input to a compelling vision…

Business perspective – By creating value in a continuous flow that we can influence and release on demand, we shorten the time to market, have much more control over what to deliver when, and are able to respond to changing circumstances fast. We can be fast and create new opportunities like mass-customization while keeping development cost, product costs and risks low, and quality high. The return of investment will improve as the time to return will be shorter and investments are more continuous instead of big bursts. The careful prioritizing by value over effort and continuous improvements like automation will reduce waste and improve the overall profit, as well as provide more room for innovation. Last but not least, keeping employees and customers happy is of course in the direct interest of the business (see below how to).

Customer perspective – Because of fast iterations with close contact and interaction, there will be more care and understanding of their needs and opportunities for them to influence, as well as a speedy and flexible service. Continuous incremental flow of value, cadence, and built in quality, enable a consistent and accurate manner of delivery. A high level of built in quality and use of modern practices and tools will create trust and confidence, as well as more space for innovative solutions and customization.

Employee perspective – Automation reduces a lot of boring repetitive task and annoying rework, freeing up time to work on challenging innovative solutions. Forming cross-functional teams enable collaborating on end-to-end solutions while removing the annoyance of fixing ‘over-the-wall’ issues. Decentralization provides autonomy and influence and being able to proceed. Designing, building and delivering small end-to-end increments in close contact with stakeholders create more engagement and the fast feedback and low risk opportunity to act upon it boosts motivation. Working with modern tools and practices and focus on quality, enables the feeling of craftsmanship. Transparency and overall collaboration provide long and short term clarity and direction. Servant leadership and continuous improvement help remove blockages and create a better place to work each day.

Survive

Below you find some examples of what could happen if we don’t take action from the perspective of the three main stakeholder groups. If a compelling vision fails, this might get things in motion, but as Deming once said, “It is not necessary to change. Survival is not mandatory“. 

Business perspective – The current orthodoxy of worshipping efficiency, conformance and first time right, lack of understanding and quantification of cost of delay and queues, and love for large batches, drive most projects over budget, over time, and have a high probability of failing to deliver what was actually needed or it will have lost much of its value. This results in disappointed customers, employees and the business itself. It is then easy for a smart competitor to gain market share (“fast fish eat slow”) and build a strong connection to customers so it’s hard to get them back. When market conditions like regulations change, or new technology becomes available, the situation becomes even worse. These competitors may become a new fun place to work for your hard-to-find and highly-invested-in disengaged employees. Replacing them will be challenging as your command and control, old-fashioned, low-tech workplace is probably not the most attractive. Or if they stay, they’re less motivated and engaged, lowering quality of work and productivity.

Customer perspective – Hearing replies like “sorry, we’re too late”, “sorry, we can’t do that”, “sorry, we thought that..”, or “sorry, that will be in our product in 5 years” too many times, gets customers to scout for a better supplier. So as soon as a competitor shows up that does it slightly better, your customer is gone and won’t return any time soon. Customers are getting used to fast or even instant delivery via all kinds of services nowadays. They start to expect this as well for your services. They are also getting used to the latest technology and customization and get disappointed and skeptical if you can’t deliver that.

Employee perspective – Working in an old-fashioned, slow, high-admin, rich of rules, command and control organization where you have little autonomy, have to work with outdated tools, spending most of your day in boring meetings and most of the rest doing low-skilled uninteresting work, is something you can do for years. However, when the opportunity arises of an employer that provides a fun, challenging and purposeful place to work, it will be hard to resist and at minimum lower your motivation and engagement.

Fit for purpose

Depending on the actual circumstances you’re (going to) face, you must find a fit-for-purpose organizational system. The competing values framework can help to provide some insight in this. In order to be successful, an organization will have a mix of types, but, depending on their environment, a predominant type can be identified. There is no best culture, just the best fit for the current circumstances. By plotting both the current organizational situation and the desired one, you can identify the size and position of the gap. For more details, please see the the section on Competing Values Framework in the Foundation.

The fast world of Formula One

It is known as the fastest R&D in the world and serves as a great example for agile hardware development. In between each race, giving them one or two weeks, they manage to do complete development cycles. The race is the demo and serves as the end, and simultaneously, the start of a development cycle, or as the military call it “OODA-loop” (Observe, Orient, Decide, Act). The race provides a lot of data and feedback from the driver. This is discussed and results in ideas for improvement to be designed, built and tested before the next race.

There is a lot to learn from Formula One teams regarding agile hardware. At the same time it’s also important to understand the differences with your company / product. There are probably different trade-offs to make. For one, an F1 car is basically a driving prototype meaning it’s not aimed for market and cost price is less prominent then for your average Volkswagen. Also, they have a huge development budget which many companies only dream about. Despite that, it really pays off to observe and learn from them, and be creative in how to apply the lessons learned.

Is it possible and to what extend?

To be very short, yes, it is possible. There are many examples of initiatives in agile hardware development with varying success and levels of maturity. The most well known are Tesla, SpaceX, Saab Gripen, John Deere, and Lockheed Martin’s Skunk works. Other well known companies making their way towards agile hardware ASML, Philips, Volkswagen, Bosch, DAF, Vanderlande, etc. This in turn will start triggering the many partners/suppliers in their network. And lets not forget the many smaller companies and start-ups that are experimenting with agile hardware and facing their own specific challenges.

The success depends mainly on two factors (or challenges): organizational and hardware. Any significant change in an organization poses major challenges regarding people, culture, history, structure, etc. On top of that, there are some unique challenges with hardware development. Examples are: cost of change, lead times, supplier dependencies, physical properties, environmental conditions, etc. This does not mean it can’t be done, but we have to accept that it will require more time and effort and will have its limitations which means a increased need for stronger motivation (via why, vision) and support. For more information, please read the in-depth article Agile Hardware Challenges and The journey.

Product Development Complexity

First let’s understand a bit better what complexity means by looking at the Cynefin Framework. Then let’s dive a bit deeper into the factors that drive the ever increasing complexity in product development and specifically, hardware development.

Cynefin

Dave Snowden developed an excellent framework for understanding and dealing with complexity called Cynefin (pronounced kuh-nev-in). A Welsh word that signifies the multiple factors in our environment and our experience that influence us in ways we can never understand.

Clear – Things are considered clear (or obvious) when you know exactly how to do it (the “known knowns”). Just follow the recipe (best practices). Its the stuff you can standardize, automate. All it requires is knowing what you want to do and find the right recipe for it: “sense–categorize–respond”. Establish the facts (“sense”), categorize, then respond by following the rule or applying best practice. Examples: run a standard test, create production drawings, assemble 2 parts, etc.

Complicated – When the recipe is there, but unclear which one to use (“known unknowns”). The relationship between cause and effect requires analysis or expertise; there is a range of right answers. This is where specialists come in, analyse and respond by following a know recipe: “sense–analyze–respond”. Assess the facts, analyze, and apply the appropriate good operating practice. Examples: trouble shooting/bug fixing, design decisions, failure modes and effects analysis, etc.

Complex – Things get complex when there is no recipe yet and even more so if conditions change a lot and fast (“unknown unknowns”). Cause and effect can only be deduced in retrospect. There are no right answers. The way forward here is to try stuff (probe, experiment), then see what the outcome is and respond to that: “probe–sense–respond”. Examples: people behavior, market changes, new technology, reorganizing, etc.

Chaotic – In a situation where things happen without a known cause (not even in hindsight), it’s called chaotic. Events in this domain are “too confusing to wait for a knowledge-based response”. Just do something, see what happens and respond to that: “act–sense–respond”. Responds can vary from establishing order to sense where stability lies and steer back to complexity. Examples: fire, radical brainstorm session, panic, etc.

Confused – This is where people tend to spend a lot of time as they’re either not clear in what area they truly are or simply unaware or ignoring it.

Product development does not build and ship hardware, instead they deliver the recipes on how to do that (drawings, specs, manuals). Its purpose is developing new recipes as it makes no sense in delivering the same recipe twice… Even when you’re delivering almost the same recipe (a minor change or addition), you’re still entering the complex zone. Considering it as complicated or even clear means you’re actually in confused. On the other hand, not all tasks related to product development are complex. Some examples are: (clear) performing a repetitive test, (complicated) solving a production issue. This means that product development deals with a mix of chaotic, complex, complicated and clear tasks. Clear tasks can be planned (or even better, automated away). Complicated tasks can only be planned after initial analysis. Complex tasks require enabling constraints like safe environment, openness, and also, do small experiments (increments/iterations). Chaotic is mostly considered a bad thing. However, a good brainstorm session has chaotic elements in it to break the traditional paths, so is very useful. Something similar goes for complexity: to be able to handle purposeful complexity, it’s helpful to reduce complexity you can do without (like ad-hoc meetings replaced by cadence planned events).

For more information on Cynefin, the following article by D. Snowden comes highly recommended: A Leader’s Framework for Decision Making.

What drives product development complexity

Complexity is driven by various factors influencing and amplifying each other.

Organization:  the interactions of an organization with its environment like public authorities, suppliers, other departments, customers, etc. Think of market expectations (fast delivery, quickly respond to fast changing needs, mass customization), competition (fast fish eat slow, fast scaling start-ups, not all play by the same rules), compliance (safety, international standards, local laws and expectations), suppliers (many and/or new co-developers and suppliers, long lead times, unresponsive, tight coupling), size (many people/departments/disciplines/stakeholders involved), impact (process changes, financial risks, customer side risks, unknown duration, reputation risks), stability (unclear direction/purpose, unclear roles and responsibilities/mandates, many different developments at same time).

Product: product aspects like market requirements (high tech, unclear, changing fast, amount of customization required), composition (many functions, interfaces, modules, challenging integrations), dependencies (third party components, external developments), conditions (environmental requirements, non-functional requirements importance and clarity), size (too big or expensive to build/test).

Resources:  Related to human aspects, material and financial resources. People are inherently complex to start with. Further think of availability (specialists are hard to get, only part-time, on standby, lack of experience, technical and domain knowledge). size (number of people and different specialized disciplines involved, many dependencies to other departments or external parties), location (distributed, international), knowledge workers (have different needs).

Technologies: technologies that are in use in the product being developed. Think of new to the company/developers, new to the world, cutting edge, changing fast, digitalization, IOT, industry 4.0.

Reducing complexity

There are many things that increase the complexity of new product development. To be able to focus on the complexity that bring value, we should reduce the complexity factors that keep us from doing that. Several of the practices described in FlashDev™ are aimed just at that. Examples are: modular architecture, synchronized cadence based events, cross-functional teams, standardization and automation, built-in quality practices, limited use of tools. However, keep in mind that with every reduction of complexity (or simplification), you also loose some of its potential benefits. Relying too much on automated tests for instance, can cause unpleasant surprises. But also, knowledge and experience are reduced when things are running automatically and people start forgetting what it exactly was what we were doing and why. Some countermeasures are exploratory testing, out-of-the-box sessions, etc.