development of cyber-physical products - bits and screws.

more than bits and bytes.

One speaks of "cyber-physical" in connection with a product or a system, which not only contains purely digital software parts, but where hardware and mechanics also have to be developed. A smartwatch or a bicycle computer are examples of this. Apart from the software, such products have electronics with, for example, a battery, controller and display. The development of the mechanics is also a challenge, especially for outdoor products. The interaction of these disciplines influences many product features, including the product design, which is becoming increasingly important and, in addition to the functions, represents another important feature in the purchase decision. A smaller case may increase the internal temperature or require a smaller battery.

If these disciplines are to be synchronized in terms of time and content, you have to understand the differences. So it's not just about bits and bytes, but also about resistors, conductor tracks, housing and screws.

everything agile?

If one speaks or reads about agile development, purely digital applications are often referred to. This can be a cloud application or a smartphone app. The framework conditions that apply here are ideal for quickly and iteratively developing, testing and improving features. You start by working out a backlog, prioritize, define an MVP [1] and work towards the release sprint by sprint. Once an MVP is with the customer, continuous improvements or extensions are delivered quickly and directly.

The world of hardware and mechanics is clocked differently. Here, too, an agile approach is an option. There are articles in the literature on how the hardware can also be developed in a modular manner so that individual subsystems can be improved and tested iteratively and independently of one another. Nevertheless, overhead and additional costs must be compared with the benefit. In any case, the lead time required is significantly greater. A circuit board is not reassembled or a housing recast with a different tool as quickly as a constant value in the software is changed. Different planning is required.

Most software projects in which the scope is not clear from the start are developed using agile methods. The hardware and mechanics are often defined, developed and tested in the V model. This works very well. It gets exciting where these worlds meet. For example, if the hardware requires a bootloader that must already be available in production. This is a classic example. The task here is to manage the balancing act in order to successfully launch the product on the market.

the overall perspective is crucial.

You can try to transfer a discipline to the other world. For example, the hardware can be developed agilely from sprint to sprint instead of in the V-model. That can have advantages. For example, the hardware design can be split up for this purpose and, instead of accommodating all subsystems on one circuit board, decoupled via additional interfaces that no longer exist in the final product. A change in a subsystem can be better isolated in this way. Depending on the problem, however, the advantages are not in good proportion to the additional effort and costs. In such cases, it is more effective to take a closer look at the requirements at the points of contact between the disciplines.

What do hardware and mechanics need from the software? When is the bootloader required and with what range of functions? What is necessary for the EMC test [2]? Many such questions need to be asked and answered. This is based on the discipline that requires a longer lead time. In concrete terms, this means that the software parts that are essential for the other disciplines are identified and the corresponding work packages are prioritized in such a way that the correct sprint increments of the software fall on the milestones of the hardware and mechanics.

At first this sounds easier than it is. In any case, it requires an understanding of the overall architecture of the product in order to identify and define the dependencies between software and hardware very early on. If you know the content, these expenses must also be estimated. However, it must be taken into account here that the velocity of the team fluctuates over time and these identified work packages can lie further in the future. Tracking progress in the sense of "Inspect & Adapt" and flexible planning is therefore all the more important. A cross-functional team, which simplifies the cooperation between the software, hardware and mechanics disciplines and prevents silos, is also a basic prerequisite for success, in addition to looking at the overall architecture.

Of course, such a short blog post can only touch on the relevant topics. The combination of these different "worlds" is and remains a challenge. However, one should always be aware that it is about more than bits and screws, but also about a cross-functional team, forward-looking planning, understanding of architecture and a lot of experience.