Praxisbeispiel

Plant Watcher

Fiktives Beispiel einer agilen Produktentwicklung aus dem industriellen Umfeld

Vorbemerkung

Die Digitalisierung von Produktionsstätten stellt sowohl Betreiber und Integratoren als auch Ausrüster vor große Herausforderungen: Projekte in diesem Umfeld sind häufig nicht mehr kompliziert, sondern komplex.  Diese Komplexität  der Entwicklung eines solchen Projektes ändern sich technische Aspekte, Vorgehensweisen, Organisationsstrukturen und möglicherweise auch das komplette Geschäftsmodell. Obendrein sollen neue Lösungen schnell und kontinuierlich in den Markt ausgerollt werden.

Anhand eines fiktiven aber durchaus sehr praxisnahen komplexen Digital-Projektes aus dem industriellen Umfeld sollen die Vorteile einer agilen Denk- und Herangehensweise in einem solchen Projekt diskutiert werden. Der Leser kann dabei sowohl die technische, organisatorische als auch ökonomische Story verfolgen.

Um Story-Pfade überschaubar zu halten, wurden vom Autorenteam im Verlauf Annahmen und Entscheidungen getroffen, auf die explizit hingewiesen wird. Diese stellen jedoch keine Einschränkung der Verdeutlichung agiler Vorgehensweisen dar.

Ausgangslage – Welche Probleme hat der Kunde?

In der agilen Welt steht der Kunde im Mittelpunkt. Unser fiktiver Kunde betreibt drei baugleiche Prozessanlagen an drei verschiedenen Standorten. In seinen Anlagen könnten z. B. Rohmaterialien in kontinuierlichen Prozessen erstellt werden (Papierherstellung, Chemie-Industrie, oder vergleichbare).
Die Anlagen werden nach fest vorgeschriebenen statischen Wartungsintervallen gewartet. Während einer Wartung kann nicht produziert werden. Zudem sind die Wartungsintervalle zeitlich nicht mit der Auslastung der Anlage synchronisiert. Während der Wartung werden Teile vorbeugend getauscht, obwohl einige der Teile die Verschleißgrenze noch nicht erreicht haben. Der Kunde möchte nun gern die Stillstandszeiten minimieren und Wartungskosten einsparen. 
Er hat gelernt, dass ein Digitalisierungsprojekt, bei dem ein höherer Grad an IT und Vernetzung zum Einsatz kommt, ihm dabei helfen kann; sieht aber dadurch auch ein wachsendes Risiko von Cyber-Angriffen und Datendiebstahl.
Die Zusammenarbeit mit dem Kunden war in der Vergangenheit bereits intensiv und von Erfolgen in gemeinsamen Projekten geprägt. Dadurch ist eine solide Vertrauensbasis gewachsen. Aus diesem Grund wird der fiktive Kunde im weiteren Verlauf als Lead-Kunde bezeichnet.

 

Die Vision – Plant Watcher – Great to safe your Money!

Die Lösung für das oben beschriebene Problem ist der Plant Watcher. 
Er sagt voraus, wann und wo ein Defekt in der Anlage auftreten wird.
Er ermittelt die Ursache von Fehlern.
Er leitet das Wartungspersonal schnell zur Fehlerquelle.
Er bestellt rechtzeitig notwendige Ersatzteile.
Er schützt die Anlage vor Cyber-Angriffen.
Damit können Anlagenstillstände vermieden, Wartungskosten reduziert und das Sicherheitslevel weiterhin hochgehalten werden.

 

Ein erstes Team findet sich, Initiale Organisation

Gedankenspiele

Mit starker Orientierung an der Vision beginnt ein Kern-Team, mehrere parallele Umsetzungsvorschläge mittels unterschiedlicher Darstellungsweisen auszuarbeiten.  Dabei werden „Prototypen auf Papier“ erstellt, bewertet und verglichen. Es finden erste Gedankenexperimente statt, ob man den Plant-Watcher als anlagen-lokale oder cloud-basierte Lösung entwirft. Darüber hinaus werden vorab Risiken identifiziert und bewertet.
Bereits in dieser frühen Projektphase wird der vertrauensvolle Lead-Kunde in das Projekt eingebunden .


 

