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. 
 

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.

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.

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.

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.

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.

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.