Der Business Analyst in einem agilen Umfeld bei Versicherungen

Was macht ein Business Analyst?

Jeder von euch kennt sicherlich Business- Analysten (BAs), Informationsverarbeitungskoordinatoren (IVKs) oder Fachbereichsberater (FBBs). Doch was steckt genau hinter diesen Tätigkeiten – vor allem im Versicherungsbereich? Sie bilden bei kleinen, mittleren und großen Versicherungen in der Regel die Schnittstelle zwischen den Fachbereichen und den IT-Abteilungen. Zu ihren Tätigkeiten gehört klassischerweise die Erhebung und Verwaltung von fachlichen Anforderungen. Ein wichtiger und nicht zu unterschätzender Bestandteil ist die Einschätzung (Analyse) der Wirtschaftlichkeit dieser Anforderungen, um den Wert der Softwareprodukte zu erhöhen. Zudem sind die fachlichen Anforderungen so aufzubereiten und zu übersetzen, dass diese von Entwicklern verstanden und umgesetzt werden können.

Was ist ein agiles Team nach Scrum und wo ist dort der Business Analyst?

Die digitale Transformation wird von Versicherungen sukzessive vorangetrieben. Um den Kunden mit seinen Bedürfnissen in den Mittelpunkt zu stellen, wird immer öfter eine agile Vorgehensweise gewählt und häufig Scrum als Rahmenwerk genutzt. Wie ihr sicherlich wisst, besteht ein Scrum-Team aus dem Product Owner, dem Scrum Master und dem Entwicklerteam. Laut Scrum Guide ist der Product Owner innerhalb des Scrum Teams das Sprachrohr von innen nach außen und von außen nach innen. Er ist zudem für die Produktvision und somit für die Anforderungsaufnahme aus den Fachabteilungen verantwortlich. Außerdem schätzt der Product Owner die Wirtschaftlichkeit der Anforderungen ein, um den Wert des Produktes zu maximieren. Diese Aufgabe sollte sich in der Priorisierung im Backlog widerspiegeln. Die Anforderungen werden dem Entwicklerteam zunächst vom Product Owner − beispielsweise in Form von User Stories – vorgestellt, damit eine anschließende Umsetzung erfolgen kann.

Nun stellt ihr euch sicherlich die Frage, ob hier Business Analysten überhaupt noch notwendig sind – schließlich werden deren Kernaufgaben ja durch den Product Owner übernommen. Es ist aber durchaus Platz für Business Analysten vorhanden. Mit ihrer Arbeit können sie ein Scrum Team sogar bereichern.

Welche Aufgaben haben Product Owner bei Versicherungen heute tatsächlich?

Ich habe die Erfahrung gemacht, dass der Product Owner in der Praxis von der Organisation oftmals noch als klassischer Projektleiter gesehen wird. Insbesondere bei Versicherungskonzernen, die am Anfang der digitalen Transformationen stehen, werden von einem Product Owner − neben seinen eigentlichen Aufgaben − zusätzlich eine Vielzahl von weiteren Tätigkeiten erwartet. Neben dem Stakeholder Management sind aufgrund klassischer Budgetierungsprozesse oftmals auch noch Gremienarbeiten erforderlich wie Vorstellungen in Lenkungs- und Serviceausschüssen. Ebenfalls sind die organisatorischen Tätigkeiten – etwa das Ausfüllen von klassischen Projektplänen und das Berichten in die Linie – als zeitlicher Aufwand nicht zu unterschätzen.

Ihr wisst sicherlich, dass die agile Softwareentwicklung in der Regel in kurzen Entwicklungszyklen von einer bis zu vier Wochen erfolgt. Wie ihr erahnen könnt, stellen diese vergleichsweise kurzen Zeiträume einen Product Owner, der zusätzlich auch noch Projektleitertätigkeiten übernimmt, vor große zeitliche Herausforderungen. Der Product Owner hat schließlich nur einen engen Zeitrahmen zur Verfügung, in dem Anforderungen erhoben, ausgearbeitet, priorisiert und dem Entwicklerteam vorgestellt werden müssen. Hinzu kommt, dass die Rolle des Product Owners oftmals durch ehemalige Projektleiter übernommen wird. Einem unerfahrenen Product Owner kann somit durchaus die fachliche Tiefe und das technische Verständnis für das eigene Produkt fehlen. Dies kann dazu führen, dass das volle Potenzial des Produktes nicht ausgeschöpft werden kann, da Anforderungen vom Wert und Aufwand falsch eingeschätzt oder priorisiert werden.

Eine Nische für Business Analysten?

Kommen wir zurück auf die Frage, ob ein Business Analyst überhaupt noch Platz in einem agilen Team hat. Ich gehe davon aus, dass der Einsatz von Business- Analysten in einem agilen Team durchaus Mehrwerte für das Entwicklerteam sowie für den Product Owner bietet – insbesondere, wenn die Organisation noch nicht vollständig agil arbeitet. Meiner Meinung nach können Business Analysten vor allem an den Schnittstellen, an denen die Organisation noch nicht agil arbeitet, unterstützen. Außerdem können sie den Product Owner in den Punkten entlasten, bei denen es um die fachliche Ausarbeitung geht.

