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

  • 1 Elektronik-Entwickler

  • 1 Mechanik-Entwickler

  • 1 Vertriebsmitarbeiter

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

  • 1 Wartungstechniker (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 bedeutet 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 sind im Business-Model-Canvas (BMC) 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

  • 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)“ 


 

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 durch das Software Team 1. 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 1 (SWT-1), 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 des SWT-1 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 SWT-1 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 Software-Team 2 (SWT-2) 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 im Sinne eines gemeinsamen Erfolges mitgetragen. Der Fokus der Aufgaben für die Scrum Master und des 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.

Neue Tests – neue Erkenntnisse

Zusätzliche Sensorik?

Bisher arbeiteten die Software-Analytics-Lösungen (A, B und C) mit existierenden Daten aus der Anlage des Kunden. Auf Grundlage dieser Daten ließ sich der Top-Fehler mit einer dem Kunden ausreichenden Erkennungswahrscheinlichkeit vorhersagen.

Die Teams beschäftigen sich damit, wie die Erkennungswahrscheinlich des Top-Fehlers weiter erhöht werden kann und wie weitere Fehler in der Anlage sicher erkannt werden können. Man kommt zu dem Schluss, dass dafür zusätzliche Sensorik in der Anlage des Kunden installiert werden muss. Allerdings ist noch nicht klar, welche Daten tatsächlich notwendig sind.

Durch weitere Tests beim Lead-Kunden wird nun herausgearbeitet, welche relevanten Prozessdaten erfasst werden müssen und daraus abgeleitet, welche zusätzliche Sensorik in der Anlage installiert werden muss

Im Ergebnis wird festgestellt, dass ein Teil dieser Sensorik im Hause SenseMeTec vorhanden ist, aber ein sehr spezieller Teil im existierenden Produktportfolio fehlt. Es wird vermutet, dass diese Spezialsensorik aber ein Schlüsselfaktor zur Erhöhung der Erkennungswahrscheinlichkeit ist und auch nur durch Spezialsensorik weitere Fehler sicher erkannt werden können. 
 

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.


 

Aus 3 mach 1 - individuelle Wege und Wertschöpfung werden zu einem Ganzen synchronisiert

Zwei wesentliche Herausforderungen, bezogen auf die Fähigkeiten aller drei Teams, sind zu bewältigen. Eines ist die deutlich engere Synchronisation und ein anderes die übergeordnete Notwendigkeit zur Erweiterung der Kompetenz.

Zur Synchronisation des Entwicklungsverbundes stehen mehrere sog. „Skalierungsmodelle“ zur Auswahl bzw. als Quelle von „good practice“ für eine individuelle Lösung zur Verfügung. Noch ist die Anzahl der Teams und auch die Gesamtsumme der Entwicklungsbeteiligten sehr überschaubar – ein hoher administrativer Aufwand wird nicht erwartet bzw. solle durch die anfängliche Lösung nicht entstehen. In einem Workshop aller (Kern-)Scrum Master, Product bzw. Feature Owner und jeweils einem Vertreter der Developer Perspektive aus jedem Team erarbeiten sie unter Anleitung des Agile Coach folgende Lösung: 

  1. … die Teams bleiben in ihrer Zusammensetzung bestehen. Dieses hat sich in der letzten Phase als sehr wertvoll erwiesen.

  2. ... Planung, Verfolgung und Integration der Ergebnisse werden in einer übergeordneten Iteration zusammengefasst. 

  3. … zur Kommunikation und Synchronisation werden aus den SW-Teams jeweils zwei Personen benannt: 
    I) Die einzelnen Feature Owner als Vertreter der Erwartungshaltung aus dem Kern-Team in das jeweilige SW-Team mit einer „top-down“ Perspektive, also was soll umgesetzt werden.
    II) Für die „bottom-up“ Perspektive (was kann umgesetzt werden) wird eine „Vertrauensperson“ jedes SW-Teams identifiziert und als Vertreter in das Kernteam berufen.

  4. … Entscheidungen im Kernteam werden im Konsent (!) getroffen. So ist eine sehr konstruktive Balance zwischen Erwartung und Machbarkeit gegeben.

  5. … Erkenntnisse aus dem Backlog-Refinement auf der Ebene des Kern-Teams werden durch mind. 2 Personen in das jeweilige SW-Team transferiert.

Die Scrum Master bilden unter der Leitung des Kern Scrum Master eine kleine Community of Practice (CoP) um gemeinsam die zweite Herausforderung zu meistern:

