Betrachten wir ein Softwareentwicklungsprojekt für einen externen Kunden. Die Entwicklungsfirma (der Anbieter) hat die üblichen Positionen und Spezialisten: Entwickler, Tester, Business-Analysten, Manager. Das Projekt wird mit Scrum durchgeführt. Wie arbeitet ein Business Analyst in einem Scrum Team? Wie fügen sie sich in den agilen Workflow des Scrum-Teams ein? Sollte ein Scrum Team überhaupt einen Business Analyst haben?
Wie kann die Beteiligung des Business-Analysten kontinuierlich und mit Sprints synchronisiert werden?
Sie müssen dem Entwicklungsteam mindestens einen Sprint voraus sein, damit im Planungsmeeting die Anforderungen fertig, klar definiert, klar zerlegt usw. sind. Der Business Analyst (BA) wird dann zum Proxy PO. Aber in diesem Fall fragen die Entwickler den BA, wie das Produkt zu implementieren ist, anstatt den PO, Stakeholder oder Benutzer zu fragen.
Wenn sie die Anforderungen gemeinsam mit den Entwicklern im Planning Meeting besprechen und sie dann aufschreiben, während die Entwickler sie umsetzen, dann werden die BAs eher zu Technischen Redakteuren.
Die kanonisch korrekte Lösung besteht darin, jemanden mit Geschäftsanalysefähigkeiten in einer Entwicklerrolle in das Scrum-Team zu stellen und dann das gesamte Scrum-Team zu schulen. Die gegenseitige Befruchtung von Fähigkeiten verbessert die Fähigkeiten des Scrum-Teams und der Entwickler und baut T-förmige Menschen auf.
Das Einbeziehen von jemandem, der sich mit Geschäftsanalysen auskennt, in das Scrum-Team erleichtert auch die Zusammenarbeit bei der Analyse von Anforderungen und der Identifizierung pragmatischer technischer/architektonischer Lösungen, anstatt Ihren Prozess zu verrohren und die Entwicklung als „nachgelagert“ von Big, Upfront Design (BUFD) zu behandeln. BUFD steht inhärent im Widerspruch zum empirischen Steuerungsprozess von Scrum, bei dem iterative Entwicklung, emergentes Design und Just-in-Time-Planung entscheidende Komponenten sind.
Im Scrum-Team-Abschnitt des 2020 Scrum Guide heißt es:
Scrum-Teams sind funktionsübergreifend, was bedeutet, dass die Mitglieder über alle erforderlichen Fähigkeiten verfügen, um in jedem Sprint Wert zu schaffen.
Das heißt, Sie können Ihrem Scrum-Team gerne jemanden hinzufügen, der sich mit Geschäftsanalyse auskennt , aber aus Sicht der Scrum-Rollen ist er einfach einer der Scrum-Entwickler. Es gibt absolut keine anderen Rollen in einem Scrum-Team als Product Owner, Scrum Master und Entwickler.
Eine andere Antwort legt nahe, dass die Geschäftsanalyse externalisiert werden könnte. Aus rein pragmatischer Sicht können Sie dies möglicherweise tun, mit zwei Einschränkungen:
Der Product Owner wäre dann für die Geschäftsanalyse verantwortlich, weil:
Der Product Owner kann die oben genannten Arbeiten ausführen oder die Verantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner verantwortlich.
Wenn der Workflow externe Abhängigkeiten enthält, verfügt das Scrum-Team nicht mehr über alle erforderlichen Fähigkeiten, um die Arbeit selbst zu verwalten, und dies kann die Agilität und Anpassungsfähigkeit beeinträchtigen .
Unvermeidbare Externalitäten sind ... nun ja, unvermeidbar. Das bewusste Herstellen einer externen Abhängigkeit erscheint jedoch kontraproduktiv.
Hier gibt es zwei Antworten – die Scrum-Antwort und die meine praktische Antwort.
In Scrum gibt es drei „Verantwortlichkeiten“ (vor der Überarbeitung vom November 2020, Rollen) in einem Scrum-Team – Scrum Master, Product Owner und Developer. Ein Team hat einen Scrum Master, einen Product Owner und jeder passt in einen dieser Buckets. Wenn jedoch mehrere Teams an einem einzigen Produkt arbeiten, wird der Product Owner auf das Produkt abgestimmt und von allen Teams gemeinsam genutzt. Basierend auf Ihrer Beschreibung klingt es so, als ob sich die Arbeit des Business Analysten und die Dinge, die der Product Owner zu tun pflegt, stark überschneiden, aber der BA ist nicht in der Lage, seine Entscheidungen von der Organisation respektieren zu lassen, und jemand anderes ist es letztendlich verantwortlich für die Entscheidungen bezüglich der Produktausrichtung.
Basierend auf der Definition in Scrum glaube ich, dass Scrum den Aufwand für Produktmanagement und -entdeckung stark unterschätzt.
Der Scrum Guide sagt, dass der „Product Owner eine Person ist, kein Komitee“. Angesichts der Art des Produktmanagements und des enormen Umfangs – Marktanalyse, Wettbewerbsanalyse, Geschäftsanalyse, Anforderungsanalyse, Kommerzialisierung, Verkauf, Terminplanung, Budgetierung und mehr – glaube ich nicht, dass es vernünftig ist, von einer Person zu erwarten, dass sie dazu in der Lage ist geh damit um. Dies wird noch verstärkt, wenn Sie menschliche Faktoren und Benutzererfahrung als Teil des Produktmanagements berücksichtigen. Die Idee, dass es eine einzige Stimme geben sollte, die Produktentscheidungen trifft, ist vernünftig, diese Person muss von einer Vielzahl von Personen unterstützt werden, die zusammen über alle erforderlichen Fähigkeiten verfügen, um das Produktmanagement durchzuführen.
Die Geschäftsanalyse ist eine der Fähigkeiten, die erforderlich sein können, um einen Product Owner zu unterstützen. Dies kann eine spezialisierte Person sein oder jemand, der neben anderen Arbeiten auch Geschäftsanalysen durchführt.
Sobald Sie erkennen, dass es ein Team gibt, das Entdeckungsarbeit durchführt, können Sie sich Dual-Track Agile ( 1 , 2 , 3 ) ansehen, wo die Entdeckungsarbeit in das Product Backlog für das Scrum-Team einfließt. Es gibt keine harte Mauer oder Übergabe zwischen den beiden Teams, es muss zusammenarbeiten, um sicherzustellen, dass beide Aspekte das Richtige tun. Es gibt jedoch eine klare Unterscheidung zwischen dem Verstehen und Definieren des Problems (Entdeckung) und der Bereitstellung (technisches Verständnis und Definition, Prototyping, Design, Implementierung, Test und Bereitstellung).
Das Team hinter dem Product Owner wird zur Quelle für Antworten auf Fragen, die die Entwickler haben. Dies könnte der Product Owner sein, oder der Product Owner könnte sich an einen der Spezialisten wenden, die das Produkt unterstützen.
Ich habe viele Business Analysten gesehen, die gut in Scrum-Teams arbeiten.
Die drei größten Herausforderungen für sie sind typischerweise:
Ein oft übersehener Wert eines BA in einem Scrum-Team ist, dass er bei guter Zusammenarbeit mit dem Product Owner ein wirklich gutes Backup für die PO-Rolle bildet. Ich habe zum Beispiel oft gesehen, wie das Team BA einspringt, wenn der Product Owner im Urlaub oder krank ist.
Ich sehe normalerweise, dass BAs auf eine von zwei Arten funktionieren. Manchmal helfen sie bei Elementen, die im aktuellen Sprint entwickelt werden, indem sie Entwicklern ihre Fachkenntnisse zur Verfügung stellen, beim Ausfüllen fehlender Details helfen und mit Benutzern und Testern zusammenarbeiten, um Probleme zu verstehen. Anforderungen müssen zum Zeitpunkt der Sprintplanung noch nicht vollständig definiert sein – sie müssen nur ausreichend fertig sein, damit das aktuelle Sprintziel erreichbar ist.
Alternativ erstellen Teams manchmal reine Analysegeschichten – Geschichten, die die weitere Arbeit definieren, die in zukünftigen Sprints abgeschlossen wird. Dies ist beispielsweise sinnvoll, wenn für die Bestellung bestimmte Details ausgearbeitet werden müssen, um neue Rückstandspositionen zu erstellen oder zu priorisieren. Dies ist eine sehr übliche Vorgehensweise zu Beginn eines neuen Produkts oder Arbeitsablaufs. Das muss aber noch lange nicht heißen, dass vor dem Sprint Planning jedes Detail definiert ist, denn der BA soll sich auch während der Entwicklung und beim Testen einbringen können. Da das Team entlang eines sich verengenden Unsicherheitskegels arbeitet , sollten die Fälle von reinen Analysegeschichten tendenziell weniger sein.
Scrum besagt lediglich, dass das Team über alle erforderlichen Fähigkeiten verfügen muss, um das Produkt und alle Produktinkremente zu erstellen, die zum Endergebnis führen. Obwohl in Scrum keine andere Rolle als „Entwickler“ identifiziert wird, verfügen Teams oft über spezialisierte Fähigkeiten wie Frontend-Entwickler, Backend-Entwickler, Tester, Designer usw.
Wenn also das Produkt, das Sie erstellen, Business-Analysten benötigt, können Sie diese Aufgabe übernehmen, indem Sie die Arbeit des Product Owners unterstützen. Die Rolle könnte in komplexeren Bereichen wie Recht, Finanzen, Versicherungen, Bankwesen usw. oder in einem komplexeren Projekt mit mehreren Scrum-Teams benötigt werden, bei dem der PO etwas Hilfe bei der Definition des Produkts und seiner Details benötigt (der PO bleibt verantwortlich und verantwortlich).
Als Aktivitäten erfüllt der Business Analyst in Agile ähnliche Funktionen wie in traditionelleren Methoden, aber die Beteiligung ist unterschiedlich und erfolgt kontinuierlich während der gesamten Entwicklung des Produkts, in jedem Sprint, nicht nur in den Anfangsphasen des Projekts.
Todd A. Jacobs
Daniel
Stanislaw Baschkirtsew
Todd A. Jacobs