Ich kann möglicherweise ein neues Team übernehmen, das mit Scrum gespielt hat, es aber nicht für den richtigen Ansatz hielt (hauptsächlich aufgrund der parallelen und nicht sequentiellen Natur von Geschäftsprojekten).
Sie arbeiten an einem ziemlich effektiven Kanban-System, aber das Entwicklungsteam ist unzufrieden. In früheren Rollen haben sie eng mit Kunden zusammengearbeitet und sind jetzt nur noch Entwickler (ihre Worte), die einem Product Owner oder Projektmanager unterstellt sind, der die Kundenanforderungen artikuliert.
Leider hat dies zu einer Reihe von Projektverzögerungen geführt, da technische Informationen oder Warnungen der Entwickler ignoriert werden, bis der Projektmanager mit eingezogenem Schwanz zum Geschäftskunden zurückkehren und erklären muss, dass die Zeitvorgaben unrealistisch waren.
Ich wurde gebeten, die Machbarkeit eines Entwicklungsteams zu prüfen, in dem jeder Entwickler theoretisch einer Reihe von Projekten zugeordnet und neben dem Projektmanager oder Product Owner stark in die Anforderungserfassung und Backlog-Generierung eingebunden werden könnte. Das Management möchte wissen, ob ein solcher Ansatz noch „agil“ ist, was eine Fixierung zu sein scheint.
Der Senior Product Owner entscheidet weiterhin über die Priorität der Projekte, die in die Umgebung kommen, aber die Entwickler sind in Verbindung mit einem PM/stellvertretenden PO für die Priorität der Aufgaben innerhalb jedes Projekts verantwortlich.
Welche Praktiken würden zum potenziellen Erfolg eines solchen Systems führen?
Ich weiß, dass einige versucht sein mögen, sich auf den Teil „Scrum hat nicht funktioniert“ oder den Teil „Entwickler ist unzufrieden“ der Frage zu fixieren, aber ich habe diese Informationen für den Kontext angegeben. Ich bin zuversichtlich, die Moral des Teams umzukehren und das Selbstwertgefühl jedes Einzelnen zu verbessern. Ich bin gespannt, ob ein ehemaliges Scrum-Team überleben kann, wenn jeder Entwickler neben einem Product Owner Anforderungen sammeln/neu priorisieren darf.
Ich weiß, dass diese Frage etwas theoretisch und etwas schwerer ist als der normale Tarif bei SE.PM, aber ich hatte das Gefühl, wenn jemand das Kosten-Nutzen-Verhältnis eines solchen Ansatzes per Crowdsource ermitteln könnte, wäre es hier. :-)
Ich denke, die Frage der „Anforderungserfassung“ basiert auf einem Missverständnis der beteiligten agilen Prinzipien und insbesondere der Frage, wie User Stories erstellt werden und wie die Details einer Story in einer Implementierung konkretisiert werden sollten. Einfach die Erwartungen aller richtig zu formulieren, kann sehr hilfreich sein.
Es ist zwar nicht machbar, dass 10 Entwickler gleichzeitig als Business Analysten fungieren, aber es gibt keinen Grund, warum Entwickler nicht in den Prozess des Storywritings, in Diskussionen zur Verfeinerung des Backlogs oder in die direkte Zusammenarbeit mit Kunden einbezogen werden können. Tatsächlich erklärt das Agile Manifest ausdrücklich die Zusammenarbeit mit Kunden zu einem Kernwert, überlässt es aber dem Framework und dem Team, die besten Wege zur Umsetzung einer solchen Zusammenarbeit zu identifizieren.
Ich biete einige Analysen im nächsten Abschnitt und einige praktische Empfehlungen für eine effektive Zusammenarbeit im letzten Abschnitt unten.
Eine User Story ist keine Spezifikation oder ein Satz von Anforderungen (siehe „Vorteile von User Storys für Anforderungen“ § User Storys sind keine Anforderungsbeschreibungen ). Vielmehr ist eine User Story ein strukturierter Platzhalter für ein Gespräch darüber, wie eine bestimmte Funktion am besten implementiert werden kann.
Selbst innerhalb von Scrum, das eine ziemlich starre Definition von Rollen innerhalb des Scrum-Teams hat, gibt es in der Beschreibung der Product Owner-Rolle nichts, was das Entwicklungsteam daran hindert, die Absicht einer User Story zu klären oder direkt mit dem Kunden zusammenzuarbeiten. Der Product Owner sollte an der Erfassung von Anforderungen und der Entwicklung von User Stories beteiligt sein, damit er das Product Backlog richtig priorisieren kann, aber dies soll eher eine Möglichkeit sein, Projektprioritäten zu strukturieren, als ein Kommunikationshindernis.
Der Scrum-Guide sagt:
Der Product Owner ist eine Person, kein Komitee. Der Product Owner kann die Wünsche eines Komitees im Product Backlog vertreten, aber diejenigen, die die Priorität eines Product Backlog-Eintrags ändern möchten, müssen sich an den Product Owner wenden.
Der Fokus liegt hier auf der Priorisierung von Stories und damit der Zuweisung von Projektressourcen für jede Iteration. Die gemeinsame Verwendung des Product Owners als Kommunikations-Proxy für einen abwesenden Kunden wird durch das Framework sicherlich nicht vorgeschrieben.
Tatsächlich sollte beim Extreme Programming der Kunde immer für das Team verfügbar sein. Darüber hinaus wird von ihnen erwartet, dass sie aktiv mit dem Entwicklungsteam zusammenarbeiten, wie dieses direkte Zitat zeigt:
Da Details in den User Stories weggelassen werden, müssen die Entwickler mit Kunden sprechen, um genügend Details zu erhalten, um eine Programmieraufgabe abzuschließen. Projekte jeder bedeutenden Größe erfordern ein Vollzeitengagement des Kunden.
Anforderungen müssen gesammelt werden, aber es ist jedem Projekt überlassen, wie das geschehen soll. Wichtig ist, dass die User Stories nicht als feste Anforderungen oder detaillierte Spezifikationen behandelt werden, sondern als gut eingerahmter Kontext für die weitere Ausarbeitung und Zusammenarbeit mit dem Kunden.
Die Zusammenarbeit mit dem Kunden während der gesamten Iteration ist vorzuziehen, vorausgesetzt, dass sie das Ziel oder den Umfang der aktuellen Iteration nicht unsichtbar ändert. Änderungen des Geltungsbereichs müssen über das Framework und nicht über Seitenkanäle adressiert werden.
Dieser Punkt kann noch etwas allgemeiner und unabhängiger vom Rahmen gemacht werden. Die Sorge ist die Möglichkeit, dass Seitenkanalkommunikation bestehende Vereinbarungen umgehen oder widersprüchliche Anforderungen einführen könnte, dh Anforderungen, die die Bedürfnisse eines Stakeholders erfüllen, ohne die Auswirkungen auf andere Stakeholder oder auf die Benutzererfahrung des Systems als Ganzes zu berücksichtigen.
Dieses Risiko kann gemildert werden, indem die entsprechenden Personen (Product Owner, Projektmanager) auf dem Laufenden gehalten werden: nicht unbedingt bei jedem Meeting anwesend, aber über die allgemein besprochenen Themen informiert.
Zum Beispiel: Bei einem meiner Projekte bin ich der Entwicklungsleiter und ich habe einen Kollegen, der der Kundenleiter ist. Kunden werden ermutigt, direkt mit mir und meinen Entwicklern zu kommunizieren – was sie bevorzugen, weil es effizienter ist – solange sie ihren Vorsprung behalten. Gelegentlich vergessen sie es, und ich bringe sie herein. (Wir erledigen viel per E-Mail, daher ist es einfach genug, die entsprechenden Leute auf CC zu setzen.) Sie kennt das Gesamtbild auf der Kundenseite, und ich kenne es auf der Entwicklerseite. Es gibt eine ausdrückliche Vereinbarung, dass nichts ohne Zustimmung von uns beiden zugesagt wird. In den seltenen Fällen, in denen wir uns nicht einigen können, gehen wir zum oberen Management und lassen sie entscheiden. Es ist informell und effektiv.
Interessante Situation. Meine größte Sorge beim Lesen des Szenarios ist, dass Sie eine Person (einen Entwickler) haben, die mehrere Hüte trägt (BA, PO, Tester?) mit möglicherweise sehr geringer Verantwortlichkeit.
Das Wichtigste für diese Art von Umgebung wäre es, sicherzustellen, dass alles sehr transparent ist, und Entwicklern dabei zu helfen, die Gefahr zu vermeiden, von einem Team zu einer Arbeitsgruppe mit isoliertem Besitz von Geschichten abzudriften.
Ich würde wahrscheinlich versuchen, eine Art Scrum-Verbot zu machen. Rückstände in Story-Größe, aber Arbeiten an einem Kanban-Board mit WIP-Limits und genauer Beachtung der Zykluszeiten für jeden Bucket von Story-Points. Ich würde wahrscheinlich auch ziemlich granular auf dem Kanban-Board vorgehen, um klar darzustellen, was in Prozessbereichen passiert, in denen jede Spezialität ihre Arbeit erledigt.
Product Owner Visioning und Priorisierung, Business Analyst Detaillierung, vom Entwickler vorab festgeschriebener Code, vom Entwickler nachträglich festgeschriebener Code, manuelle Qualitätssicherung und alle Staging- oder Integrationsaktivitäten, die ebenfalls unterstützt werden.
Ich würde die 3 Scrum-Zeremonien in Betracht ziehen, aber erwägen, die Iterationsdauer um bis zu einer Woche zu verlängern, damit sich das Team an sich schnell ändernde Prioritäten anpassen kann. Je nach Reifegrad des Teams könnten Retrospektiven/Rezensionen informeller sein.
Schließlich würde ich die Arbeit in hohe, mittlere und niedrige Prioritäten anstatt in eine Rangordnung einteilen und die Anzahl der Geschäfte mit hoher Priorität in einer Iteration begrenzen, um eine ständige Diskussion darüber zu erzwingen, was während der Iteration am wichtigsten ist.
Venture2099