Aufstellung des ersten Teams

Annahme: Das agile Team besteht noch nicht, da die gesamte Organisation aus einem traditionellen Unternehmensumfeld kommt und noch keine Schritte in die Richtung von „Agilität“ gegangen ist.

Das im weiteren als Kern-Team bezeichnete Team besteht hauptsächlich aus Entwicklern aus verschiedenen, bereits bestehenden Organisationseinheiten, andere wichtige Unternehmensfunktionen sind aber auch Teil des Teams. Wichtig ist die Vertretung verschiedener Perspektiven und Fähigkeiten im Team, schon von Anfang an. Im weiteren Verlauf muss die Zusammenstellung gegebenenfalls neu überlegt und angepasst werden.

Um ein agiles Vorgehen zu erlernen, ist die Zuweisung von agilen Rollen (hier aus dem Scrum-Framework) wichtig, damit sich jedes Teammitglied orientieren kann und die Aufgaben und Verantwortungen klar abgegrenzt sind. Dies wird am besten durch gemeinsames Training und Teambuilding unterstützt.

Product Owner: wird durch den Produktmanager besetzt, da die Rolle im Unternehmen die meisten Aspekte schon abdeckt. Zusätzlich sollte hier die Entwicklung des Geschäftsmodells und die Wertschöpfungskette bei Entscheidungen (auch über spätere Feature-Wünsche) verantwortet werden.

Scrum Master(y): wird initial durch und aus Vertretern der Leitungsfunktionen aus der „alten“ Linien-Organisation bestimmt. Die ermittelte Person sollte passende Qualifikationen und vor allen Dingen ein Interesse an der Führung von Teams mitbringen.

Solution Developer : Entwicklungsteam: alle anderen Teammitglieder, NICHT NUR Entwickler!

 

Kern-Team

  • 2 Software-Entwickler

  • 2 Elektronik-Entwickler

  • 1 Mechanik-Entwickler

  • 1 Vertriebsmitarbeiter

  • 1 Produktmanager*in (als Vertreter der Kunden, die das spätere System kaufen)

  • 1 Wartungstechniker*in (als Vertreter der Nutzer des späteren Systems)

  • 1 Führungspersönlichkeit (Scrum Master)

 


 

Das aktuelle Geschäftsmodell

Das Unternehmen „SensMeTec“ ist langfristig am Markt etabliert und  ist im Bereich Sensorik und Messtechnik für verschiedene Industrieumfelder breit aufgestellt. Unterstützt wird die gute Marktpositionierung durch die Eigenentwicklung und -produktion spezieller Sensoren und die dadurch vorhandene Erfahrung.

Das aktuelle Geschäftsmodell des Unternehmens wird mit Hilfe des Business Model Canvas (kurz: BMC) von Alexander Osterwalder (2008) visualisiert und strukturiert. 
 


 

Ein guter Start erleichtert vieles – Arbeitsablauf, Rollen, Verantwortung und Führungskultur

Vorerst bleiben Kern-Team Mitglieder in der „alten“ Linien-Organisation, werden aber zu 100% für die Arbeit am „Plant-Watcher“ freigestellt, um den agilen Grundwerten und Prinzipien so nahe als möglich zu kommen und eine Teamentwicklung zu ermöglichen.

In einem ersten Training für das Kern-Team werden agile Prinzipien, Werte, Rollen und der Ablauf des Scrum-Frameworks als Grundlage der Teamentwicklung und Zusammenarbeit erläutert. Scrum wurde als Methode gewählt, da die Idee des „Plant-Watcher“ als Vision verstanden wird und der Weg zur Erfüllung zwar planbar ist, aber aktuell noch viele Fragen und Aspekte unbekannt und damit offen sind.

Folgende Verteilung der Verantwortung auf die Scrum-Rollen wurde als Startpunkt im Kern-Team vereinbart:

  • der Product Owner vertritt die Produkt-Perspektive und ist damit Verantwortlich gegenüber den Stakeholdern für das Ergebnis in technischer und finanzieller Hinsicht

  • die Solution Developer vertreten die Prozess-Perspektive und sind Verantwortlich für die Entwicklung, Lieferung und kontinuierliche Verbesserung der Wertschöpfung

  • der Scrum Master ist verantwortlich für die Fähigkeiten des gesamten Teams, der Teamentwicklung und wird somit (vorerst) als zusätzliche Rolle herausgestellt bzw. spezifisch besetzt.

