The path to agile hardware development provides many challenges. A large part of those are actually no different than for instance trying to do agile software development. But many others are related to the nature of hardware, that is, things get physical.
Change in general
Without even looking at the physical aspects, we already find plenty of other challenges. Here you find a list of some of the major challenges (but certainly not all).
Many times the number one challenge. The current ‘disorganization’ keeps us busy and always seems to have priority over ‘future’. This in turn keeps us busy. One can only start by giving it priority and time/budget/people/resources…
The business is doing so well because of how we did it, ‘never change a winning horse!’. In that case, we should be proud of our history as it got us where we are. However, as the world and the organization in it change, you probably also need to change your approach to deal with it. Technology is advancing and getting more high-tech and complex. Customers need and expect, among others, faster delivery, more influence and flexibility. For more details, please read the article Goal.
When we do what we always did, we get the results we always got. Reinertsen mentions in his book “Flow” several, as he calls it, “problems with the current orthodoxy”. They are: failure to quantify economics, blindness to queues, worship of efficiency, hostility to variability, worship of conformance, institutionalization of large batch sizes, underutilization of cadence, managing of timelines instead of queues, absence of WIP constraints, inflexibility, noneconomic flow control, centralized control. Many of these problems are so ingrained, that they are hard to change and have severe influence on the change process. For more details see Flow – What’s stopping us and of course read all the excellent books of Donald Reinertsen and Preston G Smith.
Burning platform / lack of vision
While a burning platform seems an ideal starter for change, it has a huge downside. First of all, it has a negative impulse, it’s something we want to get away from. Next, as with everything you pay attention to, it seems to grow and focus is on the wrong (negative) topics. Finally, once the fire is getting under control, pretty soon it’s back to business as usual. Hopefully it brings some awareness and learning that lead to a new sense of urgency: let’s do this better. That brings us to the alternative approach, which is, starting from purpose (why) and strategic objectives, determine an inspiring vision and positive sense of urgency and keep ‘spreading the word’.
Lack of high level support
Some changes start from the trenches either because management is not doing anything or it is seen as the appropriate approach. In any case, soon people hit a glass ceiling which only management can help break through. And to do so, management must truly understand what it is they can and should do. In short, show leadership.
Not changing the fundamentals
People will follow the path of least resistance. If that path is the old way of doing, that’s just what they’ll do. Instead of forcing people to take the extra mile, make the new path the easy and rewarding path. As Dan and Chip Heath explained in the book The Switch, “When you shape the Path, you make change more likely”.
People tend to resist the unknown and make (bad) assumptions about it. They prefer using ways, methods and tools they know over the new ones. It helps to explain and train people so it’s not so new anymore.
Agile in general
As there are additional challenges to product flow for hardware, a lot of it is not. Creating flow starts with visualizing the work. Most development work is typically hidden in computers (models, drawings, manuals, product data, requirements, etc.). When making it visible (e.g. via kanban boards), you gain insight (like work in process, queues, etc.) and allows you to address them.
Architecture and design
Using modular architecture and design, is already a big step in enabling agility. Though hardware has its limits, much of it can be chopped into modules with clear interfaces.
Though teams with hardware development in it (being mono or multi-disciplinary), have additional challenges, much of the basic knowledge on high performing teams can already provide significant benefits.
Agile hardware specific
One of the most common objections to agile hardware development is lead time. It often takes a long time to produce something (materialize it). In software world, this is typically a matter of seconds or minutes, in hardware hours to weeks or months. Much of this is related to how the organization currently thinks, works and is organized (silo’s, efficiency mindset). That can be changed, even if that often means management support. Of course, as long as we don’t have Star Trek like replicators, there are still limits. This is further influenced by trade-offs like product cost vs speed.
Cost of change
For every change we make, we need to spend time, budget and effort. Hardware, compared to software, comes with additional costs like material costs, manufacturing and assembling/installation/commissioning, physical testing. As development proceeds, the Cost of Change typically rises (more complexity, more details to update, etc.). The height of the cost is for a large part dependent on the product (or module) life cycle stage and the need to update backwards (recall/retrofit). Just think of the difference between updating a prototype and a recall of 100.000 cars. Another big cost driver is the impact area (just a module or the entire machine) and how much we are at the limits of requirements, both which are influenced by the architecture and design.
To become more agile, it is important to lower the Cost of Change and keep it low. For instance by using Model Based Design, rapid prototyping, rapid response suppliers, modules wit robust interfaces, etc.
Compliance to safety, legislation, standards, etc. is of course not limited to the physical part, but to the system as a whole. However, the physical part usually does play a big role in both being a cause and a solution. People get hurt by the physical part, even if a software issue was the actual cause. The ever increasing need for speed, responsiveness and design to the limits can lead to higher risk taking. We are able to design closer to the limit thanks to the use of new materials, accurate predictive models and calculation tools. Besides that, as it usually is not an isolated failing of a component, but the system as a whole (physical, software and people like operators), developing incrementally and iteratively will be more labor intensive and risky. Results can vary from costly recalls and reputation damage, to bankruptcy and even injuries and casualties. To prevent failing break systems, collapsing buildings, crashing airplanes, and the likes, it is vital to find the right balance and probably increase the safety margin.
Many dependencies (specialists and disciplines)
In software there are already a number of disciplines and specialists. In hardware there are even more. Many of the physical aspects require specialist competences which makes it more challenging to combine these into people (like T-shape). This in turn leads to ‘roles’ in a team (or outside) which means dependencies and less flexibility in planning.
Typically for hardware many different people/departments are involved. Just think about purchasing, production planning, production, installation, etc. Next to that, often many parts are coming from external suppliers or are co-developed. Even though there should be made an effort to reduce the dependencies (e.g. by having a supply chain rep in the team, simplifying installation, etc.), it will remain a challenge.
Hardware, as opposed to software, has physical properties (expansion, electrical guidance, weight, wear, noise, etc.) and is influenced by the physical environment (temperature, dust, moisture, space, etc.). Many things can nowadays be simulated using models, but it’s always an approximation of which the validity depends highly on the effort invested in it (depends on trade-off). What you see ≠ what you get. Sometimes we find tiny things (e.g. a supplier using a slightly different material or production method) having major impact (‘butterfly effect’). Also, over time (e.g. due to wear, transport, or changing conditions), all of a sudden issues pop-up. Things that help are: over-sizing/robustness, Form-Fit-Function replacement, modules with simple interfaces and functional requirements instead of physical ones.
Another aspect related to physical properties is that of manufacturing, assembly and installation/commissioning limitations. Many things are still very challenging to even the best of robots. Especially when conditions may vary (tolerances, wear and tear, etc.), complex decision making like algorithms or even AI in combination with spider-like tooling would be required. So, automating this to ease automated integration/testing and fast replacement of parts, has its limits. Besides that, many times it takes quite a bit of effort to replace one part because it requires disassembling and reassembling many other parts just to get to it. Modular architecture and design can ease the pain here, but that has its limits and might come with a trade-off to unit cost and/or performance.
Tendency to oversimplify
Especially for things that people can touch and see, like mechanics, they feel more comfortable with it, leading to ‘co-designing’, (pre)estimating and centralized decision making. Management, sales and marketing people, operations people, etc., then tend to make decisions like planning commitments or design choices without involving the actual developers. This leads to unrealistic expectations around schedules and functionalities and therefore unpleasant surprises and escalations. Besides that, the tendency to oversimplify also leads to questioning whether agile is needed at all (it’s after all simple or at most complicated). We do forget that there’s much more involved than meets the eye and that it’s part of a system including software.