Meetup BizDevOps - Was Versicherungen von Banken lernen können (19.05.2020)
•Als PPTX, PDF herunterladen•
0 gefällt mir•563 views
Erfahrt in diesem Meetup, welche Vorteile es hat, wenn IT-Entwicklung, IT-Operations und die Fachseite in Unternehmen direkt kommunizieren und an einem Strang ziehen. Im Fokus steht, was Versicherungen bei der Einführung des BizDevOps-Ansatzes von Banken lernen können. Im Banking haben wir in den vergangenen Jahren eine Trendwende hin zur agilen Organisation beobachtet, unter anderem - durch die Agilisierung von Projekten und Inkubatoren, - die Weiterentwicklung von DevOps zu BizDevOps als multidisziplinäre Verknüpfung von IT & Business-Seite - und die (mitunter radikale) Transformation von einzelnen Großbanken zu agileren Organisationen. Versicherungen sind heute an dem Punkt, an dem Banken vor ein paar Jahren standen. Die Digitalisierung ist in der Branche angekommen und viele neue Wettbewerber wie Start-ups drängen in den Markt. Das Internet of Things, Blockchain-Technologie, Künstliche Intelligenz und Robotics ermöglichen Wettbewerbsvorteile in gesättigten Versicherungsmärkten oder lassen neue entstehen. Um diesen Wandel erfolgreich zu gestalten, können auch Versicherungen auf Agilität in ihren Organisationen und insbesondere auf den multidisziplinären BizDevOps-Ansatz setzen. BizDevOps ist eine Form der Teamzusammensetzung, um das End-to-End-Liefern zu erleichtern. Dabei arbeiten in einem Team Vertreter der Fachseite, also des Business (Biz), der IT-Entwicklung (Dev) und des IT-Betriebs (Ops) zusammen, um ein Produkt zu entwickeln.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Meetup BizDevOps - Was Versicherungen von Banken lernen können (19.05.2020)
Ähnlich wie Meetup BizDevOps - Was Versicherungen von Banken lernen können (19.05.2020) (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (6)
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.