Anti-Patterns in Systems Engineering: When Everything Is Green

At an automotive supplier, the design department is developing a window regulator. For the prototype department, it exports data in a rather unusual format. The prototype department laboriously converts the files back because it doesn’t actually need that format. Both departments believe the other has good reasons for this approach. Until someone asks and discovers that both departments actually use the same native format.

Marc Löffler shared this example during our webinar on anti-patterns in product development. The example illustrates what we often see in systems engineering: Technically competent people are working on a shared product, but at the interfaces, effort is expended without any benefit. Everything works somehow—just not as well as it could.

Marc Löffler is an author, keynote speaker, consultant, and the creator of the Watermelon Pattern. The content of this article is based on a conversation Marc and I had during a webinar. The presentation slides and other resources can be found here.

An anti-pattern is more than just a bad process

An anti-pattern is a recurring approach that produces undesirable consequences in the overall system. It can even arise from a solution that was originally a good one. The circumstances change, but the process remains the same.

The discussion, therefore, focused less on assigning blame and more on the question of why such patterns persist. In the case of the window regulator, the unnecessary file sharing is merely the visible symptom. Underlying this is a communication problem: The people involved never verified their assumptions about the other department’s needs.

In a complex development project, such assumptions often involve interfaces, approvals, testing strategies, and system architectures. A rule that makes sense in isolation can result in significant delays across multiple disciplines.

The full interview with Marc Löffler is embedded here. Marc works as a consultant, author, and speaker on topics including leadership, retrospectives, and collaboration in technical organizations.

The Watermelon Pattern: Green Until the Rough Awakening

Marc coined the term Watermelon Pattern "Greenwashed." This refers to a project that appears green on the outside but has long been red on the inside. At the team level, the difficulties are well known. The next level of management, playing it safe, reports "yellow." Higher up, this becomes "yellow-green" and ultimately an overall "green" status.

The reasons are understandable. No one wants to draw unnecessary attention to themselves. Teams hope to make up the deficit on their own. Executives may have learned that bad news means trouble. And sometimes, even management doesn’t want to take a closer look, because a red light signals the need for action.

„A green traffic light isn’t information. An honest conversation is.“

Marc Löffler

This is particularly problematic in systems engineering. A “green” status in the mechanical, electronic, and software domains does not necessarily mean the system status is “green.” The critical risks lie in the interactions. If integration occurs late in the process, those involved may not realize until then that their assumptions contradict one another.

The problem usually cannot be solved by simply increasing reporting. What’s needed is the ability to identify problems early on and someone who will act on that information. Marc repeatedly drew a connection to psychological safety. People who are punished for delivering bad news will start to cover it up.

System progress is more than just completed work packages

What metric proves that a system has actually been further developed? This question was raised by viewers during the webinar. It is extremely relevant for systems engineers because a project plan often reflects the progress of individual disciplines, while the functionality of the overall system has not yet been verified.

Marc suggested showing actual results instead of reports. A working algorithm can be demonstrated. For a physical product, early prototypes or the integration of new components into an existing system can help. But even that is only a partial answer at first: A prototype proves neither product maturity nor compliance with all requirements.

Especially when it comes to regulated products, a demonstrator must not be confused with a verified system. A device can successfully demonstrate a function and still require months of documentation, testing, or certification. During the discussion, participants therefore also warned against the „reverse watermelon pattern“: Management sees something that works and prematurely considers development complete.

This presents a dilemma for project management: Progress must be visible on multiple levels: Which functions are running in the integrated system? Which requirements have been verified through robust testing? What evidence is still needed for approval? A single traffic-light color cannot capture these differences.

Traceability: Complete Links, Incomplete Knowledge

A clear-cut special case is Traceability. A project may report that all requirements are linked to test cases. This is a clear and easily measurable figure. However, it does not indicate whether the links are correct, whether the tests match the current state of the system, or whether the relevant system functions have actually been verified.

I've already discussed this issue in the post Why do we ignore the quality of traceability? described. Among other things, it explains that traceability deteriorates when changes are made if the links are not maintained. What appears to be complete traceability can thus create a false sense of security.

The webinar discussed a medical technology context in which traceability and test cases were automatically prepared for testing. The main focus is on keeping this documentation up to date throughout the development process. If tests, requirements, and implementation are linked together during development, the verification process won’t suddenly come out of nowhere just before certification.

