FrankSazama- Technik
Mehrere Lösungen werden erprobt
Es wurden parallel zwei unterschiedliche Lösungsansätze A und B für die Erkennung des Top-Fehlers erarbeitet. Beide Ansätze werden bewusst auf unterschiedliche Art und Weise umgesetzt. Sie verwenden die Sensorik, die bereits in der Anlage des Lead-Kunden existiert.
Parallel arbeitet das Kern-Team vorauseilend daran, den Einsatz zusätzlicher Sensorik zu betrachten und erhält dabei kontinuierlich Feedback aus der Erprobung und dem Vergleich der Lösungen A und B beim Lead-Kunden.
Sollte ein Lösungsansatz in die „Sackgasse“ führen, wählt das Kern-Team einen weiteren Ansatz zur Umsetzung und Erprobung aus.
- Organisation
Erste sichtbare Skalierung in der Organisation
Eine weiterführende Idee ist hier, dass die beiden, möglichst unabhängigen Teams, durch unterschiedliche Herangehensweisen zu unterschiedlichen Lösungsansätzen kommen werden. Alle Teams aber werden in ihrem Ablauf nach Scrum arbeiten und einem synchronen Rhythmus von 2 Wochen-Sprints folgen.
Die beiden neuen Software-fokussierten Teams haben alle notwendigen Kompetenzen in ihrer Domäne: Sie verantworten die jeweilige (Software-) Architektur, haben Design-Hoheit, setzen die Implementierung um und führen notwendige Tests durch.
Kern-Team
- keine Änderungen in der Zusammenstellung
- der Product Owner ist und bleibt der Gesamtverantwortliche für die Produktentwicklung
- die beiden Software-Entwickler aus dem Kern-Team erhalten jeweils eine Doppelrolle, sie übernehmen zusätzlich die Verantwortung des „Feature“ Owners (eine Teil- Verantwortlichkeit der eigentlichen Product Owner Rolle) in den neuen Software-Teams
- der Scrum Master wird nun „Core“ Scrum Master und leitet die Scrum Master der beiden neuen Teams an
Software-Teams
- Die zwei neuen Software-Teams decken (jeweils) folgende Befähigungen ab:
- Software- und/oder Firmware-Entwicklung
- entsprechende Testausführung und -automatisierung
- ggfs. ist enge Zusammenarbeit mit den Betriebsfunktionen des Leadkunden notwendig
- die zwei neuen Scrum Master werden firmenintern besetzt, alles weitere dazu im Tab „agile Aspekte (Erkenntnisse)“
- Geschäftsmodell
Keine Änderungen am Geschäftsmodell
… alles bleibt wie es ist …
- Agile Aspekte (Erkenntnisse)
Eine neue Epoche für die agile Organisation – vom Single zum Multi-Team
Seit klar ist, dass der Umfang der „Plant-Watcher“-Entwicklung deutlich erweitert werden muss, hat der agile Coach wieder alle Hände voll zu tun. Zwei Software-Teams sollen neben dem Kern-Team auf der Basis agiler Prinzipien, Werte und Vorgehensweisen etabliert werden.
Wären die neuen Teams unabhängig, also mit einer jeweils anderen Produktentwicklung beschäftigt, wäre der Prozess des Aufbaus und der Etablierung sehr ähnlich zum Vorgehen des Kern-Teams. Nun sind aber drei Teams in einem Entwicklungsverbund und damit auch die übergreifenden Interaktionen zu berücksichtigen. Der agile Coach begleitet die Mitglieder des Kern-Teams und erste neue Kollegen der beiden zukünftigen SW-Teams bei einem Entscheidungsprozess über die teamübergreifende Zusammenarbeit. Dabei stellt er verschiedene Möglichkeiten zur Auswahl, die sich vor allem im Ablauf aber auch in ihren Strukturen, Rollen und der Verteilung von Verantwortung unterscheiden.
Die Entscheidung fällt auf eine Herangehensweise, die beiden bisherigen Software-Entwicklern im Kern-Team eine deutlich veränderte Verantwortung zukommen lässt. Sie übernehmen zusätzlich die Rolle des sog. Feature Owner der jeweiligen Software-Teams, damit übernehmen sie Führungsverantwortung und werden Bindeglied zwischen dem Kern-Team und ihrem jeweiligen Software-Team. So wird sichergestellt, dass die bisher gewonnen Erfahrungen weitergeben werden können und neue, lokale Erkenntnisse in der Systementwicklung berücksichtigt werden. Ein Feature Owner agiert basierend auf der gleichen Perspektive wie ein Product Owner hat aber nur eine Teilverantwortung innerhalb der Produktentwicklung – in unserem Beispiel die Verantwortung für die Entwicklung einer Lösungsvariante.
Auch der Scrum Master des Kern-Teams (ab jetzt Core-Scrum Master) bekommt eine erweiterte Verantwortung und eine Doppelrolle. Er ist jetzt nicht nur verantwortlich für Fähigkeiten des weiter bestehenden Kern-Teams, sondern auch für die Fähigkeiten des gesamten Entwicklungsverbundes bestehend aus drei Teams. D.h. seine neue Rolle schließt auch die Einarbeitung, Führung und Unterstützung der neuen Scrum Master mit ein, er wird dabei anfänglich durch den agilen Coach begleitet. Weiter bleibt die Verbindung vom Core-Scrum Master zu einem Supporting Leader erhalten, allerdings sollte dessen Autorität überprüft werden. Ein Abteilungsleiter, dessen Autorität zu Beginn hinreichend war, könnte jetzt schon einen zu geringen Schutz des neuen Entwicklungsverbundes sicherstellen.
Der Auswahlprozess für die beiden neuen Scrum Master gestaltete sich anfangs nicht gerade einfach, denn ein Scrum Master sollte kein typischer Vertreter einer technischen Rolle sein, vielmehr ist ein Kompetenzprofil sehr ähnlich zu einem Teamleiter notwendig, um die (Leistungs-)Fähigkeiten im Team zu bewerten, zu analysieren und zu entwickeln. Die Rolle des Scrum Master sollte ja auch nicht nur administrativ, sondern mit entsprechender Verantwortung interpretiert werden. Damit stand die Rolle eines Scrum Master aber in direkter Konkurrenz zu den noch vorhandenen und etablierten Teamleitern. Ein Kompromiss wurde gefunden, eine Lösung die sowohl die vormalrechtliche formalrechtliche als auch die neu interpretierte Verantwortung und die Entwicklungsmöglichkeiten der Scrum Master berücksichtigte. Die Ausbildung zum Scrum Master wurden zu einem Teil eines neuen Trainee-Programms für Führungskräfte und die bisherigen Teamleiter wurden zum persönlichen Coach in Situationen, die durch Methoden der klassischen Führung gelöst werden konnten und tragen die formalrechtliche Verantwortung sowohl für die Scrum Master als auch für das jeweilige Scrum Team. Alternative und ergänzende Methoden und damit die agile Perspektive, wurde durch den Agile Coach übernommen. So wurde das Ziel dieses Trainee-Programms und ein gegenseitiges Verständnis beider Ansätze erreicht und gleichzeitig ein modernes Führungsverhalten entwickelt, das beide Ansprüche in sich vereint. Eine sehr bewusste Keimzelle für die Führung eines modernen Unternehmens von morgen.
Der Product Owner behält seine Rolle, seine Verantwortung bleibt im Grundsatz erhalten, er wird jetzt aber durch die Feature Owner, deren Teams und der Mitglieder im Kern-Team in der Umsetzung unterstützt.
Fazit:
Organisatorisch gut aufgestellt – technische Herausforderungen folgen
Organisatorisch haben sich die Beteiligten sehr gut entwickelt. Durch Reflektion und Adaption haben sie nicht nur zu jeweils einzelnen Teams sondern auch zu einem Team-Verbund zusammengefunden. Core Scrum Master, Scrum Master und Agile Coach haben eine gut funktionierende Einheit auf Basis agiler Prinzipien geformt. Technisch hat sich noch keine eindeutige Lösung ergeben und so erwarten die Teams die nächsten Herausforderungen.