Star Wars und Scrum-Teams (Teil I)

In dieser Blogreihe erläutern Oleksandra Skybina (Projektmanagerin & Leiterin der agilen Praxis) und Andrii Kulshan (Business Analyst & Product Owner) vom GlobalLogic-Entwicklungszentrum in Kharkiv die Struktur und Rollen eines agilen Scrum-Teams.

In einer weit, weit entfernten Galaxie baute eine Gruppe unwahrscheinlicher Helden das fortschrittlichste Produkt ihrer Zeit: den Todesstern. Ok, die imperialen Ingenieure von Darth Vader sind nicht gerade die Helden der Star Wars-Saga, aber sie sind ein großartiges Beispiel dafür, wie ein Scrum-Entwicklungsteam arbeitet – zusammen mit den Sturmtruppen und den Offizieren, die schnell auf die sich ändernden Anforderungen des Imperators (auch bekannt als Stakeholder) reagieren, die ihnen von Darth Vader (auch bekannt als Product Owner) und seinem Assistenten, den wir Mini Vader (auch bekannt als Business Analyst) nennen, übermittelt werden. In Teil I unseres Blogs werden wir die Rollen des Product Owner, des Business Analysten und der Stakeholder analysieren.

Product Owner

Der Product Owner (PO) ist eine Person, die als Kundenvertreter fungiert und die Ergebnisse der Arbeit des Entwicklungsteams präsentiert. Jeder kann als Product Owner fungieren: Business Owner, Tester, Business-Analysten usw. Wie in der obigen Abbildung dargestellt, ist der Verantwortungsbereich des Product Owners das Endprodukt. Zu seinen Aufgaben gehören:

Verwaltung des Backlogs: Der PO entscheidet, was in das Backlog (d. h. eine Liste von Aufgaben) aufgenommen wird und was nicht, welche Prioritäten die Aufgaben im Backlog haben und welchen Wert die Lösung für das Unternehmen haben wird.

Definieren des Minimum Viable Product (MVP): Der PO legt fest, welcher Teil des Produkts in kürzester Zeit mit einem Mindestmaß an Funktionen an Kunden und Endbenutzer geliefert werden kann.

Teilnahme an der Entwicklung: Der PO beantwortet die Fragen des Teams und nimmt an allen Scrum-Events teil, einschließlich der täglichen Versammlungen und der so genannten „Backlog Refinements“, bei denen der PO dem Team Aufgaben und Geschäftsfälle beschreibt, Informationen für die Qualitätsbewertung bereitstellt und Feedback zu Systemgrenzen einholt.

Vorführung des Produkts: Der PO führt das Produkt am Ende jedes Sprints den Stakeholdern vor und beschreibt detailliert die Funktionalität des Produkts und die Übereinstimmung mit den Geschäftsanforderungen. Er ist auch für die Schulung der Endbenutzer und die Erstellung der Dokumentation verantwortlich.

Den Stakeholdern „Nein“ sagen: Dies ist der wichtigste Aspekt der Arbeit des PO, da er die Ansprüche der verschiedenen Interessengruppen einholt. Oft sind Aufgaben und Ideen mehr, als ein Team in einem realistischen Zeitrahmen bewältigen kann. Es ist wichtig, nicht nur zu verschieben, sondern auch einige Ideen komplett zu verwerfen. Der PO muss Geschäftsanforderungen, Benutzerpräferenzen, Metriken, Prioritäten der verschiedenen Gruppen, Arbeitsbelastung und Spezialisierung der Teams, Markttrends und vieles mehr berücksichtigen. Man kann sagen, dass dies fast die zentrale Aufgabe des PO ist; auf der Grundlage seiner Erfahrung und seines Wissens muss der PO die Ideen auswählen, die das Projekt zum Erfolg führen werden. Manche POs treffen ihre Entscheidungen intuitiv, aber auch in diesem Fall müssen sie in der Lage sein, ihr „Nein“ allen Beteiligten zu erklären.

Business Analyst

Der Business Analyst (BA) setzt Ideen in Anforderungen um. Die Rolle des Business Analysten wird manchmal mit der des Product Owners verwechselt. Der Hauptunterschied besteht darin, dass der BA ein Beruf ist, während der PO eine Rolle in Scrum ist. Während der PO für die strategische Ausrichtung eines Produkts verantwortlich ist, ist der BA für die Taktik bei der Entwicklung des Produkts zuständig. An der Kreuzung dieser Bereiche überschneiden sich die beiden Rollen. Es ist nicht immer klar, wer die Business Cases schreiben, die ersten Anforderungen sammeln und sie dem Team mitteilen soll – vor allem bei ausgelagerten Produkten, wenn die Rollen nicht so verteilt sind, wie sie scheinen.

