SlideShare ist ein Scribd-Unternehmen logo
1 von 20
S E L B S T S I C H E R Z U M E R F O L G
Meetup BizDevOps
Was Versicherungen von Banken lernen können
19.05.2020
1 Mai-20
S E L B S T S I C H E R Z U M E R F O L G
Agenda
18:15 Uhr “Einlass” & Technikcheck
18:30 Uhr Begrüßung, Kennenlernen & Vortrag
19:15 Uhr Open Space
19:45 Uhr Ende
2 Mai-20
S E L B S T S I C H E R Z U M E R F O L G
Herzlich Willkommen!
Mai-203
Stefan
Nagel
Christoph
Schmiedinger
S E L B S T S I C H E R Z U M E R F O L GMai-204
Check-In
Wir starten mit einem kleinen Check-In in mentimeter!
menti.com
37 58 20
S E L B S T S I C H E R Z U M E R F O L G
Warum sollte mich das interessieren?
5 Mai-20
source: wikipedia.org
S E L B S T S I C H E R Z U M E R F O L GMai-206
Das Ende der IT wie wir sie kennen
INSURANCE as we
know IT
Blockchain
Technolog
y
Robotic Process Automation
Internet of Things
Big Data
Handling
S E L B S T S I C H E R Z U M E R F O L G
Der Case
9
S E L B S T S I C H E R Z U M E R F O L G
Der 1. Schritt
10
Integration von Entwicklung und Fachexperten
60%
End-to-end Grad
Die Benefits:
 Etablierung eines “gemeinsamen“
Teams
 Verfolgen eines einheitlichen Ziels
 Direkte & schnelle Kommunikation
(kein „über den Zaun werfen“)
Die Herausforderungen:
 Unterschiedliche „Sprache“
 Gegenseitiges Misstrauen
 Zielkonflikte (Features vs. Qualität)
 Lähmung der Entwicklung durch
Zulieferungen aus dem Betrieb
S E L B S T S I C H E R Z U M E R F O L G
Der 2. Schritt
11
Zusätzliche Integration von IT-Operations Experten
End-to-end Grad
75%
Die Benefits:
 Schnelle und unkomplizierte Lösung
einfacher Operations-Themen
 Intensivierte Kommunikation und
effizientere Aussteuerung von
Support-Tickets
Die Herausforderungen:
 Eine „weitere“ Sprache
 Keine 100%-ige Abdeckung der
Operations-Themen
 Weiterhin schwache Verbindung nach
außen zum Kunden
S E L B S T S I C H E R Z U M E R F O L G
Der 3. Schritt
12
Zusätzliche Integration von Business-Operations Experten
Wichtig:
Kein reiner Einsatz als Domain Experts,
sondern als prozessdurchführende Kollegen!
Sachbearbeiter
Vertrieb
Marketing
Kundenbetreuer
Kundenservice
S E L B S T S I C H E R Z U M E R F O L G
Der 3. Schritt
13
Zusätzliche Integration von Business-Operations Experten
End-to-end Grad
90%
Die Benefits:
 Viel näherer Kontakt zum Kunden
 Enger Austausch zwischen „Change“
und „Run“
Die Herausforderungen:
 nächste Slide
S E L B S T S I C H E R Z U M E R F O L G
Es gibt keinen optimalen Blueprint ...
14
Gefahr der Ineffizienz auf Grund ...
 ... zu vieler paralleler Themen (kein Fokus)
 ... zu starker Vermischung von „Change“ und „Run“
 ... eines zu großen Teams
 ... von Zielkonflikten
... die Herausforderungen ändern sich lediglich
S E L B S T S I C H E R Z U M E R F O L G
Die IT wandelt sich zum funktionalen Nukleus der Versicherer
Mai-2018
Risiko-
übernahme
Produktentwicklu
ng
VertriebUnderwriting
Schaden-
regulierung
Blockchain
Technology
Robotic Process
Automation
Internet of Things
Big Data Handling Big Data Handling
ITIT
S E L B S T S I C H E R Z U M E R F O L G19 Mai-20
Mix IT up – BIZness, DEVelopment & OPerationS kombinieren
S E L B S T S I C H E R Z U M E R F O L G
Beispiel: Was brauche ich zur Entwicklung einer Telematik-
Applikation?
20 Mai-20
Marktspezialist
Leadership Experte
Entwicklungsteam
 Jurist
 Data Analyst
 Full-Stack Entwickler
 IT-Betrieb
