FrankSazama- Technik
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.
- Organisation
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
- Geschäftsmodell
Keine Änderungen am Geschäftsmodell
… alles bleibt wie es ist …
- Agile Aspekte (Erkenntnisse)
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:
- … die Teams bleiben in ihrer Zusammensetzung bestehen. Dieses hat sich in der letzten Phase als sehr wertvoll erwiesen.
- … Planung, Verfolgung und Integration der Ergebnisse werden in einer übergeordneten Iteration zusammengefasst.
- … 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. - … Entscheidungen im Kernteam werden im Konsent (!) getroffen. So ist eine sehr konstruktive Balance zwischen Erwartung und Machbarkeit gegeben.
- … 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.