Die Anbindung in die „klassische“ Organisation erfolgt über einen Supporting Leader, einen Sponsor der mind. die Autorität eines Abteilungs- oder Bereichsleiters hat. Seine Aufgabe ist vor allem der Schutz des Kern-Teams in seiner agilen Arbeitsweise und die wirksame Unterstützung bei organisatorischen Problemen oder Hindernissen, die außerhalb des Kern-Teams begründet sind.

Da keiner der Beteiligten im Umfeld des „Plant-Watcher“ Erfahrung mit der agilen Arbeitsweise hat, empfiehlt sich eine externe Begleitung durch einen agilen Coach oder Berater. Der Fokus der Begleitung sollte dabei nicht nur auf dem Kern-Team selber liegen, sondern auch die umliegende Organisation mit einbeziehen. Transparenz, gegenseitiges Verständnis wie auch Respekt sind wesentliche Erfolgsfaktoren in einem Veränderungsprozess.

Das Kern-Team lernt, angeleitet durch den agilen Coach, zuerst den Arbeitsablauf und die regelmäßigen Meetings, gleichzeitig aber auch durch das Reflektieren in den Retrospektiven, die Selbstverantwortung sowohl für Lieferungen als auch einer kontinuierlichen Verbesserung der Leistungsfähigkeit. So wird das Kern-Team mehr und mehr mit den agilen Prinzipien und Werten vertraut und etabliert diese in ihr tägliches Verhalten. Anfangs hat der agile Coach die Führung bzgl. des agilen Vorgehens und der unterstützenden Kultur. Diese Verantwortung wird nach und nach vom Scrum Master übernommen. Der agile Coach kann somit nicht nur die ganzheitliche Teamentwicklung, sondern auch das gewünschte Führungsverhalten des Scrum Masters und des Product Owners beeinflussen. Regelmäßig reflektiert der agile Coach, u.a. auch in Einzelgesprächen, mit Betroffenen die aktuelle Situation im Team und gibt Impulse zur Weiterentwicklung zu einem agilen Hochleistungsteam.

Die Denk- und Arbeitsweise im täglichen „doing“ ist von wesentlichen und für eine agile Umgebung typischen Prinzipen beherrscht. Übergeordnet ist das eine hoch iterative und reflektierende Vorgehensweise, die im Wesentlichen durch Design-Thinking geprägt ist. Kurze Feedback-Schleifen, Gedankenspiele, Visualisierungen in vielen kreativen Varianten spielen dabei eine entscheidende Rolle. Dabei wiegt in der Umsetzung die Kundenbindung und Wertauslieferung (time to market) höher als ein zu starker Fokus auf z.B. eine optimale Systemarchitektur (heute Effizienz, hoher Wiederverwendungsgrad, optimale Schnittstellen, etc.). Bevorzugt wird auch ein Over-Engineering bei dem eine starke Ressourceneinschränkungen vermieden, Performance vorgehalten und zu frühe Design-to-Cost-Gedanken vermieden werden. Eine spätere Design-to-Cost-Phase ist möglich und klar akzeptiert, dieses ist u. U. der Preis für „time-to-market“ und frühes Feedback. Kreativität bedeuteto offen denken, nicht aus den bestehenden Know-how-Silos heraus (Technologien mitbetrachten, die wir ggf. aktuell nicht haben), Chancen bewusst sehen oder erkennen wollen, den eigenen Werkzeugkasten und das Know-how dabei erweitern. So stehen Geschwindigkeit der Ideengenerierung, schnelles Feedback und Varianz der Lösungsvorschläge im Vordergrund und werden den späteren Erfolg begünstigen.


 

Fazit:

Eine kleine Veränderung – Wird sie eine große Wirkung haben?