S E L B S T S I C H E R Z U M E R F O L G
BizDevOps – Was bringt es?
21 Mai-20
Höhere Erfolgswahrscheinlichkeit des Produktes1
Kürzere Entwicklungs-, Test- und Releasezyklen4
Kontinuierlicher Wissenstransfer5
Höherer Kunden-/Userfokus2
Produktentwicklung & IT im Gleichklang3
S E L B S T S I C H E R Z U M E R F O L G
Unser Whitepaper zum Thema
22 Mai-20
BizDevOps - Warum multidisziplinäre Teams
für deutsche Versicherer unausweichlich sind
www.borisgloger.c
om
S E L B S T S I C H E R Z U M E R F O L G
Open Space
 Aufteilung in Break-out Sessions von je 5-6 Personen
 Bitte notiert in Mentimeter die Inhalte eurer Diskussion mit
 Diskutiert bitte folgende Leitfrage:
23 Mai-20
Wo seht ihr Anwendungsmöglichkeiten für BizDevOps und
habt ihr damit schon Erfahrungen gemacht?
S E L B S T S I C H E R Z U M E R F O L G
Ergebnisse Breakout-Sessions
24 Mai-20
S E L B S T S I C H E R Z U M E R F O L G
S E L B S T S I C H E R Z U M E R F O
L G
www.borisgloger.com
Follow us on Social Media
Mai-2025

Weitere ähnliche Inhalte

Ähnlich wie Meetup BizDevOps - Was Versicherungen von Banken lernen können (19.05.2020)

procon_Digitale Transformation_Digitalisierung
procon_Digitale Transformation_Digitalisierungprocon_Digitale Transformation_Digitalisierung
procon_Digitale Transformation_Digitalisierung
Andreas Sattlberger
 
MeetUp - Der agile ingenieur 2020
MeetUp - Der agile ingenieur 2020MeetUp - Der agile ingenieur 2020
MeetUp - Der agile ingenieur 2020
Helene Valadon
 

Ähnlich wie Meetup BizDevOps - Was Versicherungen von Banken lernen können (19.05.2020) (20)

4 Schritte zur Verankerung eines starken „Warum“ mittels Zielzustandskaskade
4 Schritte zur Verankerung eines starken „Warum“ mittels Zielzustandskaskade4 Schritte zur Verankerung eines starken „Warum“ mittels Zielzustandskaskade
4 Schritte zur Verankerung eines starken „Warum“ mittels Zielzustandskaskade
 
DIGITIZER INSIGHTS #1 Einfluss der Digitalisierung auf Österreichs Unternehmen
DIGITIZER INSIGHTS #1 Einfluss der Digitalisierung auf Österreichs UnternehmenDIGITIZER INSIGHTS #1 Einfluss der Digitalisierung auf Österreichs Unternehmen
DIGITIZER INSIGHTS #1 Einfluss der Digitalisierung auf Österreichs Unternehmen
 
Hoa tuoi-dep
Hoa tuoi-depHoa tuoi-dep
Hoa tuoi-dep
 
Vorbild Spotify - die Herausforderungen einer Transformation
Vorbild Spotify - die Herausforderungen einer TransformationVorbild Spotify - die Herausforderungen einer Transformation
Vorbild Spotify - die Herausforderungen einer Transformation
 
Vorbild Spotify - die Herausforderungen einer Transformation
Vorbild Spotify - die Herausforderungen einer TransformationVorbild Spotify - die Herausforderungen einer Transformation
Vorbild Spotify - die Herausforderungen einer Transformation
 
Payment der Zukunft vor dem Hintergrund von Mobile & Compliance
Payment der Zukunft vor dem Hintergrund von Mobile & CompliancePayment der Zukunft vor dem Hintergrund von Mobile & Compliance
Payment der Zukunft vor dem Hintergrund von Mobile & Compliance
 
procon_Digitale Transformation_Digitalisierung
procon_Digitale Transformation_Digitalisierungprocon_Digitale Transformation_Digitalisierung
procon_Digitale Transformation_Digitalisierung
 
MeetUp - Der agile ingenieur 2020
MeetUp - Der agile ingenieur 2020MeetUp - Der agile ingenieur 2020
MeetUp - Der agile ingenieur 2020
 
Agilität als Erfolgsfaktor im Wandel zur digitalen Bank
Agilität als Erfolgsfaktor im Wandel zur digitalen BankAgilität als Erfolgsfaktor im Wandel zur digitalen Bank
Agilität als Erfolgsfaktor im Wandel zur digitalen Bank
 
