Passt ein Business Analyst in das Scrum-Framework?

Frage

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?

Anliegen

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.

Basierend auf all den damit zusammenhängenden Fragen, die Sie gestellt haben, komme ich nicht umhin, das Gefühl zu haben, dass Ihr Unternehmen versessen darauf ist, Scrum in Name Only℠ über traditionelle, nicht agile Prozesse zu legen. Der springende Punkt ist, dass das „Was“ für die Stakeholder (durch die PO) ist, während das „Wie“ den Entwicklern überlassen bleibt (in Zusammenarbeit mit der PO).
Aber die Entwickler selbst wissen nicht, wie man in einer Scrum-Umgebung arbeitet, sie fragen mich, und ich habe nicht immer Antworten. Der Scrum Guide liefert nicht viele Details. Ich habe übrigens noch nie ein Scrum-Team gesehen – ich habe ScrumBut-Teams nur in der Praxis gesehen.
@Daniel, " Ich habe noch nie ein Scrum-Team gesehen - ich habe nur ScrumBut-Teams in der Praxis gesehen " - wenn es weh tut und die Leute den Wert nicht verstehen und niemand mit einer Peitsche da ist - sie werden es nicht tun. Scrum schadet allen so sehr, dass die Menschen von Natur aus zu effektiveren Prozessen wie ScrumBut neigen. ScrumAber ist eigentlich das, was Teams agiler macht – sie stellen fest, dass Scrum nicht ihren Bedürfnissen entspricht und modifizieren ihren Prozess, um effektiver zu werden.
Ich denke, diese Frage wird schließlich zu einer ausführlichen Diskussion führen, weil es eigentlich zwei Fragen in einer sind: 1) Sollte ein Scrum-Team eine dedizierte BA-Rolle haben? und 2) Wie geht ein Scrum-Team mit traditionellen BA-Aufgaben um? . Eine zu starke Änderung der Frage könnte die aktuellen Antworten ungültig machen, also tun Sie das bitte nicht, aber stellen Sie sie bitte als separate, aber miteinander verknüpfte Fragen, wenn Sie Antworten mit unterschiedlichem Fokus wünschen.

Antworten (5)

TL;DR

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.

Verschmelzen Sie Rollen und Fähigkeiten nicht

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.

Externalisieren von Rollen

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:

  1. 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.

  2. 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.

Ich denke, das beantwortet nur, was BAs sind, aber nicht, wie man sie mit Sprints synchronisiert, da sie ihre Arbeit im Voraus erledigen müssen.
@StanislavBashkyrtsev Nein, tun sie nicht. Genau wie das Testen sollte die Analyse ein kontinuierlicher, kollaborativer, just-enough- und just-in-time-Prozess sein. Wenn Sie nicht zustimmen, dass dies selbstverständlich ist, dann fragen Sie im Wesentlichen, wie Sie einen Mini-Wasserfall in Ihrem agilen Prozess implementieren können.
Just-enough und just-in-time für BAs bedeuten – bevor die Entwickler mit der Arbeit an einer Aufgabe begannen. Zusätzlich muss ein Puffer vorhanden sein, damit BAs nicht versehentlich Devs blockieren. Da wir hier über Scrum sprechen: Zum Zeitpunkt der Planung sollten alle Aufgaben analysiert worden sein, sonst wird die Planung … gelinde gesagt umständlich. Ergo sollten die Aufgaben des nächsten Sprints im aktuellen Sprint analysiert werden.
@StanislavBashkyrtsev Es gibt keine dedizierten BA- Rollen . Wenn Sie I-förmige Personen in Ihr Scrum-Team aufnehmen möchten und das Team gemeinsam beschließt, sie ausschließlich der Backlog-Verfeinerung zu widmen oder im Namen des PO oder der Entwickler mit Stakeholdern zu sprechen, dann lässt das Framework dies zu, auch wenn es suboptimal ist. BUFD steht im Gegensatz zu iterativem, inkrementellem und emergentem Design, also hören Sie bitte auf, dem Framework die Schuld dafür zu geben, dass es nicht 1:1 auf ein völlig anderes Modell abgebildet wird.
Ich gebe Scrum nicht die Schuld. Ich versuche deine Worte zu verdauen. Sie sagen, Scrum definiert nur Entwickler, aber was dieser Entwickler tut, ist Sache des Teams. Rechts? Wir können sagen, dass einer der "Entwickler" BA-Kenntnisse hat und somit BA-Jobs erledigen kann. Jetzt sagen Sie, dass selbst das „suboptimale“ Scrum (wie kommen Sie zu dieser Schlussfolgerung?) einem solchen „Entwickler“ erlaubt, an der Backlog-Verfeinerung zu arbeiten. Was mit meinem Punkt übereinstimmt – diese Person würde an den Aufgaben für den nächsten Sprint arbeiten.
@StanislavBashkyrtsev Das verdient wirklich eine separate Frage. Im Titel des OP geht es darum, ob ein traditioneller BA zu Scrum passt, und es ist schwer, darauf zu antworten, als „nein“ zu sagen. Die üblichen BA- Zuständigkeiten sollten zwischen dem PO und den Entwicklern verteilt werden. Wie diese Verantwortlichkeiten umgesetzt werden , ist Sache des Teams, aber es gibt zugrunde liegende Rahmenbedingungen und agile Prinzipien, die Ihre Prozessimplementierung leiten sollten. Diese Prinzipien sprechen gegen das mentale Modell einer engagierten Person vom Typ BA, die sich ausschließlich auf die zukünftige Arbeit konzentriert, aber es gibt kein explizites Rahmenverbot.
Ich bin mir nicht sicher, warum Sie Agile hier einbeziehen, da eine solche Rolle nicht verpönt ist (obwohl Sie BAs aus irgendeinem Grund mit BUFD in Verbindung zu bringen scheinen). Aber ja - Scrum scheint entweder BA in der Rolle eines PO zu akzeptieren (was ist wackelig, da BAs selten Stakeholder sind) oder verneint es komplett, weil diese Person nicht in die Liste der Entwickler aufgenommen werden kann, die am aktuellen Sprint arbeiten. Das ist interessant, weil es viele Projekte mit komplizierten Domänen gibt, die ohne traditionelle BAs nicht überleben können.

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 klares Verständnis der Rollen und Verantwortlichkeiten mit dem Product Owner erreichen
  • Anpassung an die Just-in-Time- Natur von Scrum – versuchen, Details zum spätestmöglichen Zeitpunkt hinzuzufügen
  • Gut darin werden, auf Veränderungen zu reagieren – Feedback von den Stakeholdern entgegenzunehmen und es schnell in ihre Analyse einzubeziehen

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.

