Die Versicherungsbranche in Europa ist heute an dem Wendepunkt angekommen, den die Banken in Deutschland in den vergangen Jahren versucht haben, zu meistern. Sie müssen zu Technologieunternehmen am Puls der Zeit werden. Um diesen Wandel erfolgreich zu gestalten, setzen viele Versicherer in ihren IT-Projekten auf Agilität. Sie laufen dabei aber Gefahr, eine für die agile Arbeitsweise essentielle Eigenschaft des Entwicklungsteams zu übersehen: die multidisziplinäre Zusammensetzung. Das bedeutet, dass das Projektteam mit allen für die Umsetzung notwendigen Mitarbeitern der verschiedenen „Disziplinen“ bzw. Bereiche des Unternehmens besetzt sein sollte, wie beispielsweise IT-Entwicklung, IT-Betrieb, die Fachbereiche, Aktuariat etc.Doch häufig werden die Projektteams nach dem klassischen Rollenverständnis besetzt, indem in der Regel geeignete Projektleiter gesucht, die besten Entwickler für die Umsetzung ausgewählt und ein ScrumMaster eingekauft wird.Bereits 1986 beschrieben Nonaka und Takeuchi in ihrem Artikel „The New New Product Development Game“ die Bedeutung von multidisziplinären Teams, die sich gemeinsam für ein Produkt verantwortlich fühlen und zwar vom Start der Entwicklung bis zum Verkauf. Die Diversität und Kombination der jeweiligen Expertisen im Team steigern nicht nur die Wahrscheinlichkeit des Produkterfolgs, sondern es findet automatisch ein Knowhow-Transfer im Team statt, von dem nicht nur die Teammitglieder auf individueller Ebene profitieren. Denn das neuerlangte Wissen ist gefragt, wenn sie einen Kollegen in seiner Abwesenheit vertreten können. Was Nonaka und Takeuchi durch diesen Ansatz erreichen wollten, ist das Aufbrechen von Silos in der Entwicklung, IT-Betrieb und Vermarktung von Produkten jeglicher Art.
Für eine schnelle und iterative Arbeitsweise werden also nicht nur IT-seitig Frontend- und Backendentwickler (Development) benötigt, sondern es ist auch notwendig, den IT-Betrieb (Operations) einzubeziehen sowie die Fachabteilungen (Business), die die Anforderungen an das Produkt stellen. Der DevOps-Ansatz zur Besetzung von Teams ist ein erster Schritt in diese Richtung, denn er vereint die für den Betrieb (Ops) benötigten Kompetenzen mit dem Entwicklungsteam (Dev).Ich möchte jedoch noch einen Schritt weiter gehen. Denn die nächste Herausforderung für die DevOps-Teams lauert nur um die nächste Ecke. Die Anforderungen an die Produkte, z.B. an einen Online-Tarifrechner, werden häufig in einer dem Projekt vorgelagerten Analysephase in Fachabteilungen (der Business-Seite) schriftlich vorformuliert, ohne jegliche Einbindung des späteren Entwicklungsteams. Da können die Entwickler ein Jahr später, wenn sie endlich freie Kapazitäten für die Umsetzung haben, noch so sehr versuchen, die schriftlichen Anforderungen zu verstehen bzw. zu interpretieren.Es wird immer ein bisschen sein, als würden sie versuchen, ein Soufflé anhand der schriftlichen Anleitung eines Restaurantgastes zuzubereiten, ohne das Endprodukt jemals vorab gesehen oder gar probiert zu haben. Und haben wir in diesem Prozess, in dem wir völlig damit beschäftigt sind, die schriftlichen Anleitungen zu verstehen und richtig umzusetzen, die Zeit, uns damit auseinanderzusetzen, ob ein Soufflé wirklich die Bedürfnisse des Users befriedigt? Wohl eher nicht. Es kann also sein, dass wir es schaffen, das für uns perfekte Soufflé herzustellen, dieses aber trotzdem nicht gekauft bzw. genutzt wird.
Klassische Produktentwicklung: Klare Trennung zwischen Fachbereich, IT Entwicklung und Betrieb.
Eine Lösung für unser IT-Soufflé-Problem ist der BizDevOps-Ansatz. Hinter diesem mysteriösen Akronym versteckt sich nichts anderes als die wertschöpfende Zusammenarbeit von Business-Seite (Biz), IT-Entwicklung (Dev) und IT-Betrieb (Ops) an der Entwicklung eines Produkts und zwar nicht sequentiell, sondern synchron. So entsteht ein multidisziplinäres Scrum-Team, aus Entwicklern sowie aus Experten des Fachbereichs, das gemeinsam an der Entwicklung arbeitet. Im Unterschied zu den klassischen Scrum-Teams holt BizDevOps die Business-Seite, die für die Vorgaben der Entwicklung verantwortlich ist und die Anforderungen an das Projekt definiert, mit ins Team. Anstatt in einer der Entwicklung vorgelagerten Phase Fachvorgaben herunterzuschreiben, setzt sich das Team gemeinsam mit den aktuellen Bedürfnissen der User auseinander, bricht die Funktionalitäten in User Storys herunter und liefert diese iterativ Sprint um Sprint. Auch technisch liegt die Lösung in einer Hand. Wir brauchen kein Handover mehr zwischen Fachabteilung, Entwicklung und Betrieb, da alles bei einem Team liegt.
Moderne Produktentwicklung: Fachbereich, IT Entwicklung und Betrieb arbeiten zur gleichen Zeit gemeinsam an einem Produkt.
Was gewinnen Sie als IT-Projektleiter durch diesen Ansatz? Auf den ersten Blick benötigen Sie mehr Mitarbeiter in Ihrem Projekt. Dann jedoch gewinnen Sie an Umsetzungs- und Reaktionsgeschwindigkeit. Denn durch die Verschmelzung der Marktanalyse-, Planungs- und Entwicklungsphase können Sie in Ihrem Projekt viel schneller auf Veränderungen im Verhalten der Kunden oder der Rahmenbedingungen reagieren. Zudem ersetzen Sie die Entwicklungsphasen, die bisher Monate oder gar Jahre auseinanderliegen, durch Sprints und reduzieren so die Verschwendung der zwei wertvollsten Ressourcen, Zeit der Mitarbeiter und Geld:
Neben der Reduktion der Verschwendung wertvoller Ressourcen liefert Ihr Projekt mit dem BizDevOps-Ansatz zudem einen größeren Mehrwert für Ihr Unternehmen, nämlich in Form von attraktiven, auf die Kunden zugeschnittenen Produktangeboten. Das multidisziplinäre Team mit seinen verschiedenen Expertisen und Blickwinkeln identifiziert gemeinsam die Probleme der Kunden. Mithilfe ihrer unterschiedlichen Skill-Sets und Knowhows entwickeln die Teammitglieder die diversesten Lösungsansätze und finden häufig eine Möglichkeit der Umsetzung, die mit geringerem Ressourceneinsatz dem Kunden einen größeren Nutzen bringt. Zudem werden sie zu Experten für ihre Problemlösung und übernehmen dadurch automatisch mehr Verantwortung für den Erfolg des Produkts.Ich freue mich, wenn Sie am 19. Mai bei unserem Meetup “BizDevOps – Was Versicherungen von Banken lernen können” mitdiskutieren.
Titelbild: Pexels License, Pixabay