Voice Erfahrungsaustausch CIO Barometer
Voice Erfahrungsaustausch CIO BarometerVoice Erfahrungsaustausch CIO Barometer
Voice Erfahrungsaustausch CIO Barometer
 
S&T AG: Enabling digital business models
S&T AG: Enabling digital business modelsS&T AG: Enabling digital business models
S&T AG: Enabling digital business models
 
Die Zukunft der IT
Die Zukunft der ITDie Zukunft der IT
Die Zukunft der IT
 
Die 5 wichtigsten Sales-Trends 2022
Die 5 wichtigsten Sales-Trends 2022Die 5 wichtigsten Sales-Trends 2022
Die 5 wichtigsten Sales-Trends 2022
 
Bankenstudie 2019
Bankenstudie 2019Bankenstudie 2019
Bankenstudie 2019
 
Zalando runs HANA and SAP BI
Zalando runs HANA and SAP BIZalando runs HANA and SAP BI
Zalando runs HANA and SAP BI
 
VER-RÜCKTE WELT - Ist die Digitalisierung ein Frage von 0 und 1? Oder mehr?
VER-RÜCKTE WELT - Ist die Digitalisierung ein Frage von 0 und 1? Oder mehr?VER-RÜCKTE WELT - Ist die Digitalisierung ein Frage von 0 und 1? Oder mehr?
VER-RÜCKTE WELT - Ist die Digitalisierung ein Frage von 0 und 1? Oder mehr?
 
BEKO News
BEKO NewsBEKO News
BEKO News
 
CIO Studie 2011__Deutschland_POV
CIO Studie 2011__Deutschland_POVCIO Studie 2011__Deutschland_POV
CIO Studie 2011__Deutschland_POV
 
Arbeitswelt 2025: Die Jobs der Zukunft
Arbeitswelt 2025: Die Jobs der ZukunftArbeitswelt 2025: Die Jobs der Zukunft
Arbeitswelt 2025: Die Jobs der Zukunft
 
eStrategy-Magazin - Ausgabe 03/2020
eStrategy-Magazin - Ausgabe 03/2020eStrategy-Magazin - Ausgabe 03/2020
eStrategy-Magazin - Ausgabe 03/2020
 

