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\u2019t 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.<\/p>\n\n\n\n
Marc L\u00f6ffler 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\u2014just not as well as it could.<\/p>\n\n\n\n\n\n\n\n
Marc L\u00f6ffler<\/a> 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<\/a>.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s needs.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The full interview with Marc L\u00f6ffler is embedded here. Marc works as a consultant, author, and speaker on topics including leadership, retrospectives, and collaboration in technical organizations.<\/p>\n\n\n\nAn anti-pattern is more than just a bad process<\/h2>\n\n\n\n