Annahme: Das Kern-Team hat mehr und mehr gelernt nach agilen Prinzipien, Werten und im Scrum-Framework iterativ zu arbeiten. Scrum hat ihnen einen klaren und sicheren Rahmen gegeben um Verantwortung zu übernehmen und auch in Zukunft im Sinne der Stakeholder mit ihren unterschiedlichen Erwartungen sicher und zuverlässig zu agieren. Um die Produktentwicklung weiter ganzheitlich und vollständig voran treiben zu können, entwickelt sich aus dem Kern-Team der Wunsch eine zusätzliche, spezielle Rolle innerhalb des Teams zu etablieren – den System-Architekten.

Was soll das spätere Produkt können?

Erkennung des TOP-Fehlers

Das Kern-Team hat mehrere Umsetzungsvorschläge mittels „Prototypen auf Papier“ erstellt. Dabei wurden alle Aspekte der Vision des PlantWatchers betrachtet.
Als größtes technisches Risiko wird die sichere Früherkennung eines auftretenden „Top-Fehlers“ in der Anlage gesehen. Gelingt dies nicht, ist der Lead-Kunde vom Plant-Watcher nicht zu überzeugen und darauf aufbauende Funktionen stellen allein für den Lead-Kunden keinen Mehrwert dar. 

Schnelles Lernen durch mehrere Lösungsansätze

Zusammen mit dem Lead-Kunden wird ein Top-Fehler in seiner Anlage identifiziert. Ziel eines ersten „Minimal-Viable-Product“ (MVP) ist es nun, diesen Top-Fehler mit einer vorab definierten Treffsicherheit frühzeitig zu erkennen und in der Anlage zu lokalisieren. Dies soll mittels einer Software-Analytics-Funktion auf Basis von „Live“-Daten aus der Anlage geschehen. Die Live-Daten sollen dabei von Sensorik bereitgestellt werden, die bereits in der Anlage installiert ist. 

Da es mehrere Lösungsansätze für die Analytics-Funktion gibt, entscheidet das Kern-Team, die beiden vielversprechendsten Lösungsansätze A und B in zwei unterschiedlichen Realisierungen umzusetzen und beide im weiteren Verlauf beim Lead-Kunden zu testen, um das MVP besser definieren zu können.

Das Kern-Team entwickelt ein Verständnis für mögliche Systemarchitekturen.


 

Notwendige Strukturen werden klarer

Der Ansatz an zwei unterschiedlichen, aber zeitlich parallelen Realisierungen zu arbeiten, sowie die Abschätzung des Zeitbedarfs, legt nahe, dass zusätzlich Software-Kapazitäten benötigt werden. 

Um generell die Konsistenz der technischen Umsetzung gewährleisten zu können, benötigt das Kern-Team eine neue Rolle. Architektonische Entwicklungen und vor allem Entscheidungen wurden bisher innerhalb des Kern-Teams durchgeführt, jetzt wird dies durch den System Architect verantwortet.

In Zukunft wird es hier eine Veränderung durch die Etablierung weiterer Software-Teams geben, denn um weiter größtmögliche Unabhängigkeit und Flexibilität zu gewährleisten, ist es notwendig Vertreter aus den Software-Teams mit einzubeziehen.
 

Kern-Team

  • keine Änderungen in der Zusammenstellung

  • eine zusätzliche Person wird die (Haupt-) Verantwortung für die Systemarchitektur übernehmen


 

Erstes rein digitales Produkt

Das neue MVP führt zu einer Wandlung des bisherigen Geschäftsmodells. Neben dem bisher klassischen Verkauf von Sensorik und Messtechnik, soll zukünftig eine reine Analytics-Software als Produkt angeboten werden, welche unabhängig zu den Sensoren verkauft werden kann. Das Unternehmen baut dadurch sein Produktpalette aus und steigt zum ersten Mal in den Verkauf eines reinen digitalen Produkts ein. Die Auswirkungen auf das Geschäftsmodell ist in der BMC-Tabelle dargestellt. 

 

 


 

Kleine Veränderung – keine wesentliche Wirkung