Meetup BizDevOps - Was Versicherungen von Banken lernen können (19.05.2020)

  • 1. S E L B S T S I C H E R Z U M E R F O L G Meetup BizDevOps Was Versicherungen von Banken lernen können 19.05.2020 1 Mai-20
  • 2. S E L B S T S I C H E R Z U M E R F O L G Agenda 18:15 Uhr “Einlass” & Technikcheck 18:30 Uhr Begrüßung, Kennenlernen & Vortrag 19:15 Uhr Open Space 19:45 Uhr Ende 2 Mai-20
  • 3. S E L B S T S I C H E R Z U M E R F O L G Herzlich Willkommen! Mai-203 Stefan Nagel Christoph Schmiedinger
  • 4. S E L B S T S I C H E R Z U M E R F O L GMai-204 Check-In Wir starten mit einem kleinen Check-In in mentimeter! menti.com 37 58 20
  • 5. S E L B S T S I C H E R Z U M E R F O L G Warum sollte mich das interessieren? 5 Mai-20 source: wikipedia.org
  • 6. S E L B S T S I C H E R Z U M E R F O L GMai-206 Das Ende der IT wie wir sie kennen INSURANCE as we know IT Blockchain Technolog y Robotic Process Automation Internet of Things Big Data Handling
  • 7. S E L B S T S I C H E R Z U M E R F O L G Der Case 9
  • 8. S E L B S T S I C H E R Z U M E R F O L G Der 1. Schritt 10 Integration von Entwicklung und Fachexperten 60% End-to-end Grad Die Benefits:  Etablierung eines “gemeinsamen“ Teams  Verfolgen eines einheitlichen Ziels  Direkte & schnelle Kommunikation (kein „über den Zaun werfen“) Die Herausforderungen:  Unterschiedliche „Sprache“  Gegenseitiges Misstrauen  Zielkonflikte (Features vs. Qualität)  Lähmung der Entwicklung durch Zulieferungen aus dem Betrieb
  • 9. S E L B S T S I C H E R Z U M E R F O L G Der 2. Schritt 11 Zusätzliche Integration von IT-Operations Experten End-to-end Grad 75% Die Benefits:  Schnelle und unkomplizierte Lösung einfacher Operations-Themen  Intensivierte Kommunikation und effizientere Aussteuerung von Support-Tickets Die Herausforderungen:  Eine „weitere“ Sprache  Keine 100%-ige Abdeckung der Operations-Themen  Weiterhin schwache Verbindung nach außen zum Kunden
  • 10. S E L B S T S I C H E R Z U M E R F O L G Der 3. Schritt 12 Zusätzliche Integration von Business-Operations Experten Wichtig: Kein reiner Einsatz als Domain Experts, sondern als prozessdurchführende Kollegen! Sachbearbeiter Vertrieb Marketing Kundenbetreuer Kundenservice
  • 11. S E L B S T S I C H E R Z U M E R F O L G Der 3. Schritt 13 Zusätzliche Integration von Business-Operations Experten End-to-end Grad 90% Die Benefits:  Viel näherer Kontakt zum Kunden  Enger Austausch zwischen „Change“ und „Run“ Die Herausforderungen:  nächste Slide
  • 12. S E L B S T S I C H E R Z U M E R F O L G Es gibt keinen optimalen Blueprint ... 14 Gefahr der Ineffizienz auf Grund ...  ... zu vieler paralleler Themen (kein Fokus)  ... zu starker Vermischung von „Change“ und „Run“  ... eines zu großen Teams  ... von Zielkonflikten ... die Herausforderungen ändern sich lediglich
  • 13. S E L B S T S I C H E R Z U M E R F O L G Die IT wandelt sich zum funktionalen Nukleus der Versicherer Mai-2018 Risiko- übernahme Produktentwicklu ng VertriebUnderwriting Schaden- regulierung Blockchain Technology Robotic Process Automation Internet of Things Big Data Handling Big Data Handling ITIT
  • 14. S E L B S T S I C H E R Z U M E R F O L G19 Mai-20 Mix IT up – BIZness, DEVelopment & OPerationS kombinieren
  • 15. S E L B S T S I C H E R Z U M E R F O L G Beispiel: Was brauche ich zur Entwicklung einer Telematik- Applikation? 20 Mai-20 Marktspezialist Leadership Experte Entwicklungsteam  Jurist  Data Analyst  Full-Stack Entwickler  IT-Betrieb
  • 16. S E L B S T S I C H E R Z U M E R F O L G BizDevOps – Was bringt es? 21 Mai-20 Höhere Erfolgswahrscheinlichkeit des Produktes1 Kürzere Entwicklungs-, Test- und Releasezyklen4 Kontinuierlicher Wissenstransfer5 Höherer Kunden-/Userfokus2 Produktentwicklung & IT im Gleichklang3
  • 17. S E L B S T S I C H E R Z U M E R F O L G Unser Whitepaper zum Thema 22 Mai-20 BizDevOps - Warum multidisziplinäre Teams für deutsche Versicherer unausweichlich sind www.borisgloger.c om
  • 18. S E L B S T S I C H E R Z U M E R F O L G Open Space  Aufteilung in Break-out Sessions von je 5-6 Personen  Bitte notiert in Mentimeter die Inhalte eurer Diskussion mit  Diskutiert bitte folgende Leitfrage: 23 Mai-20 Wo seht ihr Anwendungsmöglichkeiten für BizDevOps und habt ihr damit schon Erfahrungen gemacht?
  • 19. S E L B S T S I C H E R Z U M E R F O L G Ergebnisse Breakout-Sessions 24 Mai-20
  • 20. S E L B S T S I C H E R Z U M E R F O L G S E L B S T S I C H E R Z U M E R F O L G www.borisgloger.com Follow us on Social Media Mai-2025