In Scrum-Projekten hilft der BA dem PO bei der Spezifikation der Anforderungen. Der BA kann entweder Teil eines Teams oder eine eigenständige Einheit sein, mit mehreren Teams zusammenarbeiten und die Anforderungen für verschiedene Module oder Teilprojekte beschreiben.

Natürlich ist die Rolle des BA nicht nur auf das Anforderungsmanagement beschränkt. Er kann auch auf die gleiche Weise mit Stakeholdern und Benutzern kommunizieren, den Markt analysieren und Hypothesen aufstellen (obwohl dies in einer ausgelagerten Umgebung nicht immer möglich ist). Wie in der nachstehenden Abbildung dargestellt, haben wir verschiedene Konfigurationen der Interaktion zwischen BA und PO sowie die Aufteilung ihrer Zuständigkeiten ermittelt.

Auf der Grundlage dieser Konfigurationen können Sie Ihre eigene Situation besser verstehen und wissen, wie Sie die Interaktion mit dem Kunden effektiver gestalten können. Betrachten wir jede Konfiguration im Detail.

BA-PO-Client (Produktgruppe)

Die erste Konfiguration ist perfekt. Wir haben den Business Analysten und den Product Owner, und wir haben den Kunden (Produktgruppe). Wenn der PO auch ein Teil dieser Produktgruppe ist (d. h. Entscheidungen treffen und den Aufgabenbereich beeinflussen kann), dann ist alles in Ordnung. Der BA legt die Anforderungen fest, der PO kümmert sich um die strategische Planung und sagt zu jedem „Nein“. Der Kunde ist glücklich und zufrieden, sowohl mit dem System als auch mit der Tatsache, dass das Team selbstorganisiert ist. Mit dieser Konfiguration können Sie dem Kunden einen vollständigen, autonomen Entwicklungszyklus anbieten, von der Idee bis zur Umsetzung.

BA/PPO (Proxy Product Owner)-Client

Dies ist eine gute Konfiguration für den Beginn eines Projekts, bei dem Sie noch nicht das Vertrauen des Kunden haben. Hier stellt der Kunde klar definierte Geschäftsanforderungen für alle Phasen des Projekts (d. h. die Roadmap) und eine Liste von Anforderungen (d. h. das Backlog) für jedes Team bereit. Der BA, der auch als stellvertretender Product Owner fungiert, verteilt diese Anforderungen einfach und überwacht ihre Bewertung und Umsetzung durch das Team. Im Laufe der Zeit und bei guten Beziehungen kann sich dieses Arbeitsmodell zur ersten Option (d. h. BA-PO-Client) entwickeln, die mehr Entscheidungsfreiheit bietet.

BA-PPO-Client

Dies ist wahrscheinlich die am wenigsten effektive Konfiguration, weil die Kette der Entscheidungsfindung und der Anforderungsüberprüfung gestreckt ist. Grob gesagt, ist der PPO für fast nichts zuständig, und der BA weiß nicht, was er tun soll – ob es möglich ist, den Kunden direkt zu kontaktieren, oder warum er den PPO braucht. Versuchen Sie daher, dieses Modell zu vermeiden.

BA-Client

Bei einem solchen Interaktionsmodell kommen die vorgefertigten Anforderungen von der Produktgruppe des Kunden, und der BA auf Ihrer Seite hilft nur bei der Ausarbeitung der lokalen Funktionalität und bestätigt ständig jede Änderung. Dieses Modell tritt auf, wenn der KundIn fast kein Vertrauen in das Team hat.

PO-Client

Es gibt den Kunden, es gibt die Produktgruppe, es gibt das Scrum-Team – und jedes Team hat einen Product Owner. Der PO erhält die Initiative von der Produktgruppe, bearbeitet Geschäftsfälle und Anforderungen und teilt sie dem Team mit. Da sowohl der PO als auch das Team große Entscheidungsfreiheit haben, gibt es in diesem Schema keinen BA, so dass der PO und das Team gemeinsam an den Aufgaben arbeiten müssen, die normalerweise vom BA übernommen werden. Nicht alle Teams sind mit der Aussicht auf das Schreiben von Anwendungsfällen zufrieden, so dass die Einführung eines solchen Schemas auf einigen Widerstand stoßen kann. Eine Übergangszeit zwischen BA – PO – Kunde ist oft erforderlich, aber eine erfolgreiche Umstellung erhöht sowohl die Effizienz des gesamten Teams als auch die Qualität der Entwicklung. Sie verkürzt auch die Reaktionszeit auf Änderungen der Geschäftsaufgaben.