Im Sinne der agilen Vorgehensweise, der Prinzipien hat es mit der Etablierung einer neuen Rolle (System Architect) innerhalb des bestehenden Teams keine Veränderung gegeben. Auch die Integration einer weiteren Person in den Ablauf, die Kommunikation wird aus agiler Sicht kein Hindernis oder keine Besonderheit darstellen. Betroffen ist der Team-Status und so hat der Scrum Master hier eine spezielle Aufgabe bzgl. der Teamentwicklung – die Leistungsfähigkeit wird durch die Hinzunahme eines Kollegen sicher beeinträchtigt werden, ein Anpassungsprozess, der beobachtet und reflektiert werden sollte, um das Kern-Team über die alte Leistungsfähigkeit hinaus und für neue, kommende Aufgaben zu entwickeln.


 

Fazit

Ein neues Kapitel der Veränderung beginnt – Zwei zusätzliche Teams stehen vor der Integration

Annahme: Das Kern-Team agiert sehr sicher und selbstständig, ist zu einer funktionierenden Gemeinschaft geworden und ein agiler Coach wird nur noch in seltenen Ausnahmefällen für eine Supervision und damit für einen unabhängigen “Blick von außen” benötigt. Auf den agilen Coach warten aber neue Herausforderungen, denn in die Entwicklung des “Plant-Watcher” sollen zwei neue Teams integriert werden. Eine Herausforderung nicht nur für die neuen sondern auch für das bestehende Team. Ein neues Kapitel der Veränderung beginnt.

Aus einem Team werden jetzt drei

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.


 

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

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


 

Keine Änderungen am Geschäftsmodell

Keine Änderung des Geschäftsmodells.

 


 

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.

Angestrebte Lösung A trägt nicht!

Ergebnisse der Evaluierung beim Kunden

Während der Erprobungsphasen der Lösungen A und B beim Kunden zeigt sich, dass Lösung A eine zu geringe Erkennungswahrscheinlichkeit des Top-Fehlers aufweist. Das Kern-Team stoppt daraufhin die Erprobung von Lösung A und initiiert die Entwicklung und Erprobung einer Lösung C. Lösung B und C werden nun weiterverfolgt und beim Lead-Kunden kontinuierlich erprobt. Im Ergebnis zeigt sich, dass auch Lösung C eine zu geringe Erkennungswahrscheinlichkeit des Top-Fehlers aufweist und wird daraufhin vom Kern-Team verworfen.

Aufgrund der beim Test der Lösung C gewonnenen Erkenntnisse, wird jedoch vermutet, dass die bereits früher verworfene Lösung A mit spezifischen Anpassungen zu einer höheren Erkennungswahrscheinlichkeit führen könnte.

Um das zu beweisen, beauftragt das Kern-Team nun das SW-Team, welches die Lösung A entwickelt hatte, die Lösung A wieder aufzunehmen und mit den gewonnenen Erkenntnissen zu überarbeiten. Es wird jedoch parallel auch Lösung B hinsichtlich der Erkennungswahrscheinlichkeit durch das bestehende Team durch auf Basis der neuen Erkenntnisse (aus C) weiter verbessert.

Nach Überarbeitung von A und Weiterentwicklung von B zeigt ein weiterer Test beim Lead-Kunden, dass die verbesserte Lösung A die höchste Erkennungswahrscheinlichkeit liefert und das Kern-Team entscheidet, von nun ab nur noch diese Lösung zu verfolgen. Dem Lead-Kunden ist jedoch die aktuell erreichte Erkennungswahrscheinlichkeit bei Lösung A immer noch zu gering.

Es folgt eine Analyse, was getan werden kann, um die Erkennungswahrscheinlichkeit zu erhöhen - mit dem Ergebnis, dass dazu spezielle Sensorik in der Anlage des Kunden nachgerüstet werden muss.


 

Keine Änderungen in den einzelnen Teams

 

 

Kern-Team

  • keine Änderungen in der Zusammenstellung

  • keine Änderungen in der Verantwortung 

zwei Software-Teams (jeweils):

  • keine Änderung in der Zusammensetzung

  • keine Änderung in der Verantwortung


 

Keine Änderungen am Geschäftsmodell

Keine Änderung des Geschäftsmodells.


 

Aufgabensteuerung und Kompetenz-Management