Hinweis der Redaktion

  1. Das Dilemma, welches sich aus der ganzen end-to-end Diskussion ergibt, ist folgendes: Das Team sollte einerseits, wie bereits zuvor angesprochen, möglichst „end-to-end“ aufgestellt und damit auch “end-to-end“ lieferfähig sein und andererseits gleichzeitig jedoch klein und handlungsfähig bleiben – weil wir ja wissen, dass es bei Teams ab 10 Personen naturgemäß mit oder ohne agile Methoden zu Ineffizienzen kommt. Da wir heute nun mal in einer Welt leben, die immer komplexer wird und dadurch auch die für die Herausforderungen notwendigen Lösungen mit komplexer werden, brauchen wir für die Entwicklung von Produkten heute ein Vielzahl von Skills. In diesem Schaubild habe ich beispielhaft mal einige der Wissensdomänen aufgelistet und jedem sollte hier schnell klar werden - ein Team mit max. 9 Personen, dass gleichzeitig möglichst „end-to-end“ aufgestellt ist, wird eine Herausforderung, und keine kleine! Vor allem im Hinblick darauf, dass Skills typischerweise ja auch durch mind. 2 Kollegen abgedeckt sein sollten, um nicht zu sehr auf Grund von Wissensmonopolen abhängig zu sein.
  2. Die Gretchenfrage, die sich bei der Zusammensetzung eines konkreten Teams stellt, ist die folgende: Wo beginnt und endet ein sinnvoller end-to-end Schnitt? Nicht jede Integration zusätzlicher Skills macht auch automatisch Sinn. Ein ehemaliger Kunde von mir hat hier den Begriff der „end-to-end-Lüge“ geprägt. Nämlich, dass es in der heutigen komplexen Welt in einer Vielzahl von Umgebungen weder möglich ist noch sinnvoll ist, alle für eine Entwicklung notwendigen Skills in einem Team zu integrieren,. Ein Beispiel: braucht am Ende jedes Team seinen eigenen Pförtner/seinen eigenen Empfang? Wahrscheinlich nicht und genau darum geht es: sinnvoll abzuwägen, was es an Skills im Team braucht und welche zentral als Services bereitgestellt werden können. Wichtig ist, hier langfristig auf möglichst viel Automatisierung und saubere Schnittstellendefinitionen zu setzen, um hier so wenig Reibungsverluste wie möglich zu erzeugen.
  3. Sehr gerne möchte ich die Weiterentwicklung hin zu „BizDevOps“ und insbesondere deren Herausforderungen an Hand eines konkreten Beispiels aus der Praxis verdeutlichen. Die Initialaufstellung des Kunden war wie hier skizziert sehr klassisch orientiert. Es gab einen Bereich im Business, der sich mit der gesamten Online Plattform und den damit verbundenen Angeboten und Produkten beschäftigte. Darunter waren natürlich viele Fachexperten, die ein starkes Domänenwissen auf diesem Gebiet hatten und wussten, wie die einzelnen Prozesse innerhalb dieser Plattformen zu designen und weiterentwickeln sind. Unter diese Fachexperten mischten sich auch eher operative Kollegen, die die Website, die Apps und den Webshop am Laufen hielten und mit Inhalt bespielten. Die Abgrenzung zwischen diesen Kollegen ist nicht immer ganz eindeutig – mir geht es aber vor allem darum aufzuzeigen, dass es diese zwei Arten von Arbeiten im Business Kontext gibt – eher im Design und in der Weiterentwicklung der Customer Experience und eher operativ als wirkliche Kraft im Prozess, wie hier beispielsweise im Content Management. Daneben gab es einen IT-Bereich, der relativ klassisch in einen Change- und einen Betriebs-Bereich aufgeteilt war. In dem Change-Part wurden die einzelnen Applikationen durch Development-Teams entwickelt. Im Betriebs-Anteil waren beispielsweise das Datacenter, zentrale Security Funktionen und ein paar weitere Core-Systeme angesiedelt. Mit diesem Setup waren auch viele der klassischen Herausforderungen getrennter Fach- und IT-Welten verbunden. Schwierigkeiten in der Abstimmung zwischen den beiden Seiten. Anforderungsdokumente auf der einen, IT-Konzepte auf der anderen Seite, um nach mehreren Monaten anschließend zu merken, dass die gesamte Lösung mehr oder weniger an den Kunden vorbei entwickelt wurde. Innerhalb der IT zogen sich diese Abstimmungsschwierigkeiten weiter, sodass unfertige und qualitativ nicht ausgereifte Lösungen auf Grund von forcierten Projektenden in den Betrieb meist mit lediglich rudimentärem Übergabeprozess überführt werden und dann dort auf wenig Gegenliebe stoßen. Alles in allem ein Arbeitsmodell, welches zahlreiche Probleme aufwarf und eine Vielzahl der Beteiligten nicht zufrieden stellte.
  4. Der erste Schritt zur Verbesserung des gesamten Prozesses war die Einführung von virtuellen cross-funktionalen Teams und die Umstellung auf agile Arbeitsweisen. So wurden kleine Teams geschnitten, die für jeweils ein Produkt oder einen Teil eines Produkts verantwortlich waren. Diese Teams hatten jeweils einen Product Owner, der inhaltlich für das Produkt verantwortlich war und meistens aus dem Business kam, und einen ScrumMaster, der das Team auf dem Weg in die performende Selbstorganisation begleiten sollte. Neben dem PO hatten die diversen Teams auch noch 1-2 weitere Fachexperten in den Teams, um genug Branchen- und fachliches Wissen in die Teams zu integrieren. „Aufgefüllt“ wurde das Team mit einem breiten Mix an Development-Skills. Datenbanken, Service-Entwicklung, Front-End, UX-Designer usw. Die Vorteile stellten sich über einen Zeitraum von 4-6 Iterationen ein. Das wichtigste Kernelement war die Etablierung eines „gemeinsamen“ Teams. Wir konnten hier die Wand zwischen den vorher durchaus getrennten Welten einreißen und so das ganze Team verantwortlich für ein Ziel und damit auch einen gemeinsamen Erfolg machen. Ein schönes Resultat war auch die direkte und schnelle Kommunikation zwischen den verschiedenen Wissenden, die ein „über ein Zaun werfen“ verhinderten. Einen Erfolg, der nicht gleich zu Beginn sichtbar war, ist der Fakt, dass wir mit einem Setup, welches Fachexperten beinhaltet, schneller an das ideale Zielbild einer modernen agilen Product Ownership kommt. Hier übernimmt der Product Owner nur mehr eine strategische Rolle ein und legt die große Richtung für das Team fest, während das Entwicklungsteam selbst sich um die Aufteilung in kleinere User Stories und deren Abstimmung mit den Stakeholdern kümmert. Ein Bild, dass mit Hilfe von zusätzlichen Fachexperten wesentlich einfacher erreicht werden kann. Gerade am Anfang – das heißt im Wesentlichen in den ersten 3 Sprints – waren jedoch auch die Herausforderungen enorm. Wir hatten mit unterschiedlichen „Sprachen“ zu kämpfen – es verstanden sich nicht alle von Beginn an und so musste gerade der ScrumMaster hier einiges an Entwicklungshilfe leisten, um die Sprachbarrieren schrittweise zu reduzieren. Auch kamen beide Seiten in einigen Teams mit einem großen Misstrauen aufeinander zu, dass sich in den letzten Jahren auf Grund von Misskommunikation gebildet hatte. Schnell stellte sich auch heraus, dass die inhärenten Ziel-Konflikte zwischen Business und IT viel transparenter wurden. Während es für die Business-Seite darum ging, möglichst viele Features zu möglichst geringem Werteinsatz zu entwickeln, mussten die Kollegen aus dem Dev-Part immer wieder auf die Bremse steigen, um so auch eine Qualität sicherstellen zu können, die einen nachhaltigen Betrieb gewährleisten konnte. Ein weiteres Problem war, dass die Entwicklung immer wieder durch Support-Tickets an den eigenen Betrieb gelähmt wurde, weil hier viel zusätzliche Abstimmung notwendig war und die Laufzeiten sehr lange waren. Nichts desto trotz konnten wir mit Hilfe diesen Schrittes den end-to-end Grad der Teams auf etwa 60% schrauben – und das ist nur eine Schätzung. Definitiv eine erste Leistung, aber unserem Anspruch nach noch zu wenig.
  5. In einem zweiten Schritt wurden in die einzelnen Teams auch vermehrt IT-Operations Experten eingegliedert. Dies half ungemein bei der letzten Herausforderung, welche ich gerade eben angesprochen hatte. Die diversen Operations-Themen, welche Stand damals noch viel manuell bearbeitet wurden und in Zukunft definitiv auch automatisiert werden sollten, konnten so viel leichter getracked und vorangebracht werden, da es nun explizit Kollegen gab, die genau darauf ihren Fokus hatten und so nicht ständig von der Entwicklung abgelenkt wurden. Des Weiteren konnten diese Kollegen eine Vielzahl von kleineren und einfacheren Operations-Themen schnell und unkompliziert im Team lösen, ohne dass andere Einheiten überhaupt betroffen waren. Ich muss zugeben, dass gerade diese Änderung fast nur Vorteile mit sich brachte. Wenn Sie so wollen, ist dies die klassische “DevOps“-Erweiterung. Der einzige Nachteil war, dass durch eine weitere Sprache und der Integration weiterer Kollegen die Komplexität im Team (gerade in der Ebene der Kommunikation) noch weiter erhöht wurde. Auch haben wir es mit Hilfe der Integration von 1-2 Operations-Kollegen pro Team nicht geschafft, alle Operations Themen zu 100% abzudecken, sodass weiter ein nicht unrelevanter Teil über Support-Tickets an den Betrieb ausgesteuert werden musste. Kein Nachteil dieses spezifischem Setups, sondern bereits seit Anbeginn, war die nach wie vor schwache Verbindung des Teams nach Außen zum Kunden. Wir hatten zwar Fachexperten, Domänenwissende und User Experience Designer mit viel vermeintlichem Wissen über die Kunden an Board, aber ein tatsächlicher direkter Kontakt war trotzdem rar gesät. Wenn wir den end-to-end Grad dieses Setups abschätzen müssten, würde ich ihn, je nach Team, mit ca. 75% beziffern. Ein weiterer guter Schritt in die Richtung, die Teams autonomer und selbstverantwortlicher zu machen.
  6. Die Stoßrichtung der 100%-igen Abdeckung von Operations hatten wir nicht weiter verfolgt, da die Strategie war, eine Vielzahl der Operations-Themen über die nächsten Jahre zu automatisieren, umso schrittweise die 1-2 Operations-Experten je Team für die übrig bleibenden Themen zu nutzen und so den Abdeckungsgrad zu erhöhen. An der zweiten Thematik – dem Fehlen der Kundennähe – wollten wir jedoch weiter arbeiten. So kam die Idee, zusätzlich auch noch Operations Experten aus dem Fachbereich, also aus dem Business, zu integrieren. Dies sind nämlich genau jene Kollegen, die wirklich nah am Kunden sind, weil sie tagtäglich die Prozesse am Kunden durchführen. Beispiele sind hierfür Kundenbetreuer, der Vertrieb und Sachbearbeiter. Wichtig ist, dass wir diese Kollegen nicht nur als reine Domain-Experten integrieren (wie beispielsweise: wir stellen einen Sachbearbeiter aus der Immobilien-Bewertung für Hypothekar-Kredite für ein Scrum Team für 6 Monate ab), sondern als wirklich prozessdurchführende Kollegen. Das heißt, dass diese weiter an ihren Themen arbeiten und so ständig Rückmeldung über den Prozess und dessen Performance geben können. Was nicht heißt, dass es nicht durchaus Sinn macht, für größere Themen auch wirklich Kollegen freizustellen und als Domänen-Experten arbeiten zu lassen. Ich will hier nur bewusst diesen letzten Schritt, der Integration von wirklich im Prozess arbeitenden Kollegen, herausgreifen, um zu verdeutlichen, was für Auswirkungen dieser Schritt hat.
  7. Die Vorteile eines solchen Setups sind ganz klar die Nähe zum Kunden. Dadurch, dass diese neuen Operations-Kollegen aus dem Business noch wirklich in ihren Prozessen arbeiten, erleben sie tagtäglich die Bedürfnisse und Probleme der Kunden. Auch findet so ein noch engerer Austausch zwischen „Change“ und „Run“ statt – was gerade im Hinblick auf die Weiterentwicklung der Lösung den großen Vorteil hat, tatsächlich nah an den Bedürfnissen der eigenen Kollegen und der Kunden zu sein. Durch dieses Setup konnten wir den end-to-end-Grad auf bestimmt über 90% gehoben. Ein toller Erfolg, der jedoch auch einige Nachteile mit sich zieht. Im Gegensatz zum letzten Setup haben wir damit die Herausforderungen sogar erhöht, sodass jeder für sich selbst klar bekommen muss, bei welchem end-to-end Grad die “Reißleine“ gezogen wird.
  8. Wie bereits erwähnt gibt es keinen optimalen Blueprint für ein einzelnes Team. Es ändern sich lediglich die Herausforderungen und daher gilt es für sich selbst abzuschätzen, was das jeweils beste End-Setup eines Teams darstellt. Bei all seinen Vorteilen steigt mit diesem letzten Schritt die Gefahr der Ineffizienz, weil durch die Integration von „Run“ der Fokus aufgemacht wird und eine breite Anzahl von Themen gleichzeitig vorangetrieben wird und daher auch vermischt werden. Auch bedeutet, wie bereits zu Beginn des Vortrags angesprochen, das Streben nach einem hohen end-to-end Grad eine sehr breite Auswahl an Skills, die in der Regel in komplexeren Umgebungen zu einem sehr großen Team führt. All das mündet in diverse Zielkonflikte, die man für sich selbst und wo möglicherweise in jedem Team einzeln abwägen muss.
  9. Wenn wir Teams bei unseren Kunden schneiden, dann bedienen wir uns meist folgender Vorgehensweise. Zu aller erst geht es darum, die Mission des Teams in Form der leuchtenden Vision und den vorgegebenen Rahmenbedingungen zu definieren. Anschließend stellen wir uns die Frage, welche Skills es für die Umsetzung dieser Mission benötigt. Diese Skills reihen wir nach Priorität (wie wichtig sind die Skills für die Mission und wie häufig benötigen wir diese). Es ergibt sich so eine Reihung an Skills. Im nächsten Schritt füllen wir das Team der Reihe nach mit den wichtigsten Skills auf. Wir beginnen so bei den für die Mission am nötigsten Skills. Auch versuchen wir zu überlegen, welche Skills durch eine Person abgedeckt werden können. Was heute noch nicht möglich ist, kann durchaus ein Zielbild sein und mit einem Plan für den Wissenstransfer mittelfristig auch erreicht werden. Alle Skills, die nicht mehr ins Team passen (weil es schon zu groß geworden ist), können dann über einzelne Personen im Team ausgesteuert werden. Und ja, das ergibt Abhängigkeiten. Aber mit Hilfe dieses Vorgehens stellen wir zumindest sicher, dass die Abhängigkeiten nur jene Skills betrifft, die wir nicht häufig in unserem Entwicklungsprozess benötigen.
  10. In unserem realen Case haben wir nach mehreren Monaten für die meisten Teams ein Setup ohne Operations-Experten aus dem Business gewählt, da uns ansonsten die Teams zu groß geworden wären. Für einzelne Teams haben wir dieses Setup trotzdem bewusst gewählt, um so nah am Kunden zu sein. Auch in Teams, in denen Dev nicht so präsent war, wurden Fach-Operations-Experten integriert (ein Beispiel war das Social Media Team). Der vorerst letzte Schritt, der nach mehreren Monaten des Einschwingens gesetzt wurde, war die Anpassung der Organisationsstruktur an den vorläufig finalen Teamschnitt. Auf Grund der engen Zusammenarbeit von Business, IT-Dev und -Operations wurden diese Teams auch formal unter eine Berichtslinie gestellt. So konnten wir sicherstellen, dass fast alle für den Produkt und/oder den Prozess notwendigen Experten in eine Business Unit integriert waren. Dieser Schritt hat sehr dazu beigetragen, die Teams noch weiter auf ein gemeinsames Ziel einzuschwören, da es fortan nun eine Führungskraft gab, die dem Bereich vorstand und somit für alle gemeinsam den Weg klar machte. So verblieb in diesem konkreten Fall der Online Plattform lediglich der Core-IT Anteil in einer separaten Einheit über, die zentrale Funktionen für alle agilen Teams bereit stellte.
  11. Wenn ich eines als Learning mitgeben kann, dann folgendes: Die Mission des Teams bestimmt das Setup. All jene Ideen der fortlaufenden Integration von immer mehr Experten in ein Team sind gut und durchaus erstrebenswert – doch am Ende kommt es auf das jeweilige zu bearbeitende Vorhaben an, um zu bestimmen, was es genau in diesem Team braucht. Fakt ist: je breiter der Technologie-Stack, desto eher muss mit Vertretern und damit Abhängigkeiten gearbeitet werden, da sich diese Breite nicht mehr mit der Anforderung eines kleinen agilen Teams vereinbaren lässt. Dazu ein kleines Beispiel aus der Medizintechnik, indem wir ein Massenspektrometer mit Hilfe von agilen Teams entwickeln durften. Der Technologie-Stack ist hier so breit, dass es gerade zu unmöglich ist, alle Skills in einem Team zu haben. Nur um eine Vorstellung zu bekommen – für ein neues Produkt braucht es hier Biologen, Chemiker, Mechaniker, Mechatroniker, Elektroniker, Fertigungsingenieure, Softwareentwickler, User Interface Designer, Safety Engineers, usw.. Sie können sich vorstellen – das ist der reine Wahnsinn. Nach diversem Ausprobieren am Team-Setup hatten wir uns damals für die Aufteilung in Sub-Teams entschlossen, die aber allesamt Vertreter in ein Core-Team schickten, um dort agil in Iterationen fachübergreifende User Stories zu planen und zu committen. Wie bereits gesagt: am Ende bestimmt die Mission das Setup.