+1. Ich stimme zu, dass es gut funktioniert, wenn der BA nicht getrennt von den anderen Entwicklern gesehen wird und das Design auf den letzten verantwortlichen Moment verschiebt. Nach meiner persönlichen Erfahrung funktioniert es jedoch nicht, wenn die BA-Verantwortung nicht vom Team geteilt wird oder wenn die Entwicklung als nachgelagert zur Anforderungserfassung/-analyse behandelt wird.

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.

Ich habe Ihre Antwort positiv bewertet, da sie das Y im X / Y-Problem des OP direkt anspricht. Meine Antwort konzentriert sich mehr darauf, was das Team tun sollte, als darauf, wie es es tun sollte, daher denke ich, dass Ihre Antwort viel Wert hinzufügt.
@StanislavBashkyrtsev Diese Antwort befasst sich mit einigen der Ansätze auf Implementierungsebene, die innerhalb des Frameworks möglich sind. Wenn die Bedenken, die Sie in anderen Kommentaren geäußert haben, nicht berücksichtigt werden, öffnen Sie bitte eine neue Frage, da Sie meines Erachtens legitime Implementierungsfragen über die zentrale rollenbezogene Frage im OP auf oberster Ebene hinaus aufwerfen.

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.

Aber wie kann die Beteiligung des Business-Analysten kontinuierlich und mit Sprints synchronisiert werden? Sie müssen dem Entwicklungsteam dann mindestens einen Sprint voraus sein, damit die Anforderungen beim Planungsmeeting fertig, klar definiert, klar zerlegt usw. sind. Der Business Analyst wird dann zum Proxy PO.
@Daniel Sie versuchen, eine Upstream / Downstream-Dichotomie aufrechtzuerhalten. Warum sich überhaupt mit Scrum beschäftigen, wenn Sie nur Wasserfall machen wollen? BUFD kann in einigen Bereichen nützlich sein. Wenn es also für Sie funktioniert, warum sollte Scrum (das ein iteratives Framework ist) überhaupt?
@Daniel: Die Ergebnisse aller Business-Analysten, die Sie möglicherweise zum Team hinzufügen möchten, spiegeln sich hauptsächlich im Inhalt des Backlogs wider, der ein lebendes Artefakt ist, das kontinuierlich verfeinert wird, und ja, er müsste genügend Details für den nächsten Sprint haben um geplant und gestartet werden zu können, aber betrachten Sie es nicht als Stellvertreterposition. Alle sind im Team auf der gleichen Ebene, ein BA sitzt nicht zwischen dem PO und den Entwicklern.
Passt ein Business Analyst in das Scrum-Framework?
AntwortenHierDatenschutz-Bestimmungen1y, 0v