Technologisch ist viel Bewegung und Dynamik in diesem Abschnitt der Entwicklung unseres PlantWatcher. Diese Dynamik wirkt sich natürlich auch auf die Emotionen und damit die Leistung der Teams aus. Scrum Master und agile Coach hatten einiges zu tun, um die Fähigkeiten eines Teams zu stabilisieren. Aber der Reihe nach.

Das Software-Team welches Lösung A bearbeitet hat, stand plötzlich ohne Aufgabe da. Lösung A wurde beim Kunden nicht akzeptiert und im Core-Team wurden neue Lösungswege bzw. Alternativen diskutiert. Zumindest der Feature Owner war mit dabei und kam sehr schnell zu dem Schluss dass die notwendige Kompetenz für Lösung C aktuell in seinem Team nicht vorhanden war. Er informierte sofort seinen Scrum Master und das restliche Team. Gemeinsam veranstalteten sie ein erstes Backlog Refinement, um zu verstehen welche Ergebniserwartungen sie zu erfüllen hatten und daraus auch den Bedarf an Kompetenz zu identifizieren. Noch während die Solution Developer mit dem Feature Owner und mit weiteren Vertretern aus dem Core-Team im Refinement saßen, kümmerte sich der Scrum Master um Weiterbildungsmöglichkeiten.

Developer und Scrum Master standen in fast ständigem Kontakt, um mehr und immer konkretere Erkenntnisse über Notwendigkeit und Möglichkeit auszutauschen. So fand sich schnell eine gemeinsam erarbeitete Strategie, um die fehlende Kompetenz im Team herzustellen und die Erwartungen zur Lösung C erfüllen zu können. Ziel war es das Team zusammen zu halten und an der Lösung dieser Herausforderung zu beteiligen. So konnte die Motivation und damit die Leistungsbereitschaft sehr hochgehalten werden. Dann aber, kurze Zeit später, noch ein Rückschlag, denn Lösung C brachte nicht den gewünschten Erfolg, war aber offensichtlich der notwendige „Umweg“, um mit einer veränderten Lösung A vielleicht den Durchbruch zu schaffen.

Von außen betrachtet hatte die Leistungsfähigkeit sicher Einbrüche, aber durch den starken Zusammenhalt und die Beteiligung an der Lösung der Herausforderungen sowohl auf technischer als auch sozial-emotionaler Ebene konnte das betroffene Team sehr schnell wieder an alte Leistungen anknüpfen und einen wesentlichen Beitrag zum Gesamterfolg leisten.

Im zweiten Abschnitt ist nun das Team um die Lösungsvariante B von den technologischen Erkenntnissen und Entscheidungen betroffen. Aber auch hier bringt der Zusammenhalt nicht nur im Team, sondern im gesamten Team-Verbund enorme Vorteile mit sich. Die Teams tauschen sich jetzt noch enger inhaltlich aus und unterstützen sich gegenseitig, um dem Gesamterfolg näher zu kommen.

In der Zusammenfassung dieses Abschnittes soll nochmals betont werden, dass nicht einzelne Mitarbeiter durch „Ressourcen Management“ verwaltet und von Team zu Team entsendet wurden, sondern die Arbeit und der Arbeitsfluss wurden gesteuert. Weiter waren alle Betroffenen gemeinschaftlich an einer Lösung beteiligt und haben diese mitgetragen, im Sinne eines gemeinsamen Erfolges. Der Fokus der Aufgaben für Scrum Master und Agile Coach waren vor allem auf der sozialen und emotionalen Ebene zu beobachten, um ihrer Perspektive der „Fähigkeiten“ gerecht zu werden.


 

Fazit

Der gemeinsame Weg zum Ziel

Bisher haben die Teams zwar ein gemeinsames Ziel verfolgt, sind aber unterschiedliche und unabhängige Wege gegangen. Durch die technologischen Erkenntnisse und Entscheidungen rücken ab jetzt alle noch enger zusammen, denn sie arbeiten nun an einem Ziel und gehen einen gemeinsamen Weg. Damit bekommt die Synchronisation der einzelnen Teams innerhalb ihres Verbundes eine noch intensivere Bedeutung. Zudem muss das übergeordnete Kompetenz-Spektrum erweitert werden. Spannende Entwicklungen und Lösungen kündigen sich an.