Als Engagement Manager bei OutSystems unterstütze ich Kunden dabei, die Ergebnisse agiler Ansätze mit unserer Low-Code-Entwicklungsplattform zu maximieren. Dabei begegnet mir oft die Frage: Worin besteht in einem agilen Team der Unterschied zwischen einem Product Owner und einem Business Analyst? Und darauf folgt meist: Ist es für ein erfolgreiches Projekt erforderlich, beide Rollen zu haben?
Entdecken Sie, wie Low-Code bei der Beschleunigung agiler Praktiken von Vorteil ist
Auf die erste Frage kann ich keine kurze Antwort geben, auf die zweite aber schon: Es kommt darauf an. Ich habe gesehen, dass agile Projekte mit Geschäftsanalysten, die als Product Owner agieren, erfolgreich waren. Ebenso habe ich aber auch Projekte gesehen, die keinen designierten Produktverantwortlichen hatten und gescheitert sind.
Das liegt daran, dass jedes agile Entwicklungsprojekt seine eigenen Herausforderungen mit sich bringt. Das vergessen wir oft. Manchmal ist zu Beginn des Projekts der Umfang nicht klar. Manchmal ist der Zeitplan herausfordernd oder sogar unrealistisch. Manchmal fehlen die richtigen Teammitglieder, um den Erfolg des Projekts zu gewährleisten. Und manchmal trifft alles drei zu.
In der Welt der Agilität hängt der Erfolg stark von der Fähigkeit ab, effizient und effektiv zu kommunizieren. Störungen in der Kommunikation können zu schlechten Ergebnissen führen, wie z. B.:
- Ergebnisse, bei denen zentrale Features fehlen
- Ergebnisse, bei denen Schlüsselfunktionen innerhalb der Features fehlen
- Ergebnisse, die unerwünschte zusätzliche Features und/oder Funktionalität enthalten
- Ergebnisse, denen es an Qualität mangelt (Bugs)
- Projektverzögerungen
Die Notwendigkeit, einen Product Owner, einen Business Analyst oder beides zu haben, hängt von den Besonderheiten des jeweiligen Projekts ab. Ihnen sind die oben genannten Fragen schon einmal durch den Kopf gegangen? In diesem Blogbeitrag gehe ich darauf ein, welche Rollen und Verantwortlichkeiten Product Owner und Business Analyst haben und ob bzw. wo sich die beiden Rollen überschneiden.
Was ist ein Product Owner?
Der Product Owner, oder PO, ist entscheidend für den Gesamterfolg des Projekts. Diese Rolle arbeitet direkt mit dem Unternehmen zusammen, um projektbezogenes Wissen zu erlangen und die geschäftlichen Gründe dafür zu liefern, warum bestimmte Features entwickelt werden. Er oder sie kann dabei helfen, die Vision des Produkts zu entwickeln, ohne sich um die technische Umsetzung kümmern zu müssen. Außerdem dient ein Product Owner als Stimme des Unternehmens und als zentraler Ansprechpartner, um eine gemeinsame Linie zu finden, Fragen zu klären, einen Konsens zu erzielen und Entscheidungen voranzutreiben.
Was macht ein Product Owner?
Die Verantwortlichkeiten eines Produktverantwortlichen umfassen:
- Definieren der Geschäftsstrategie
- Ausrichtung auf Kundenbedürfnisse
- Sicherstellen des geschäftlichen Engagements
- Verwalten des Produkt-Backlogs
- Vermitteln von Erwartungen
- Akzeptieren von Funktionen und User Stories
- Bei Bedarf Eskalieren von Problemen
Der PO wird häufig mit Scrum-Praktiken assoziiert. Doch um nicht vom Thema abzukommen, werde ich an dieser Stelle nicht auf die Unterschiede zwischen Agile und Scrum eingehen.
Was ist ein Business Analyst?
Der Business Analyst, or BA, ist dagegen dafür verantwortlich, den Wunsch des Kunden mit dem abzugleichen, was das Team produziert. Der BA fungiert als Bindeglied zwischen dem geschäftlichen und dem technischen Team, sucht nach Lücken und analysiert Auswirkungen. Während der PO auf der geschäftlichen Seite steht, agiert der Business Analyst eher auf der Seite des technischen/agilen Teams. Meist sind letztere in technischer Analyse und Design ausgebildet, wodurch sie weniger betriebswirtschaftliches Wissen besitzen als ein PO, dafür aber technisch versierter sind.
Was macht ein Business Analyst?
Vom BA wird Folgendes erwartet:
- Definieren der Projektanforderungen
- Fokus auf dem Projekt halten
- Verstehen und Definieren der Bedürfnisse der Stakeholder
- Erleichterung des Austauschs zwischen Business und IT
- Analysieren der technischen und geschäftlichen Auswirkungen
- Identifizieren und Schließen der Lücken zwischen Kunden und Entwicklungsteam
- Abstimmung mit dem Product Owner, um die Produktvision zu kommunizieren
Business Analyst vs. Product Owner
Einfach ausgedrückt: Der Product Owner ist die Stimme des Kunden und der Business Analyst vertritt das Entwicklungsteam. Doch in der Realität ist die Trennung zwischen den beiden Rollen nur selten so eindeutig.
Der PO ist eher geschäfts- und kundenorientiert, während der BA oft taktischer und auf das Projekt fokussiert ist. Doch seine Ausbildung und Kompetenzen qualifizieren einen BA meist auch dafür, einige Aufgaben des PO zu übernehmen. Dazu gehören die meisten Funktionen der Backlog-Verwaltung, das Aufteilen von großen Storys in kleinere, die Modellierung von Arbeitsabläufen und Daten, die Definition von Geschäftsregeln und die Behandlung nicht-funktionaler Anforderungen. So kommt es, dass sich die beiden Rollen oft überschneiden.
Das wirft die Frage auf: Brauchen Sie wirklich beide Personas für eine erfolgreiche Einführung agiler Methoden? Kann ein Business Analyst den Product Owner nicht ersetzen? Im nächsten Abschnitt will ich diese Frage anhand von Praxisbeispielen beantworten.
Der Product Owner als agiler Superheld?
Vor kurzem habe ich mich mit einer Kollegin getroffen, die viele agile Projekte erfolgreich durchgeführt hat. Sie erinnerte sich daran, dass sie im Laufe der Jahre an mehreren Projekten ohne PO gearbeitet hat, und erzählte Folgendes:
„Bei einem Projekt haben wir eine bestehende Applikation mit einer anderen Technologie umgeschrieben. Da wir gerade eine App von einer Technologie auf eine andere migrieren wollten, meinten die Kunden, dass ein PO nicht notwendig wäre.Sie waren der Meinung, dass die Analyse und das Reverse-Engineering der aktuellen Apps für die Erstellung der neuen Apps ausreichen würden. Aufgrund von Verzögerungen beim Sammeln der benötigten Informationen aus verschiedenen Kanälen waren Sprints oft nicht bereit, User Stories wurden während des Sprints blockiert, und es mussten Annahmen gemacht werden. Dies führte später zu Nachbesserungen und wirkte sich [negativ] auf die Lieferung aus.“
Die Realität sieht so aus: Für ein agiles Team ist es eine Herausforderung, die geschäftliche Seite des Projekts ohne einen PO zu überbrücken. Die Projektvision, die Haupttreiber und die Erfolgskriterien fehlen häufig, sind schlecht definiert oder basieren auf der Perspektive der IT statt auf der des Endbenutzers. Letztlich steigert der PO den Wert des Produkts, indem er Einblicke liefert, was mit dem Produkt erreicht werden soll.
Dieselbe Kollegin erinnert sich auch an die Arbeit an Projekten mit ineffektiven POs:
„[Wir hatten] ein Projekt, bei dem eine HR-App für Onboarding und Offboarding entwickelt wurde. Der Projektmanager des Kunden versuchte, der PO für diese App zu sein. Die erste Version war ein totaler Flop, weil sie nicht den Bedürfnissen der Endanwender entsprach. Die verschiedenen Endanwenderteams delegierten schließlich eine Person aus ihrem Team, um Input für den PM zu liefern. Nach mehreren weiteren Versionen wurde die App schließlich ein großer Erfolg.“
Im ersten Beispiel hat sich niemand zu Wort gemeldet, wodurch das Projekt beeinträchtigt wurde. Im zweiten Beispiel war der PO ineffektiv, aber das Team unternahm die richtigen Schritte, um das Problem zu beheben. Die Essenz aus diesen beiden Beispielen ist: Es muss eine oder mehrere engagierte Personen von Seiten des Unternehmens geben, die diesem Einsichten bietet und für Engagement und Kommunikation sorgt. Diese Person sollte die Vision für die App liefern können. Wenn das nicht möglich ist, muss sie mit Teammitgliedern zusammenarbeiten, die ihr helfen können, die Vision zu definieren, um die zugrunde liegenden Anforderungen des Unternehmens zu erfüllen.
In einem positiven Beispiel erinnert sich eine andere Kollegin an ein äußerst erfolgreiches Projekt, das ohne einen PO begann. Sie berichtet:
„Die QA-Abteilung wollte Zeit sparen, die SLAs verbessern und hat die Aufsicht über die eigene Arbeit verstärkt, aber hatte keine Zeit. Wir haben einen ihrer Admins zum BA ausgebildet, und die Person wurden de facto zum PO: Sie war für die Erfassung und Klärung von Anforderungen zuständig. [Dadurch] war diese App sehr erfolgreich, und wir hatten Messwerte, wie sich die SLAs mit dem neuen Prozess und der neuen App verbessert haben.“
Die Erkenntnis ist wieder derselbe: Es ist möglich, mit einem agilen Team ohne PO gute Ergebnisse zu erzielen. Der BA kann diesen durchaus ersetzen, solange er in der Lage ist, die Rolle des PO zu übernehmen. Dies erfordert jedoch Unterstützung, Engagement, Detailgenauigkeit und gute Kommunikation. Der Schlüssel zum Erfolg besteht darin, den Kontext der App und die zugrunde liegenden Geschäftsbedürfnisse zu verstehen. Um dies zu erreichen, muss das Unternehmen die wichtigsten Anwender und Stakeholder identifizieren und sicherstellen, dass diese schnell verfügbar sind und bei der Bereitstellung dieses Kontexts helfen. Sie sollten in der Lage sein, ihre Wünsche, Bedürfnisse und aktuellen Pain Points zu formulieren. Erst dann kann das Projektteam damit beginnen, den vom Unternehmen angestrebten Wert zu extrapolieren.
Schlussbemerkungen
Letztlich wird ein agiles Team immer von einem erfahrenen PO profitieren. Die entsprechende Person sollte in die erwähnten Aufgaben erledigen können und zudem Klarstellungen liefern und Entscheidungen vorantreiben. Das Ergebnis sollte ein effizienteres Team und ein effektiveres Produkt sein. Feedback von wichtigen Anwendern in das Produkt einzubeziehen, hat oberste Priorität.
Wenn der PO über keine angemessenen Fachkenntnisse verfügt – wie im Falle des BA –, dann muss er die Hauptanwender identifizieren (oder mit dem Unternehmen daran arbeiten), so viele Informationen wie möglich sammeln und sicherstellen, dass diese in das Produkt eingearbeitet werden. Letztlich geht es darum, den Kontext der App und das Gesamtbild zu verstehen. Nun brauchen Sie noch Engagement und gute Kommunikation – und schon haben Sie Ihren agilen Superhelden.
Übrigens: Wenn Sie mehr über die Technologien und Ansätze erfahren möchten, in die Unternehmen mit höherem agilen Reifegrad investieren, empfehle ich Ihnen den Report zum Status quo der Applikationsentwicklung 2019.
Nutzen Sie OutSystems jetzt!
Erstellen Sie Ihre erste App in wenigen Minuten.
Mit der kostenlosen Free Edition.
