Funktioniert Scrum auch auf der Baustelle oder im Maschinenbau?

Die Frage, ob agile Methoden wie Scrum jenseits der Softwareentwicklung – im Maschinenbau, auf der Baustelle oder in der Produktion – überhaupt funktionieren können, beschäftigt viele Projektleiter in klassischen deutschen Industrien. Der Druck, schneller und flexibler auf Marktveränderungen zu reagieren, wächst stetig. Gleichzeitig sind die Realitäten der physischen Produktentwicklung geprägt von langen Vorlaufzeiten für Materialien, festen regulatorischen Anforderungen (z.B. durch den TÜV) und dem berechtigten Bedürfnis nach verlässlicher Planung und stabilen Budgets.

Oft wird die Diskussion auf eine falsche Dichotomie reduziert: das starre, aber planbare Wasserfallmodell versus das flexible, aber vermeintlich chaotische Scrum. Man hört Ratschläge wie „Man muss die Rollen des Product Owners und Scrum Masters einführen“ oder „Kanban ist für Hardware besser geeignet“. Diese Ansätze kratzen jedoch nur an der Oberfläche und ignorieren die tiefere, kulturelle und prozessuale Ebene. Sie führen oft zu Frustration, da die neuen Methoden auf die alten, unveränderten Strukturen prallen.

Aber was wäre, wenn die wahre Lösung nicht im Ersetzen, sondern im intelligenten Integrieren liegt? Was, wenn Agilität nicht als neue, starre Methodik, sondern als ein Satz von Prinzipien verstanden wird, die als Prozess-Katalysator für Ihre bewährten Abläufe dienen? Dieser Artikel bricht mit der „Alles-oder-Nichts“-Logik. Er zeigt Ihnen pragmatische Wege auf, wie Sie die Stabilität traditioneller Projektplanung mit der Anpassungsfähigkeit agiler Praktiken kombinieren können. Es geht nicht darum, Scrum dogmatisch zu implementieren, sondern darum, Ihr Unternehmen durch gezielte, hybride Ansätze widerstandsfähiger und krisenfester zu machen.

Wir werden uns konkreten, praxisnahen Fragen widmen, die Sie als Projektleiter im Tagesgeschäft bewegen. Von der Wahl der passenden Methode über die Gestaltung von Festpreisverträgen bis hin zur Koordination mehrerer Teams – dieser Leitfaden bietet Ihnen erprobte Strategien für den deutschen Mittelstand.

Welche Methode passt besser zur Instandhaltung oder Produktion?

Die Wahl der „richtigen“ agilen Methode ist keine Glaubensfrage, sondern eine Frage des Kontexts. Während Studien zeigen, dass in der agilen Transformation 81% der deutschen Industrieunternehmen auf Scrum setzen, ist es für Bereiche wie Instandhaltung oder Serienproduktion oft nicht die beste Wahl. Der Grund liegt in der Natur der Arbeit: Scrum ist für die Entwicklung neuer, komplexer Produkt-Inkremente in festen Zyklen (Sprints) optimiert. Instandhaltung und Produktion sind hingegen oft von einem kontinuierlichen Fluss unvorhersehbarer Aufgaben geprägt.

Hier spielt Kanban seine Stärken aus. Anstatt in festen Sprints zu planen, konzentriert sich Kanban auf die Visualisierung des Arbeitsflusses und die Begrenzung der gleichzeitig laufenden Aufgaben (Work-in-Progress-Limit). Dies macht Engpässe sofort sichtbar und optimiert den Durchsatz. Ein Team kann eine dringende Reparatur sofort beginnen, ohne auf den nächsten Sprint-Start warten zu müssen. Das Ziel ist nicht, eine bestimmte Menge Arbeit in zwei Wochen zu schaffen, sondern den Fluss der Aufgaben so reibungslos wie möglich zu gestalten.