Es gilt Know-how aufzubauen, um Spezifikationen und Auswahlkriterien für die extern eingekaufte Spezialsensorik zu erstellen und in das eigene Produkt integrieren zu können. Dabei geht es der Scrum Master CoP nicht so sehr darum selbst Know-how aufzubauen, sondern Wege zu finden dieses technische Know-how ggf. im eigenen Unternehmen zu identifizieren und Konzepte für Trainings- und Weiterbildungen zur Verfügung zu stellen.

Ebenso geht es darum die notwendige Erwartungshaltung als Grundlage mit den Feature Ownern und dem Product Owner abzustimmen und die Maßnahmen zur Weiterentwicklung in das zentrale Backlog der Produktentwicklung zu integrieren und ggf. in den Backlogs der SW-Teams weiter zu detaillieren.

Wie bisher liegt die Verantwortung zur Umsetzung des jeweiligen Team-Backlogs bei den einzelnen Teams. Maßnahmen, die zum Erhalt oder zur Verbesserung der (Leistungs-)Fähigkeit beitragen bezeichnen wir als „enabler“. Diese repräsentieren ebenso Erwartungen an einzelne Teams oder den Teamverbund und sind entsprechend ins jeweilige Backlog zu übernehmen und ihrer Wertschöpfung nach angemessen sowie gegen bestehende andere Aufgaben zu priorisieren.

Fazit

Technik passt – was macht das Geschäftsmodell?

Nachdem der Top-Fehler beim Lead-Kunden nun sicher erkannt werden kann und der Kunde dies durch den ersten Kauf von Plant Watcher-Lizenzen honoriert, ergibt sich ein neues Problem. Der Product Owner stellt fest, dass allein durch den Verkauf von Software-Lizenzen an den Lead-Kunden und an weitere Kunden das angestrebte Geschäftsmodell nicht trägt. Hier muss zügig eine Lösung gefunden werden, wodurch im Weiteren der Pfad der Geschäftsmodellentwicklung in den Vordergrund rückt und Vorgaben für die weitere Entwicklung der Technik macht. 

Haben wir noch immer das richtige Geschäftsmodell?

Um die Kausalkette der Story besser zu verfolgen, empfiehlt es sich im Weiteren zunächst den Pfad des Geschäftsmodells zu lesen. Daher ist das Geschäftsmodell im folgenden Abschnitt bereits vorangestellt. 

 

Aktueller Stand des Geschäftsmodells

Das bisherige Geschäftsmodell der Firma SensMeTec bestand aus dem Verkauf von Pro-dukten (Sensorik und Messtechnik) sowie des dafür notwendigen Supports für die Auswahl oder die kundenspezifische Anpassung (Ingenieursdienstleistung) der Produkte. Mit der Entwicklung des Plant Watchers erweiterte sich das Geschäftsmodell zu Beginn nur um den Verkauf von Lizenzen für die Analytics-Software. Mit der Einführung eines Lizenzsys-tems fand bereits eine erste grundlegende Erweiterung des Geschäftsmodells statt.
Mittels einer Business Case Analyse zur Lösung A hat der Product Owner festgestellt, dass sich das aktuelle Geschäftsmodell langfristig nicht trägt. Die Einnahmen über das Lizenz-modell sind zu gering. Neue Geschäftsmodelle müssen entwickelt und erprobt werden.

 

Entwicklung von neuen Geschäftsmodellen

Es wird ein agiles Business-Model Team damit beauftragt, unter Berücksichtigung der Eingaben des Product Owners des Plant Watchers, andere zusätzliche Geschäftsmodelle zu (er-)finden und diese am Beispiel des Plant Watchers dem Supporting Leader und der weiteren Unternehmensleitung vorzustellen.
Das neu gegründete Team trifft sich mit dem Product Owner des Plant Watchers sowie Vertretern des Kern-Teams, um als Startpunkt der eigenen Arbeiten, die Situation des Plant Watchers aufzunehmen. Dabei wird auf die Business Case Analyse des Product Owners zurückgegriffen.

Um dem Prinzip „in kleinen Schritten etwas zu probieren und früh damit zu scheitern“ zu folgen, werden folgende Anforderungen für ein neues Business Modell des Plant Watchers vereinbart:

  • Das Modell muss sich für den einen Zielkunden selbst tragen. Die Tragfähigkeit soll nicht auf Querfinanzierung oder Annahmen zukünftiger Umsatzzahlen mit anderen Kunden basieren.
  • Das Modell muss sich zukünftig auf kleinere und größere Kunden skalieren lassen.
     

Unterüberschrift

Textelement mit Bild

Das Bild kann in diesem Element hinzugefügt werden, muss aber nicht.

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Unterüberschrift