However, automation alone does not solve the problem. An automatically updated link is not necessarily a correct link. Systems engineering must therefore verify the relationship between artifacts and the quality of the evidence. That is exactly what reviews and technical integration are for.

Good metrics start with the problem

Marc came up with a provocative rule of thumb:

„If a metric is easy to improve, it's usually not a good metric.“

Marc Löffler

This isn't true in every case. But it explains why organizations tend to track what their tools already provide: closed tickets, written requirements, story points, or completed reviews. These numbers reflect activity. Whether that activity has actually moved the overall system forward remains to be seen.

For a specific development organization, other questions would be more revealing:

• Lead Time: How much time elapses between a new customer requirement and a verifiable change to the product?
• Integration delay: How long does it take for a modified component to be tested in the entire system?
• Questions and Handoffs: How many organizational steps does a technical problem go through before a decision can be made?
• Working in parallel: How many projects or changes are competing for the same specialists and testing facilities at the same time?

None of these metrics is automatically a good one. You have to know which problem you’re trying to address with them. A project that suffers from late integration gains little from counting requirements more precisely. And a team with lengthy decision-making processes won’t become faster just by categorizing its tickets in greater detail.

Collecting this data can be tedious because the start and end points are often located in different systems. It is precisely this gap between the tools that shows how little oversight there has been of the entire development workflow to date.

Early integration also means early collaboration

Marc talked about a project at the Erbe, a medical technology company. Among others, production planners were involved in the development teams from an early stage. The mechanical and software components were developed in tandem until the next major handoff. Issues related to manufacturing or packaging could be addressed as early as the development phase.

This is a practical example of a problem that systems engineers have long been familiar with. Errors at cross-disciplinary interfaces are difficult to detect as long as each discipline evaluates its own subproduct. The organizational interface is therefore just as relevant as the technical one (Conway's Law).

This also includes the Compliance. During the conversation, Marc described a project in the banking sector in which a cybersecurity officer was involved from the outset of implementation. This allowed regulatory issues to be clarified directly, rather than addressing them at the end as an additional approval step. This can reduce wait times.

For systems engineers, this raises specific questions about the project: When will we see an integrated system for the first time? Who will verify that the interface assumptions are consistent? Are manufacturing, verification, and certification involved early enough to still influence the design?

Diagnosis Before Taking Action

The most dangerous response to an identified anti-pattern is a one-size-fits-all solution. If approval takes too long, you can reduce the number of signatures required. Maybe that will solve a problem. But maybe it just masks the fact that responsibilities are unclear or that no one knows which risks actually need to be assessed.

The same anti-pattern can have different causes. Delayed integration, for example, can result from a lack of testing capabilities, incompatible interfaces, or organizational structures in which no one is responsible for system integration. Each cause requires a tailored solution.

Marc recommended holding regular retrospectives. The point isn’t to come up with as many improvement measures as possible. What’s interesting are situations that keep recurring. If an interface causes problems during integration for the third time, it’s worth asking what assumption or working method is behind it.

I found Marc's recommendation to also conduct such retrospectives in large projects particularly interesting across teams to be conducted, for example, every three months. Local retrospectives are useful. However, if the problem lies between teams, the reflection must also extend beyond team boundaries.

One helpful tool is the Product Velocity Anti-Pattern Finder. He suggests possible patterns based on a few questions. The result is a starting point for further investigation—not an automatic diagnosis, and certainly not a ready-made action plan. I had already discussed this approach in a previous SE Trends post written.

Conclusion

In systems engineering, anti-patterns are rarely spectacular. A redundant file format, an approval process with no apparent justification, or a “green” project traffic light are, in and of themselves, minor observations. They become costly when the same mechanism persists across many interfaces and problems only become apparent during integration.

In practice, therefore, I would start with a question: What problem have we identified repeatedly over the past few months, even though each discipline involved considered its work to be complete? The answer often leads to an assumption that has never been verified across disciplines.

Systems engineering is tasked with focusing on the system as a whole. This involves scrutinizing the quality of supporting documentation, integrating system functions early on, and making progress visible across disciplinary boundaries. When the traffic light turns red, it’s an opportunity to take action in a timely manner.