Ein hervorragendes Beispiel aus dem deutschen Maschinenbau ist die Gerd Mosca AG. Durch die Einführung von Kanban-Systemen direkt an der Produktionslinie konnte das Unternehmen die Materialverfügbarkeit signifikant steigern. Wie in ihrer Fallstudie zur Prozessoptimierung beschrieben, führte dies nicht nur zu einer Reduzierung der Lageroperationen, sondern auch zu mehr Ordnung und Übersichtlichkeit. Für projektbasierte Neuentwicklungen bleibt Scrum oft das Mittel der Wahl, aber für prozessorientierte Abläufe ist Kanban der pragmatischere Ansatz.

Letztlich geht es darum, die Methode an den Prozess anzupassen und nicht umgekehrt. Eine hybride Landschaft, in der Entwicklungsteams mit Scrum und Produktionsteams mit Kanban arbeiten, ist oft die effektivste Lösung.

Wie vereinbaren Sie Festpreise, wenn der Projektumfang flexibel ist?

Die Sorge, dass Agilität unweigerlich zu explodierenden Kosten führt, ist einer der größten Hemmschuhe im Maschinenbau. Der klassische Festpreisvertrag scheint unvereinbar mit dem agilen Prinzip des flexiblen Umfangs. Doch dieser Widerspruch lässt sich durch intelligentes Puffermanagement und hybride Vertragsmodelle auflösen. Anstatt den gesamten Projektumfang von Anfang an festzuschreiben, definieren Sie einen klar abgegrenzten Kernumfang.

Dieser Kernumfang (ca. 60-70 % des erwarteten Gesamtprojekts) enthält alle „Must-have“-Features und wird zu einem festen Preis vereinbart. Für die restlichen 30-40 %, die „Should-have“- und „Could-have“-Features, wird ein separates, budgetiertes Änderungskontingent eingerichtet. Jede Änderung oder jedes zusätzliche Feature, das aus diesem Puffer finanziert wird, muss transparent priorisiert und vom Auftraggeber freigegeben werden. So behält der Kunde die volle Kostenkontrolle, während das Projektteam die Flexibilität behält, auf neue Erkenntnisse zu reagieren.

Die Visualisierung dieses Modells hilft, die Struktur klar zu kommunizieren: Ein solider Kern mit einem flexiblen, aber kontrollierten Rahmen.

Wie in Fachmedien für die Produktentwicklung hervorgehoben wird, basiert dieses Modell auf wertorientierten Meilensteinen. Die Bezahlung ist nicht an den Abschluss vager Phasen gekoppelt, sondern an die Lieferung funktionierender und werthaltiger Produkt-Inkremente. Dies schafft Vertrauen und stellt sicher, dass der Kunde für tatsächlichen Fortschritt bezahlt. Wichtige Schritte für solche Verträge sind:

• Definition eines festen Kernumfangs für 60-70% des Projekts.
• Einrichtung eines budgetierten Änderungskontingents als Puffer (20-30%).
• Vereinbarung von Zahlungsmeilensteinen, die an die Lieferung von Mehrwert gekoppelt sind.
• Implementierung transparenter Prozesse für die Genehmigung von Scope-Änderungen.
• Regelmäßige Review-Zyklen zur gemeinsamen Überprüfung von Budget und Fortschritt.

Dieses Vorgehen transformiert die Vertragsbeziehung von einer konfrontativen zu einer partnerschaftlichen. Beide Seiten haben ein gemeinsames Interesse daran, mit dem verfügbaren Budget den maximalen Wert zu schaffen.

Wie kombinieren Sie Wasserfall-Meilensteine mit agilen Sprints?

Der Versuch, ein etabliertes Wasserfall-System radikal durch Scrum zu ersetzen, ist in der Hardware-Entwicklung meist zum Scheitern verurteilt. Zu tief sind externe Abhängigkeiten, Zertifizierungsprozesse und Lieferketten in Phasen und Meilensteine eingebettet. Die Lösung liegt in der Schaffung einer hybriden Stabilität, bei der die übergeordnete Projektstruktur dem Wasserfall folgt, die eigentliche Entwicklungsarbeit aber in agilen Sprints organisiert wird.

