Differences in the development of physical and IT & service products

When introducing agile frameworks and methods, I often hear that agile working in the development of physical products is not possible. I agree that some extensions are useful or even necessary, but the principles are very applicable. So, in this article, I’d like to take a closer look at the differences between the realities of software and hardware development.

Without claim to completeness, I see the following differences to software development:

1. Higher specialization of the developers
2. More dependencies on suppliers
3. Building samples and prototypes is more complex and more expensive (time & cost)
4. Testing is more complex (test benches are also physical systems)
5. Technical feasibility and more dependencies
6. History and habits

In the following I would like to go into each point individually …

1. Higher specialization of the developers

Physical Product Development has undergone a high specialization through its technological diversity and long history. In the product development process, therefore, many highly specialized experts are often involved. The cooperation of these specialists is …

• not necessary in every product development.
• If so, then they are usually not needed 100%
• and not over the entire process (or the entire project duration).

This leads to a contradiction the agile approach of stable and relatively small teams (3-9 people). You would need either very large or very many teams.

The specialization is aggravated by the following circumstances, leading to the hyperspecialization observed today:

• The human need to be very good at one thing, and therefore to seek a niche in which this is possible.
• The need to become indispensable.
• Employee evaluation processes in which individuals are evaluated by their boss

I’m not saying that specialization is fundamentally bad, except that in my opinion it represents a local optimum.

Disadvantages

• Specialists are often unavailable when needed. This creates strong dependencies between the various development projects and therefore, delays.
• Specialists work in many projects at the same time, leading to excessive task switching and they see themselves more as service providers, only feeling responsible for their own outcome.

Possible solutions through agile principles

• Develop some of the specialists to generalists. They work together in stable, interdisciplinary teams who are responsible for a product or a group of products. (Stable teams work closely together over a long period of time, not just over the life of a single project)
• Other specialists work as Extended Team Members for a few teams, and again others work as supporters on request.
• In general, responsibility is not assigned to individuals, but to teams.

2. More dependencies on suppliers

Suppliers are also specialists in a broader sense, not only for know-how and technology, but also for the production and delivery of components and services. This results in the following problems:

• Less transparency, as the supplier forms a seperate company and may initially only promise us a delivery date, but may not be able to keep it
• Long waiting times (frequent quote: “Developing a plastic mold takes at least 6 months”)
• More advance planning of deliveries
• Mistrust between supplier and customer, e.g. by one-sided contracts after tough negotiations

Possible solutions through agile principles

• Closer and trusting communication and collaboration, as well as adequate compensation, mutual support to identify problems early and to update plans.

3. Building samples and prototypes is more complex and more expensive

In software development, building is usually limited to compiling (translation), binding (integrating), and loading (deployment). All of this is usually done with a keystroke or automatically by a script. The whole thing costs almost nothing and is done in a few moments.

In physical product development, we have to think very carefully which samples we want to build and, even more, how many of them, because we have to expect tolerances between the specimens. Since building samples requires material, it costs money. Added to this are the costs for production and the delivery. Since we are usually not able to produce all the parts ourselves (due to the high degree of specialization), we are also dependent on the suppliers (See last chapter).

Possible solutions

• Rapid prototyping (possibly in-house)
• Use of inhouse production
• Close supplier relationships to quickly get to prototypes

4. Testing is more complex

First of all, everything that was said under 3. also applies here, since test benches are also physical systems. This means that also the production and the structure of the test systems are time-consuming and costly.

Also, the setup of the device under test, as well as the configuration and operation of the test systems requires resources.

Possible solutions through agile principles

• Virtualization of tests by simulation
• Automation of the test systems. This makes at least the test operation cheaper and more reproducible.
• Efficient regression tests (repetition of tests with a newer version of the test specimen) become possible in the first place.

5. Technical feasibility and more dependencies

There are fewer questions about technical feasibility in the software and IT world. If an algorithm exists, it is always “feasible” in principle, maybe it needs a lot of resources or runs for a very long time, or is slow. In general, this can be compensated by better or more hardware.

In the physical world, on the other hand, there are many “impossibilities” and contradictory requirements, such as weight, size, robostness, sustainability and manufacturing costs. The task of physical product design is therefore not only the functions and features, but also the balancing of these quality attributes.

Possible solutions through agile principles

• Developing knowledge about the characteristics of a technology early is extremely important when deciding about the physical product design. This may be done by e.g. “Knowledge-Based Development” and Toyota’s set-based design approach.

6. History and habits

The organization’s age

Older organizations have typically established a large number of processes and compliance rules, mostly because of critical events and faults in the past. Such rules often last for a very long time and are rarely taken back. To a certain extend, thsi makes sense and it reflects the experince of the developemnt organization. But very often it makes the process sluggish and slow. Organizations should be careful when adding tests and approvements

Employee age and seniority

In the IT world, employees are on average 10-15 years younger than in the physical product world. Of course, this has a lot to do with the younger technology of software. However, young people have a greater willingness to try new things, value autonomy at work, and want to identify themselves with the company’s values, goals, and products. In traditional companies, on the other hand, we often see a strong top-down culture (command & control). This is not least due to the persistence in thought patterns of the “learning years” of the managers and employees.

“We’ve always done it this way”

Often alternative methods and processes are either unknown or could not prevail due to the “inertia of the mass”. The established methods include e.g. Waterfall & Stagegate processes and the “exclusive thinking in projects”. (For more about that, see the article under https://blog.hardscrum.com/en/das-monopol-der-projekte.)

Possible solutions through agile principles

• Courage, trust and success: Courage to try something, trust in a new work system and, in the end, to experience the success of your own change.

Summary

The article shows that agile methods and principles are also applicable in physical product development as long as some adjustments and extensions are agreed. The P4-Dev framework developed by hardScrum unites these into a coherent structure.