Joachim Pfeffer: Techniques for agile product development

Last week, Joachim Pfeffer reported in an interview on why agile product development makes sense for companies. This week, we're looking at specific techniques and practices for achieving success with agile product development:

• Value stream mappingOptimization of value streams through improved release and reconciliation mechanisms, without technological investments.
• Agility & Systems EngineeringSystems engineering as the basis for iterative and incremental product development.
• Integration, architecture & interfacesEarly integration and stable interfaces to avoid integration problems.
• Roadmaps & versioningVersioning and management of interfaces to reduce complexity and facilitate planning.
• IterationsShort development cycles and flexible "Plan B" solutions for continuous integration.
• Software development as a role modelUse of CI/CD, versioning and test automation from software development.
• MBSEPotential through consistent model-based systems engineering, but high effort for consistency.
• Pull systemsKanban to reduce multitasking and improve throughput times.

Enjoy reading - or watching the video!

Value stream mapping

Joachim pointed out several times that the challenges are more in the People than in the technology. This insight is not new: nevertheless, it is always amazing what results can be achieved without any investment in technology.

As an example, Joachim Value Stream Mapping (VSM)a technique from Lean, which is also used in SAFe is used. He regularly moderates workshops on VSM. Often misunderstood: It's not about process optimization, but about mediating between the department and management. He often hears from decision-makers in workshops: "We can't be working like this."

In practice, it is simply the case that departments optimize themselves internally, but there is no one responsible for the value flow through the departments. This sometimes results in figures such as a downtime of 90%!

In several cases, we reduced lead times by 30% without any investment, just by optimizing the approval and reconciliation mechanisms.

In many companies, management sees it as its duty to save projects. However, this is not their job at all. The task of management is to optimize the organization. In many corporate cultures, however, it is unfortunately inconceivable to give management the time budget for this task (regular workshops lasting several days).

No agility without systems engineering

Joachim tends to use the term "Lean" than "agile", as agility, at least in some areas, is already a bit burnt out. But in the end, it depends on the definition with which he Part 1 of this interview began: "Lean (agile) product development means developing products iteratively and incrementally in small learning loops in order to learn faster."

However, this definition implies that the company has at least traditionally developed in large learning loops. Unfortunately, this is not yet the case for many companies. He therefore sees a certain level of maturity in systems engineering as a basic prerequisite for being able to enter agile product development at all.

If I am weak in systems engineering, I find agile product development very difficult.

As Case study he cites the development of a measuring device. In this project, the system to be developed had a solid architecture with stable interfaces. This enabled the team to produce an executable system with commercial components at a very early stage. Once this was achieved, the team could continue to develop the product step by step. But this worked particularly well because there was an executable system early on that remained executable even with continuous further development.

Important: "We always had a functioning system."

Reduce problems when integrating with architecture

Many systems have problems with the Integration come to light. Therefore, as described above, it helps to create an integrated, executable system at an early stage. However, there are other measures to gain speed and reduce problems during integration.

The Architectural goals play an important role here: many companies set targets such as production costs, installation space, etc. The important goal of adaptability is often missing.

When it comes to customizability Interfaces plays an important role. If the interfaces are stable, components can be developed further without having to change the entire system. This is why interfaces also need their own versioning.

Roadmaps for interfaces and more

Because the Interfaces are so important, Joachim recommends not only versioning them, but also managing them properly. This includes, for example, Roadmaps for interfaces and to announce changes. This is the normal case for public, standardized interfaces (e.g. USB or Browser Extension Manifest). With internal interfaces, we now find this quite frequently with APIs, but rarely for mechanical or electrical interfaces.

Sensible interface management helps to always have an executable system. Consumers of interfaces can then plan accordingly. For example, it may be necessary to work with mechanical or electrical adapters for a transitional period, which is already common practice in software development.

Interface management and regular refactoring of interfaces contribute to mastering complexity.

Because the domains are so different from one another, different Roadmaps for software, mechanics and electronics which can then be coordinated with each other. Component roadmaps also make sense, which in turn are based on the coordinated interfaces (and interface roadmaps).

Pragmatism is of course important here; the roadmaps are a tool and must not become an end in themselves.

Clocking of iterations