Kurz gesagt, obwohl der Product Owner und der Business Analyst konzeptionell unterschiedlich sind, überschneiden sie sich in vielen Aufgaben. Um zu verstehen, wen Sie in einem Projekt brauchen, müssen Sie die Erwartungen des Kunden, sein Vertrauen in Sie, die Bedürfnisse des Teams und den Grad der Autonomie des Teams herausfinden.

Stakeholders

Der Begriff „Stakeholder“ ist in einem beruflichen Umfeld häufig anzutreffen. Man könnte meinen, es handele sich um eine einzelne Person oder einige wenige Personen, die immer das letzte Wort haben. Das ist oft der Fall, aber gleichzeitig umfasst dieser Begriff fast alle Teilnehmer an der Entwicklung, einschließlich:

Kunden: Das sind die Entscheidungsträger, Lieferverantwortlichen und Produktmanager im Kundenunternehmen. Es kann auch Leute im Marketing oder Vertrieb geben, die uns helfen können, zu verstehen, was getan werden muss, herauszufinden, was die Benutzer erwarten, und Marktanalysen zu liefern.

Interne/externe Benutzer: Je nachdem, welches Produkt Sie entwickeln, gibt es möglicherweise nicht nur Endnutzer, sondern auch eine große Gruppe von Fachleuten, die Ideen zur Verbesserung des Produkts haben.

Team: Dies ist das Entwicklungsteam, das das Produkt jeden Tag sieht und verbessert. Viele Leute machen den großen Fehler, nicht auf das Team zu hören, aber seine Meinung kann sehr wertvoll sein.

Verschiedenes: Ein Beispiel für einen „sonstigen“ Interessenvertreter ist eine externe Regulierungsbehörde. Wenn Sie im medizinischen oder finanziellen Bereich tätig sind, müssen Ihre Produkte Vorschriften, Regeln und Gesetze einhalten, die oft von speziellen Organisationen kontrolliert werden. Sie können auch interne Regulierungsbehörden zu dieser Gruppe hinzufügen, z. B. die Rechtsabteilung. Sie wirken sich nicht direkt auf die Funktionalität aus, können aber einige Einschränkungen mit sich bringen.

Wie können Sie verstehen, wie Sie mit jedem dieser Zielgruppen arbeiten können? Sie können mit einer Stakeholder-Einfluss-/Interessen-Matrix beginnen, wie sie unten abgebildet ist. Sie wird Ihnen helfen zu bestimmen, wo Sie eine bestimmte Gruppe von Interessenvertretern hinführen wollen und wie Sie den Prozess der Interaktion mit ihnen organisieren können.

Enge Verwaltung: Zu diesem Quadranten gehören die Stakeholder, die einen großen Einfluss haben und am meisten an dem Produkt interessiert sind. Sie müssen zuerst mit dieser Gruppe von Interessengruppen arbeiten.

Zufriedenheit bewahren: Zu diesem Quadranten gehören die Stakeholder, die nicht besonders an dem Produkt interessiert sind, aber einen großen Einfluss haben. Dies können die gleichen externen Regulierungsbehörden oder Leiter von Rechtsabteilungen sein. Sie müssen dafür sorgen, dass sie zufrieden sind, indem Sie dem Produkt die erforderlichen Funktionen hinzufügen.

Auf dem Laufenden bleiben: Zu diesem Quadranten gehören Stakeholder, die sehr an dem Produkt interessiert sind. Sie haben in der Regel eine Menge Ideen, aber nur wenig Einfluss auf das Projekt. Sie sollten sich nicht vor den Kopf gestoßen fühlen, also müssen wir sie informieren.

Überwachen: Zu diesem Quadranten gehören Stakeholder, die nicht interessiert sind und keinen Einfluss auf das Projekt haben. Es ist jedoch notwendig, sie manchmal zu beobachten, weil sie plötzlich in eine der anderen Gruppen übergehen können oder nützliche Ideen äußern.

In Teil II dieser Blogserie werden wir einen Blick auf die verschiedenen Rollen und Verantwortlichkeiten des Entwicklungsteams werfen, einschließlich der Rollen von Scrum Master und Manager.