Ein Reifegradmodell oder doch schon Scrum?

In einer meiner früheren Aufgaben war ich für einen Entwicklungsbereich in einem internationalen Konzern verantwortlich. Kernaufgabe war die Entwicklung neuer Plattformen eines Halbleiterprodukts, insbesondere des Halbleiterprozesses.

 Als ich diese Funktion neu übernommen habe, bestand der Entwicklungsbereich aus verschiedenen Abteilungen, die in fest zementierten Silos vor sich hin entwickelten. Zu den Nachbarbereichen in der Vorserienfertigung und dem Facility Management wurden gefühlt noch höheren Mauern kultiviert.

Dies wurde wohl bereits schon länger so kultiviert, denn die Ergebnisse der Entwicklung konnten, Rückblickend, in der Vorserienfertigung nicht reproduziert werden. Performance Einbrüche und damit deutliche Rückschritte bei der Produktentwicklung waren an der Tagesordnung.

 Kurz vor meiner Aufgabenübernahme wurde zudem das erste „agile“ Kundenprojekt in einer solchen Umgebung aufgesetzt. Scrum war das Zauberwort. Es gab aber – vor ca. 10 Jahren – nicht wirklich viel Erfahrung mit Scrum in Hardware Projekten. Das Projektteam war damals organisatorisch ein quasi klassisches Projekt mit doppelter Projektleitungsspitze. Aber es wurde auch „Scrum“ gemacht…

 Aufgrund dieser Umgebung setzte ich die Entwicklung organisatorisch neu auf. Eine bestehende Strukturierung der Halbleiterprozessentwicklung nutzend, entsann ich ein Reifegradmodell. Dabei war für mich folgendes wichtig:

• alle Teams mussten crossfunktional besetzt sein. Entwickler und Mitarbeitende der Vorserienfertigung waren die Mindestbesetzung, dazu oft noch Facility Management und Einkauf.
• Alle Teams mussten Tafeln haben, auf denen der aktuelle Entwicklungsstand ständig abzulesen war.
• Alle Teams hatten ein Daily.
• Es gab kurze wöchentliche Gesamtdarstellungen der Reifegradentwicklung, der in zehn Stufen unterteilt war.
• Alle vier Wochen gab es einen Reviewtermin für jedes Team. Das Inkrement war die Reifegradsteigerung.
• Die Gruppenleiter hatten in der Regel die Funktion des Product Owners, sie standen in engem Kontakt zum Kundenprojekt.
• Ich selbst übernahm die Rolle des „Scrum Masters“ im „Team of Scrums“ und kümmerte mich darum, dass die Teams reibungslos miteinander arbeiten konnten. Dazu wurde in der Organisation meine Zuständigkeit in Form einer Doppelspitze für die Vorserie erweitert. Wir führten auch eine Art Retrospektive ein, um die vielen historischen Barrieren in der Zusammenarbeit aus dem Weg zu räumen.

Dieses Projekt schaffte mit dieser veränderten Arbeitsweise ein ganz neues Erfolgserlebnis. Zum ersten Mal in der Geschichte des Unternehmens konnte ein Performancegewinn des Halbleiterdevices beim Übergang in die Vorserienfertigung erzielt werden. Und das bei einer Ontime +2%. In Betracht der hohen Komplexität einer weitgehend neuen Fertigung und eines komplett neu gebauten Entwicklungslabors eine sehr gute Leistung.

Kritische Betrachtung

Aus Sicht der vielen Erfahrung mit Scrum zum heutigen Zeitpunkt gab es damals doch noch einiges an Improvisation, keine sauber getrennten Verantwortlichkeiten von Linie und PO und SM. Die Events waren noch nicht sauber aufgesetzt, die Teams kaum mit Scrum vertraut. Der größte Mangel betrifft sicher die Artefakte, die nicht bzw. nur sehr rudimentär vorhanden waren.

Fazit

Trotzdem hat das Projekt sehr gut geklappt, es wurde mit viel Erfahrung mit PDCA basierten Veränderungsprojekten und mit Prozessoptimierung aufgesetzt. Die Teams fanden sehr schnell eine sehr gute Kommunikationsbasis. Die Transparenz war kurz nach dieser Projekttransformation hoch.

Spiegele ich die Werte und Prinzipien von Scrum an diesem vorgehen, finde ich sehr vieles wieder was zum Erfolg beigetragen hat:

• Transparenz
• Mut
• Fokus
• Commitment
• Die Offenheit musste in Laufe der Arbeit erst errungen werden

Dazu zählen auch viele agile Prinzipien, die ich rückblickend identifiziere kann. Gerade die Prinzipien sind handlungsleitend. Hier sind die wichtigsten die wir umgesetzt haben:

– Transparenz vor Geheimnissen
– Unterstützende Führung
– Talente vor Titel
– Vertrauen vor Kontrolle
– Abliefern vor Planung
– Netzwerke vor Hierarchie

Daraus entstand ein Vertrauen und eine wirklich gute Zusammenarbeit über die einstigen Grenzen der Abteilungen und Bereiche hinweg.

Es war vielleicht nach den Regeln der Kunst kein Scrum Vorzeigeprojekt – oder etwa doch, wenn wir insbesondere das Mindset betrachten. Für mich war es ein gelungenes Scrumbut Projekt.

Viele der hier beschriebenen Vorgehensweisen wurde aus meinem Erfahrungsschatz und dem meines Teams heraus vorgeschlagen und umgesetzt. Das Vorgehen basierte auf Empirie und Iteration. Das selbe Fundament, wie es auch Scrum fürsich in Anspruch nimmt…

Wie seht Ihr das? Muß ich immer Scrum nach Vorschrift machen oder geht agil auch anders?