Textelement mit Bild

Das Bild kann in diesem Element hinzugefügt werden, muss aber nicht.

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Plant Watcher verändert das Unternehmen – die Agilität entfaltet sich

Aus der Perspektive der agilen Transformation und des damit verbundenen organisatorischen Experiments steht das Unternehmen SensMeTec vor einer weiteren Herausforderung. Für einen eher klar umrissenen Zeitraum wird eine spezifische Kompetenz für den Plant Watcher benötigt. Die Scrum Master Community hat mehrere Möglichkeiten diskutiert, um die notwendigen Kompetenzen zu integrieren bzw. zu etablieren und ist zu dem Schluss gekommen, dass die notwendige Kompetenz zur Evaluierung bzw. Entwicklung alternativer Business-Modelle von einer Gruppe erfahrener Spezialisten auszuführen ist und nicht innerhalb der bestehenden Teams umgesetzt werden kann.

In der SensMeTec ist diese Kompetenz grundsätzlich vorhanden aber bisher klassisch in den vorhandenen Strukturen verteilt. Die Scrum Master Community geht dabei auf den Supporting Leader zu, um eine gemeinsame Entscheidung mit der Geschäftsleitung zu erwirken. Im Einvernehmen mit der Geschäftsleitung wurde, auf Basis der guten Erfahrungen im Rahmen des Plant Watchers, entschieden, dass die Kompetenz zur Business Modellierung gebündelt und in einem weiteren agilen Team organisiert werden soll. Das erweitert unser Plant Watcher-Experiment in einen Bereich außerhalb der Entwicklung, kommt aber der Vision einer modernen und anpassungsfähigen Organisation einen wesentlichen Schritt näher.

Auch in Zukunft wird die Überarbeitung, Neugestaltung oder Entwicklung von Geschäftsmodellen eine wesentliche Rolle für SensMeTec spielen, um sich an die Veränderungen im Markt erfolgreich anpassen zu können. Diese Anpassungsfähigkeit in Strukturen, Prozessen, Abläufen und der passenden Entwicklung von Mitarbeitern und damit der Unternehmenskultur wird u.a. auch als „Business Agility“ bezeichnet.

Das neu gebildete Team mit der Kernkompetenz „Business Modell Findung“ wird also auch in Zukunft bestehen und kann sich, wie die bisher im Plant Watcher etablierten Teams, zu einem stabilen Hochleistungsteam entwickeln. Organisiert und strukturiert ist dieses Business-Model Team nach dem gleichen Muster wie die bisherigen agilen Teams auch. Ganz konkret besteht es aus einem Feature Owner  des Business-Model Teams, einem Scrum Master und den Developern in Form der Spezialisten, die für eine ganzheitliche Entwicklung und Bewertung von Geschäftsmodellen notwendig sind.

Für die Zeit der Zusammenarbeit mit den bestehenden Teams im Plant Watcher gliedert sich dieses spezielle Team in den Entwicklungsverbund mit ein und alle Teams arbeiten in einem zeitlich und inhaltlich synchronen Ablauf. Die inhaltliche Kommunikation erfolgt im Schwerpunkt über den Product Owner aber auch über die Integration des Feature Owners des Business-Model Teams in das Kern-Team selbst.

Die bisherige Entwicklungsdomäne des Plant Watchers bleibt unangetastet, das neue Business-Model Team ‚koppelt an‘ und alle Teams bilden dann zusammen ein ‚Netzwerk‘. Für die aktuelle Situation bzw. den Entwicklungsabschnitt des Plant Watchers hat dieses Netzwerk ein gemeinsames Ziel: die Optimierung des Geschäftsmodells für das neue Plant Watcher Portfolio.
 

Fazit

Ein neues Geschäftsmodell entsteht

Das neu ins Leben gerufene Business-Model Team macht sich an die Arbeit neue Geschäftsmodelle für den Plant Watcher zu (er)finden. Die Technik-Teams arbeiten weiter an der Steigerung der Erkennungsgenauigkeit des Top-Fehlers und gewinnen mehr und mehr Erkenntnisse, welche Sensorik wo passgenau in der Anlage des Lead Kunden eingerichtet werden muss. Für sie bleibt es spannend, in welche Richtung sich die Technik weiterentwickeln muss, um zukünftigen neuen Geschäftsmodellen zu genügen. Der komplette Entwicklungsverbund ist aktuell einer hohen Änderungsdynamik ausgesetzt, aber man ist optimistisch, ein tragfähiges Geschäftsmodell zu finden und damit auch dem Technikpfad eine klare Vision zu geben.