Stellen Sie sich ein Projekt zur Entwicklung einer neuen Maschine vor. Der Gesamtplan könnte klassische Meilensteine wie „Konzept-Freigabe“ (M1), „Prototyp-Fertigstellung“ (M2) und „Serienfreigabe“ (M3) enthalten. Innerhalb der Phasen zwischen diesen Meilensteinen arbeiten die Teams (z. B. Mechanik, Elektrik, Software) jedoch in zweiwöchigen Sprints. Am Ende jedes Sprints findet ein gemeinsames Review statt, bei dem nicht nur die Software, sondern auch Simulationsergebnisse, CAD-Modelle oder erste Bauteile demonstriert werden. Diese Reviews dienen als Mini-Meilensteine, die das Risiko reduzieren und sicherstellen, dass alle Gewerke synchronisiert bleiben.

Ein hybrider Ansatz ermöglicht es, die Stärken beider Welten zu nutzen, wie die folgende Gegenüberstellung verdeutlicht.

So werden die Wasserfall-Meilensteine von gefürchteten Deadlines zu sinnvollen Integrationspunkten, die auf den Ergebnissen mehrerer Sprints aufbauen. Das Management behält seine gewohnten Kontrollpunkte, während die Entwicklungsteams die nötige Flexibilität für ihre Arbeit gewinnen.

Wer entscheidet im Maschinenbau über die Priorität der Features?

In der agilen Softwarewelt ist die Antwort klar: der Product Owner. Im Maschinenbau ist die Realität komplexer. Die Entscheidung über die Priorität eines Features hat oft weitreichende Konsequenzen für Mechanik, Elektrik, Software und sogar den Einkauf. Ein einzelner Product Owner kann diese Komplexität kaum überblicken. Statt diese Rolle künstlich zu erzwingen, hat sich in der Praxis ein Triumvirat aus Fachexperten bewährt.

Dieses Gremium besteht typischerweise aus einem Produktmanager (der die Stimme des Kunden und des Marktes vertritt), einem Chefingenieur oder Systemarchitekten (der die technische Machbarkeit und Integrität verantwortet) und dem Projektleiter (der Zeit und Budget im Blick hat). Diese drei Rollen entscheiden gemeinsam über die Prioritäten im Product Backlog. Dies stellt sicher, dass jede Entscheidung sowohl kundenorientiert, technisch fundiert als auch wirtschaftlich sinnvoll ist. Das oberste Ziel ist dabei stets die Maximierung der Kundenzufriedenheit, ein Bereich, in dem laut einer Studie von CA Technologies 84% der deutschen Unternehmen mit agilen Methoden Verbesserungen erzielen konnten.

Um die Entscheidungen dieses Triumvirats zu objektivieren, können etablierte Frameworks wie das Kano-Modell helfen, Features zu klassifizieren und zu priorisieren:

• Basis-Features: Technische Mindestanforderungen, die als selbstverständlich angesehen werden. Ihre Abwesenheit führt zu Unzufriedenheit.
• Leistungs-Features: Je mehr davon, desto zufriedener der Kunde (z.B. höhere Geschwindigkeit, geringerer Energieverbrauch).
• Begeisterungs-Features: Unerwartete Innovationen, die einen hohen Differenzierungswert haben und für echte Begeisterung sorgen.
• Cost of Delay (Verzögerungskosten): Eine mächtige Metrik, die den wöchentlichen oder monatlichen Verlust quantifiziert, der entsteht, wenn ein Feature *nicht* ausgeliefert wird.

Durch die Kombination aus einem Expertengremium und einem datengestützten Priorisierungs-Framework werden Bauchentscheidungen vermieden und sichergestellt, dass die knappen Entwicklungsressourcen stets an den wertvollsten Features arbeiten.

Wie koordinieren Sie 10 agile Teams, die an einem Produkt arbeiten (SAFe/LeSS)?

Sobald mehr als eine Handvoll Teams an einem einzigen Produkt – wie einer komplexen Anlage oder einem Fahrzeug – arbeiten, stoßen einfache Scrum-Methoden an ihre Grenzen. Die Koordination zwischen den Teams wird zur größten Herausforderung. Hier kommen Skalierungsframeworks wie SAFe (Scaled Agile Framework) oder LeSS (Large-Scale Scrum) ins Spiel. Doch anstatt diese riesigen Regelwerke dogmatisch zu übernehmen, sollten sie als eine Art „Rezeptbuch“ betrachtet werden, aus dem man sich die passenden Zutaten für das eigene Unternehmen herauspickt.

