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 the 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 (PPE) has undergone a barely detectable deepening and 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 it is usually not 100% necessary
  • and not over the entire process (or the entire project duration).

This contradicts 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, which leads 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 each individual is 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 waiting times.
  • Specialists work in many projects at the same time, so they see themselves more as service providers and only feel responsible for their expertise.

Possible solutions through agile principles

  • Development some of the employees to generalists. They work together in stable, interdisciplinary teams who are responsible for a product or a group of products. (Stable teams work closely and over a long period of time, not just over the life of a project.)
  • Specialists work as extended team members for several teams or 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. This results in the following problems:

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

Possible solutions through agile principles

  • Closer and trusting communication and collaboration, as well as adequate compensation of performance, help to identify problems early and to update plans based on trust.

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, most of all, 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 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.

Possible solutions

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

4. Testing is more complex

First of all, everything that was said under 3. applies, 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 system requires resources.

Possible solutions through agile principles

  • Virtualization of tests by simulation
  • Automation of the test system. 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 virtual software and IT world. If an algorithm exists, it is always “feasible” in principle, maybe it needs a lot of resources or runs 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, strength, and manufacturing costs. The task of optimal design is therefore not only the function, 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 in choosing an optimal design. This is 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 events in the past. Such rules often last a very long time and are rarely taken back.

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 young technology of software. However, young people have a greater willingness to try new things, value autonomy at work, and want to identify with the company’s values, goals, and products. In traditional companies, on the other hand, we 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. Stagegate processes and the “exclusive thinking in projects”. (For about that, see my article under https://blog.hardscrum.com/en/das-monopol-der-projekte.)

Possible solutions through agile principles

  • Only one thing has grown up against the change in the agility of people and organizations: 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.

One thought to “Differences in the development of physical and IT & service products”

  1. Oliver,
    This a great manifesto for product design agility, thank you for summarizing your vast experiences and providing tips.
    In my experience, I have seen most of the traits you pointed out in your article and solutions, partial solutions to the impediments are indeed very close to the ones you suggested. I may just not agree on the point about the age…but I’m biased…I’m indeed from the last millennium…

Leave a Reply

Your email address will not be published. Required fields are marked *