Unterstützung des Entwicklerteams

Das gilt vor allem für den Versicherungsbereich, denn Versicherungen haben oftmals eine historisch gewachsene, heterogene Systemlandschaft. Dieser Umstand führt dazu, dass neue Produkte häufig viele Schnittstellen anbinden müssen. Dadurch entstehen starke Abhängigkeiten, die sogar über den Erfolg oder Misserfolg eines Produktes entscheiden können. Dies kann insbesondere dann zu Reibungen führen, wenn neue Produkte agil und bestehende Produkte klassisch an Release-Zyklen gebunden entwickelt werden. Ebenfalls kann ein Business Analyst das Entwicklerteam bei der oft ungeliebten, aber notwendigen Dokumentation unterstützen und nur bei konkreten Fragestellungen auf das Entwicklerteam zugehen.

Aus meiner Erfahrung kann ich sagen, dass ein Business-Analyst vor allem für diese Aufgaben nicht wegzudenken ist:

• Support bei der fachlichen Ausarbeitung von Schnittstellen
• Übernahme der Schnittstellendokumentation
• Unterstützung bei der Abstimmung mit anderen Bereichen
• Unsicherheiten des Entwicklerteams im Hinblick auf die Auflösung von Schnittstellen
• Unterstützung bei der Sicherheits- und Freigabedokumentation
• Dokumentation von fachlichen Features

Unterstützung des Product Owners

Einem Product Owner fehlt aufgrund paralleler Projektleitertätigkeiten und kurzen Entwicklungszyklen oftmals die Zeit, sich intensiv mit den fachlichen Themen auseinanderzusetzen. Hier können Business- Analysten den Product Owner bei folgenden Tätigkeiten unterstützen und entlasten:

• Bei der iterativen Erhebung von Anforderungen und der Erstellung von User Stories
• Bei der Unterbreitung von entsprechenden Priorisierungsvorschlägen
• Bei der Vermittlung von Inhalten an das Entwicklerteam

Beitrag zur Verbesserung der Produktqualität

Da Business Analysten die Fachlichkeit sehr gut kennen, tragen sie auch zur Erhöhung der Qualität des Produktes bei. Denn insbesondere im Testbereich sind fehleranfällige Konstellationen für Entwickler und Fachbereiche häufig nur schwer erkennbar. Für Business-Analysten könnten hier folgende Aufgaben anfallen:

• Erstellung von Testfällen und Testszenarien
• Erkennen von Negativtestfällen
• Durchführungen von Testfällen und exploratives testen

Was sollte ein Business Analyst in einem agilen Umfeld vermeiden?

Agile Business Analysten sollen sich als Dienstleister sehen und dem Entwicklerteam die Möglichkeit geben, Fachlichkeit und Anwender besser zu verstehen. Business Analysten sollten daher kein fachliches Kopfmonopol darstellen, sondern das Entwicklerteam fachlich coachen und ihm vor allem auch die Möglichkeit geben, an notwendigen Entscheidungen mitzuwirken.

Ich denke, dass ein Team nur gemeinsam die besten Entscheidungen trifft. Ein Business-Analyst sollte daher sein Ego zurücknehmen, als Teammitglied entsprechend offene Diskussionen führen und auch für alternative Lösungsmöglichkeiten offen sein. Dies betrifft auch Bereiche die klassischerweise in der „Hoheit“ von Business- Analysten liegen – etwa Prozessmodellierung oder Serviceschnitte.

Business Analysten sollten auch kein Mikromanagement betreiben. Die für das Erreichen des Sprintziels erforderlichen Aufgaben, die Sprintplanung und das Sprint-Backlog sollte gemeinsam mit dem Entwicklerteam festgelegt werden. Business-Analysten sollten jederzeit für Verständnisfragen, fachliche Fragestellungen und Feedback aus dem Entwicklerteam offen sein.

Fazit

Wie ihr seht, können Business Analysten durchaus eine echte Unterstützung in einem agilen Team sein. Sie können ihre in klassischen Projekten gesammelte Methodenerfahrung und auch ihre Softskills einbringen. Dadurch kann der Product Owner sowie das Entwicklerteam insbesondere an den Stellen unterstützt werden, an denen die Organisationen noch nicht agil arbeitet und bei den Punkten, bei denen es um die fachliche Ausarbeitung geht.

Da die Kommunikation in agilen Projekten direkt und persönlich innerhalb eines Teams erfolgt und nicht über detaillierte Fachkonzepte oder –spezifikationen, eignen sich solche Projekte besonders für Business Analysten. Hier können sie ihr fachliches und methodisches Wissen um ein technisches Verständnis erweitern.