Ein zentrales und äußerst wirksames Element aus SAFe ist das PI (Program Increment) Planning. Bei diesem meist zweitägigen Event kommen Vertreter aller (!) beteiligten Teams, das Management und andere Stakeholder zusammen. Gemeinsam planen sie die Arbeit für das nächste Quartal (das „Program Increment“). Abhängigkeiten zwischen den Teams werden auf einem großen „Program Board“ visualisiert und direkt besprochen. Dieses Event schafft ein unschätzbares gemeinsames Verständnis und eine Verbindlichkeit, die per E-Mail oder in separaten Meetings niemals erreicht werden könnte.

Die Erfahrung aus dem deutschen Mittelstand, wie bei der Athmer Gruppe, zeigt, dass eine schrittweise Einführung solcher Praktiken der Schlüssel zum Erfolg ist. Maico Ludwig, Entwicklungsleiter bei Athmer, begann bereits vor über fünf Jahren mit der Einführung von Scrum im Maschinenbau und skalierte die Prozesse über die Zeit. Anstatt SAFe komplett zu implementieren, wurden Elemente wie das PI Planning adaptiert, um die teamübergreifende Koordination zu verbessern. Der Fokus liegt auf der Förderung der direkten Kommunikation zwischen den Teams, anstatt neue Hierarchieebenen durch „Release Train Engineers“ oder andere Rollen einzuführen.

Der wichtigste Grundsatz bei der Skalierung ist: Fördern Sie die dezentrale Entscheidungsfindung und die direkte Zusammenarbeit der Teams. Ein Framework ist nur ein Hilfsmittel, kein Ersatz für eine Kultur des Vertrauens und der Kommunikation.

Wie kombinieren Sie Stabilität und Flexibilität im deutschen Markt?

Der deutsche Markt, insbesondere der „Mittelstand“, ist geprägt von einem hohen Qualitätsanspruch, der oft durch Zertifizierungen wie ISO 9001 untermauert wird. Diese Prozesse stehen im Ruf, bürokratisch und starr zu sein – das genaue Gegenteil von Agilität. Doch dies ist ein Trugschluss. Richtig verstanden, sind agile Prinzipien und die Anforderungen der ISO 9001 zwei Seiten derselben Medaille: der kontinuierlichen Verbesserung.

Der in der ISO 9001 geforderte PDCA-Zyklus (Plan-Do-Check-Act) findet sein direktes agiles Äquivalent in den Sprint-Zyklen von Scrum. Die Sprint-Retrospektive ist nichts anderes als ein institutionalisierter „Check-Act“-Workshop. Agile Praktiken können die Anforderungen der ISO 9001 sogar lebendiger und wirksamer machen. Anstatt Prozessbeschreibungen zu erstellen, die in einem Ordner verstauben, wird die „Definition of Done“ zu einer lebenden, vom Team getragenen Qualitätsdokumentation. Anstatt auf jährliche Audits zu warten, validieren die Sprint Reviews die Produktqualität kontinuierlich mit dem Kunden.

Die wachsende Beliebtheit dieses Ansatzes zeigt auch die PMI Global Survey 2024: Der Anteil der Projekte, die hybride Methoden nutzen, ist signifikant gestiegen. Laut einer Analyse der Umfrage werden bereits 31,5% der Projekte im Jahr 2023 hybrid gemanagt. Die Synergie zwischen Qualitätsmanagement-Normen und agilen Arbeitsweisen ist ein starker Hebel für diese Entwicklung.

Die folgende Tabelle zeigt, wie agile Praktiken die klassischen ISO 9001-Anforderungen konkret umsetzen und bereichern:

Indem Sie Agilität als Werkzeug zur Erfüllung Ihrer Qualitätsversprechen nutzen, schaffen Sie eine Kultur, die sowohl robust als auch anpassungsfähig ist – eine entscheidende Fähigkeit im volatilen globalen Markt.

Warum Verschwendung in Prozessen oft unsichtbar ist

