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).
No time
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…
No need
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.
Current orthodoxy
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”.
No idea
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
Product flow
As there are additional challenges to product flow for hardware, a lot of it is not hardware specific. 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.
Team Flow
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
Lead time
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
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.
Physical properties
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.
The Scrum Guide seen through the hardware lens
Scrum is a lightweight framework which is most commonly used in the software domain. Teams facing difficulties when trying to use it in the hardware domain, often relate that solely to being in the hardware domain. The truth is that the same or similar difficulties are found by many teams in the software domain, or any other domain for that matter, as well. However, we do see that the difficulties are more common and more challenging for the hardware domain due to often high lead times, more specialists, dependencies with complex and large stakeholder field, physical issues requiring time-consuming physical testing, etc.
Below you find a brief explanation and remedies to deal with the difficulties. The applicability of any of the suggested remedies depend on desirability, feasibility, and viability of them, so should be considered in the light of the actual situation.
| Topic in Scrum Guide | How to deal with it |
|---|---|
| Cohesive unit of professionals | Scrum as defined in the Scrum Guide is designed for a cohesive team. A team working together towards a single goal. Often, teams find this hard, especially when new to Scrum. There is an optimum cohesion given the current circumstances, and improving those circumstances will move the optimum to higher cohesion (see Cohesion). Some suggestions to help the team work more cohesively: provide a Sprint Goal and value based multi-disciplinary stories, develop T-shaping, reduce lead/wait time, create focus by clustering work. A team that has an optimum away from full cohesion, has to deal with that. It means that the events will have to be approached slightly differently and that not all will be working on the same backlog items or even Sprint Goal. |
| 1 Sprint Goal | In Scrum the Sprint Goal is defined as “why the sprint is valuable to stakeholders”. When it is difficult to create a single Sprint Goal, for instance in a less cohesive team, the advice is to not create multiple Sprint Goals, but rather select what is providing most value for stakeholders as the goal and consider the product backlog items not related to it as additional work. Sometimes however, for a given situation, though conflicting with the Scrum Guide and only to be used if really helpful, one could add additional Sprint Goal(s). |
| Daily Scrum, max 15 minutes | Teams sometimes suggest a lower frequency like bi-daily or weekly because too little progress has been made to share or people are not working on the same topics so claim having nothing of interest to share. The advice is to stick to a daily frequency and rather keep it short, and at the same time improve the value of the Daily Scrum by creating more cohesion in the team using the suggestions made earlier. Only under special circumstances, one could decide to, temporarily, go to a slightly lower frequency. |
| Done work | This depends on what is considered Done which will vary with the domain of work and maturity of the team. In the hardware domain, the definition of Done tends to be more intermediate-value-based as it is most often not feasible or viable to materialize it in the hands of customers. The advice is to define stories based on whatever brings value to stakeholders like reduction of uncertainty/ambiguity/risk, improving performance, reducing product cost, reducing lead time, etc. The main stakeholders are the users/customers, the business, and the development organization, and value varies with the different needs of the different stakeholders. In Scrum, providing the Sprint Goal is met, work not Done is simply considered not being part of the increment. It is up to the Product owner to decide what to do with it. Though, when this happens regularly, try to improve by addressing the root causes for instance lack of T-shaping, neglecting or underestimating lead times, not cut into small enough valuable pieces, etc. The Scrum Guide mentions that “Scrum’s artifacts represent work or value”. So not every Product Backlog Item needs to deliver value for a stakeholder. Sometimes we just need to do some work like ordering a part. These items can be split to fit the Sprint like an item for “order part” and later one for “receiving/checking part” when it has arrived. |
| Usable Increment in Sprint | Scrum talks about an Increment of value to be delivered in a Sprint and that to provide value, the Increment must be usable. There is no definition or explanation of the word ‘usable’. Value can be very different for different stakeholders and different domains, and for the stakeholder to make use of it, we need to consider what they want to accomplish. If for instance, the stakeholder needs to learn if a certain solution idea is feasible, the results of a quick lab test may suffice. Or, if a stakeholder needs to assess if a certain solution idea is not in violation with health and safety regulations, a CAD model or 3D print may do the trick. To make sure that Product Backlog Items can be finished in the Sprint, make sure to properly estimate for size and duration, assess any risk that could compromise this, and split items where needed. |
| Missing long term view in Scrum | Scrum is mainly focusing on the short term, having the Product Goal and Product Backlog as the exception. For many teams, especially teams in the hardware domain, this is not sufficient as they deal with long(er) lead times, many dependencies, commitments like release dates and milestones, etc. Many of these needs are addressed by scaling frameworks like SAFe. Even if you are just one or few teams, you could well benefit from the practices as described in the following article, six SAFe practices for s-sized-teams. |