The aim of agile product development is to shorten development cycles. Here Joachim recommends a hard clockingas this reduces the complexity of the development process. However, this also means that every team needs a "plan B" in case there are delays. This can mean, for example, using an older component with an adapter after all. However, the system's integration capability must be guaranteed at all times.

I need to know at all times: How do I keep the system ready for integration?

To accelerate the pace (with full integration), we need to work differently. The software industry is leading the way, where the production system is sometimes deployed hundreds of times a day. This, in turn, is only possible with automation. There are many possibilities that are hardly used today:

3D printing 3D printing is now also being used in production (not just for prototypes) because it can reduce the logistics and number of parts, and therefore the complexity.

Design automation can drastically reduce development times for non-innovative design. This is an approach that Flow Engineering would like to make available to customers. At this point, Joachim mentioned the Design compiler from IILS (Stephan Rudolph).

Artificial intelligence has potential on the upper left side of the V-model, where there are already initial solutions, such as Raiqon or Trace.space.

Specialized models such as FEM, injection molding simulation, thermal vibration, etc.) could be integrated much more closely into the development process

Test robot can act automatically during testing and integration, e.g. when assembling, operating and manipulating products.

Software development as a role model

In the late 1990s, complexity was a major challenge in software development, but it is now under control. So Joachim, like many others, looks to software development for inspiration. Of course, these cannot usually be adopted one-to-one. The following options exist and are already being used in some cases:

Continuous Integration / Continuous Delivery (CI/CD) can also be used to a limited extent for hardware-based products, particularly for software (over-the-air updates). However, this is also possible with hardware, as is the case, for example, with SpaceX during the production of the Raptor engines is practiced (no two Raptors are the same).

Branching and merging for models and not only for text has enormous potential, because this is a basic prerequisite for asynchronous work. More and more modeling tools have at least rudimentary solutions, regardless of whether CAD models (e.g. Onshape) or SysML model (e.g. LemonTree).

Configuration Management is still a major challenge in product development. This was also a challenge in software development, which was solved via Package management was solved. In product development, Joachim tends to see BaselinesThe responsibility rests with the company, in particular cross-tool baselines.

More extensive versioning is necessary to enable configuration management at all. As an example, Joachim cited printed circuit boards, which are often overlooked as an artifact to be versioned.

Test automation was an important driver in software development. As mentioned in the previous section, testing can also be automated in many areas of hardware with simulations and robots, where it was impossible just a few years ago.

Different timing is an important tool, as we cannot switch off physics. It is not a problem at all if different components have different cycle lengths.

The software is released every two weeks, but the housing is only available every 12 weeks

MBSE

Is Model Based Systems Engineering (MBSE) now the key to agile product development? Joachim sees the potential, especially of SysML v2. On the other hand, companies find it difficult to see the benefits and even more so to realize the benefits. He believes that the biggest obstacle is that models are often inconsistent:

• Teams underestimate the effort required to maintain the consistency of the model.
• Companies fear that the cost of maintaining consistency is greater than the benefit.

Joachim sees the enormous potential of MBSE if everything is consistent. But that's a big "if". In practice, shortcuts are often taken. And as soon as the first "holes" appear in the model, all the effort has been wasted and the model is virtually useless.

MBSE: You see today's effort, not tomorrow's return.

Pull systems as low-hanging fruit

When asked how teams can achieve a lot with little effort, Joachim referred to his successes with Pull systems like Kanban. He points out how much friction is lost through multitasking.

Joachim gave the example of a department with 70 people. This was converted into a "black box" with a backlog, which drastically reduced employee interruptions and, after a year, the Throughput time reduced by 40% could be completed. This means that the work is still lying around for a while, but in the backlog, not on the desk. At the end of the day, decision-makers have to decide whether they want busy teams or quick results on demand: You can't have both at the same time.

Conclusion

Agile product development is possible, but it doesn't happen overnight. Joachim shared a lot of the knowledge he uses to lead companies to success.

Even though he pointed out many strategies and tactics, the biggest pivot is the human being and the potential to develop people together with the organization. And here he shared one last piece of wisdom: you can't force change, the Inviting people to change become. Because creating psychological security costs almost nothing; destroying it, however, has an enormous impact, alienates people and kills motivation. But if they are properly motivated, almost all people will embrace the changes and challenges of the future.