Im Lean Management ist das Konzept der „Muda“ (Verschwendung) zentral. Im Kontext des deutschen Maschinenbaus sind diese Verschwendungsarten jedoch oft schwer zu erkennen, da sie sich hinter etablierten Prozessen oder sogar einer als Tugend empfundenen Gründlichkeit verbergen. Das typische deutsche „Over-Engineering“ ist ein perfektes Beispiel für die Verschwendungsart „Überbearbeitung“. Man entwickelt ein Feature nicht nur gut, sondern perfekt – obwohl der Kunde diesen Perfektionsgrad nie gefordert hat und nicht bereit ist, dafür zu zahlen.

Agile Methoden, insbesondere visuelle Werkzeuge wie Kanban-Boards, machen diese unsichtbare Verschwendung gnadenlos sichtbar. Wenn eine Aufgabe wochenlang in der Spalte „Warten auf ERP-Freigabe“ hängt, wird die Verschwendung durch Wartezeit für jeden offensichtlich. Wenn das Backlog voller Features ist, die vor Monaten entwickelt, aber nie ausgeliefert wurden, visualisiert dies die Überproduktion – nicht nur von physischen Teilen, sondern auch von digitalem Code.

Die Kunst besteht darin, die klassischen sieben Arten der Verschwendung neu zu interpretieren und auf die spezifischen Gegebenheiten der Engineering- und Verwaltungsprozesse zu übertragen. Eine Audit-Checkliste kann dabei helfen, die eigenen Abläufe kritisch zu hinterfragen.

Durch diese agil-inspirierte Perspektive wird Verschwendung von einem abstrakten Konzept zu einem konkreten, messbaren Problem, das systematisch angegangen werden kann.

Wie macht eine agile Strategie Ihr Unternehmen in 6 Monaten krisenfest?

Krisenfestigkeit, oder Resilienz, ist die Fähigkeit eines Unternehmens, auf unvorhergesehene Schocks – sei es eine Lieferkettenunterbrechung, ein plötzlicher Technologiewandel oder eine globale Pandemie – schnell und effektiv zu reagieren. Eine agile Strategie baut diese Fähigkeit systematisch auf, und die Effekte können sich bereits innerhalb von sechs Monaten zeigen. Der Kern der agilen Resilienz liegt in zwei Aspekten: verkürzte Feedback-Zyklen und radikale Transparenz.

Kurze Zyklen (wie zweiwöchige Sprints) zwingen ein Unternehmen, seine Pläne ständig mit der Realität abzugleichen. Anstatt ein Jahr lang an einer Maschine zu entwickeln und am Ende festzustellen, dass sich der Markt geändert hat, erhält man alle zwei Wochen Feedback. Dies ermöglicht eine schnelle Kurskorrektur. Siemens beispielsweise konnte durch den Einsatz von vorausschauender Analyse und agilen Daten-Teams die Maschinenstillstände um bis zu 35% reduzieren – ein konkretes Beispiel für Krisenprävention durch das frühzeitige Erkennen von Problemen.

Gleichzeitig schafft die Transparenz durch Tools wie Kanban-Boards ein Frühwarnsystem für die gesamte Organisation. Engpässe in der Produktion oder Blockaden in der Lieferkette werden sofort für alle sichtbar, nicht erst, wenn es zu spät ist. Ein eindrucksvolles Praxisbeispiel aus der Automobilindustrie zeigt, wie durch die Einführung eines „Internet-Kanban“-Systems zur Lieferkettensteuerung die Bestände um 60 Prozent und der Dispositionsaufwand um 75 Prozent reduziert werden konnten. Fast alle Expressaufträge, die zuvor die Regel waren, konnten eliminiert werden. Dies ist ein Beleg dafür, wie schnell sich eine Organisation durch agile Optimierung stabilisieren kann.

Beginnen Sie nicht mit einer Revolution, die das gesamte Unternehmen lahmlegt. Starten Sie mit einem einzelnen, kritischen Prozess. Machen Sie die Arbeit und ihre Engpässe sichtbar und beweisen Sie den Wert agiler Prinzipien schrittweise. So bauen Sie Resilienz von innen heraus auf – pragmatisch, wirkungsvoll und nachhaltig.