Wie man ein gescheitertes Unterteam innerhalb eines Scrum-Teams verwaltet

Sie haben in Bezug auf Scrum gefragt, also werde ich so antworten. Es gibt jedoch eine Reihe von roten Fahnen in Ihrer Frage, die mich glauben lassen, dass Sie nicht wirklich Scrum betreiben (und ich bin weit davon entfernt, ein Scrum-Purist zu sein).

Die Scrum-Antwort wäre:

• Als PO sind Sie für das Product Backlog und die Prioritäten verantwortlich, nicht für die Prozessverbesserung. Wenn Sie ein Problem sehen, können Sie es im Retro ansprechen oder (was ich angesichts der anhaltenden Natur des Problems empfehlen würde) mit dem SM sprechen und sich beraten lassen, ob Sie es im Retro ansprechen sollten oder ob sie würden es vorziehen, das Thema anzusprechen.

• Der SM ist dafür verantwortlich, alle beobachteten Prozessprobleme, die er sieht, zur Sprache zu bringen und das Team in Richtung Prozessverbesserung zu coachen. Dies geschieht normalerweise im Retro-Stil.

• über das Problem klar sein. Das Problem, wie Sie es beschreiben, ist nicht "sie können keinen Code ohne Fehler veröffentlichen". Das ist ein unerreichbares Ideal, das wir alle anstreben sollten, aber es ist nicht wirklich erreichbar. Das eigentliche Problem, das Sie beschreiben, klingt wie "komplexe Fehler werden spät entdeckt und können nicht innerhalb des Sprints behoben werden".

• Der erste Schritt bei jeder Frage in der Form „Warum passiert das?“ ist, sie dem Team vorzutragen: Fragen Sie sie , warum das passiert. (Auch dies ist eigentlich in der Sphäre des SM zu tun, nicht in der des PO.) Der SM muss möglicherweise über die erste Antwort hinaus coachen.

• Denken Sie in dieser Diskussion breit und kreativ: Vielleicht liegt das Problem weiter oben, in den Anforderungen und der Abnahmespezifikation. Vielleicht liegt es an der Verfeinerung des Rückstands (und wenn ja, ist dieser Teil in Ihrer Sphäre als PO). Vielleicht müssen Sie wirklich in automatisierte Tests investieren. Vielleicht musst du früh scheitern. Vielleicht müssen Sie einige Spikes durchführen, um Unsicherheiten zu reduzieren und Anforderungen zu klären. Ich bin sicher, es gibt noch mehr Möglichkeiten.

• Denken Sie auch inkrementell: Brainstormen Sie eine Reihe von Möglichkeiten, dann wählt das Team ein Element aus, um es auszuprobieren, um zu sehen, ob es einen inkrementellen Unterschied macht. Es ist höchst unwahrscheinlich, dass Sie eine große Wunderwaffe finden.

• Zum Schluss, gute Güte, hören Sie auf, sie Überstunden und Nächte und Doppelschichten machen zu lassen! Scrum soll ein nachhaltiges Tempo sein, und unabhängig davon, welche Methodik Sie verwenden, ist dies absolut kontraproduktiv. Es erschöpft Ihr Team und erwartet, dass es komplizierte Probleme löst, während es erschöpft ist.

Bearbeiten: Auf eine zusätzliche Bearbeitung oben geantwortet

Was passiert in Retrospektiven

Wir sind in einer Schleife, in der wir auf die Probleme hinweisen -> Team zeichnet es auf -> beim nächsten Sprint, dieselben Probleme -> Retrospektive

Dies ist der Ort, an dem Sie anfangen können. Hören Sie nicht damit auf, das Problem einfach aufzuzeichnen. Bei der Retro geht es nicht nur darum, Prozessprobleme zu identifizieren; Es geht darum, Ursachen/Faktoren und entsprechende mögliche Lösungen zu erproben und sich zu verpflichten, im nächsten Sprint mindestens eine davon auszuprobieren.

Auch wenn „wir“, die auf die Probleme hinweisen, nicht dasselbe sind wie „Team“, das sie aufzeichnet … das ist ein weiteres Problem.

Steigern Sie Ihre Zusammenarbeit mit dem Scrum-Team

In diesem speziellen Fall ist dies jedoch keine Option.

„Keine Option“ heißt in der Regel betriebswirtschaftlich: „Wir wollen andere Ergebnisse, aber wir lehnen es ab, die zugrunde liegenden Faktoren zu ändern.“ Das ist nicht agil und führt im Allgemeinen zu Schuldzuweisungen und anderen nicht konstruktiven Anti-Mustern für Unternehmen.

Das Front-End-Team produziert viele Fehler (Defekte) innerhalb eines Sprintzyklus.

Scrum ist keine dünne Schicht von Schlagworten über dem Command-and-Control-Produktmanagement. Sie brauchen einen Paradigmenwechsel.

Mängel und unvollständige Arbeit sind Symptome von Prozessproblemen. Normalerweise liegt das daran, dass das Entwicklungsteam:

1. „Zur Rechenschaft gezogen werden“ für die Arbeit, die in den Sprint gedrängt wird, anstatt vom Entwicklungsteam auf der Grundlage seiner eigenen Prognosen für Kapazität und Aufwand in den Sprint gezogen zu werden.
2. Versäumnis, an einer Definition of Done mitzuarbeiten, die eine Test-First-Entwicklung umfasst, oder Versäumnis, ausreichende Qualitätskontrollmaßnahmen bei der Schätzung und Planung der Arbeit einzubauen.
3. Keine Verwendung angemessener Testmethoden oder kontinuierlicher Integrationstools. Dies ist für die Frontend-Arbeit etwas schwieriger als für die Backend-Arbeit, aber in Ihrem Fall fehlt es der Scrum-Implementierung wahrscheinlich überhaupt.

Sie sollten mit dem Scrum Master zusammenarbeiten und mit dem Entwicklungsteam zusammenarbeiten, um die zugrunde liegenden Prozessprobleme anzugehen. Sie können damit beginnen, dass Sie nicht davon ausgehen, dass sie „versagen“ oder leistungsschwach sind, und aufhören, sie wie ein „Unterteam“ zu behandeln. In Scrum gibt es nur ein Scrum-Team, und Sie sind alle zusammen in diesem Team .

Als Product Owner ist es Ihre Aufgabe, herauszufinden, was das Entwicklungsteam braucht, um erfolgreich mit Ihnen bei der Produktentwicklung zusammenzuarbeiten. Es ist auch Ihre Aufgabe, die notwendigen Voraussetzungen im Product Backlog als Arbeit zu erfassen , die das gesamte Team nachverfolgen kann. Beispielsweise ist die Einrichtung eines Continuous-Integration-Servers, der JavaScript rendern und testen kann, wahrscheinlich eine Voraussetzung, die derzeit nicht als erstklassiges Product-Backlog-Element verfolgt wird. Es liegt in Ihrer Macht, das zu beheben, denn Sie sind der Verwalter des Product Backlogs, mit der Befugnis, die Backlog-Elemente zu priorisieren (und somit Teamressourcen zuzuweisen), um den Erfolg des Projekts zu erleichtern!

Ich bekomme viele "uns" vs. "sie" Gefühle aus Ihrer Frage, was ein wichtiges Warnsignal ist. Als PO bist du Teil des Teams, es gibt nur „wir“.

Andere haben angesprochen, wie es besser wäre, keine separaten „Unterteams“ zu haben, sondern nur ein Team mit übergreifenden Fähigkeiten, also werde ich darauf nicht näher eingehen.

Ich denke, Ihr Hauptproblem ist, dass das Team dazu gedrängt wird, Dinge zu liefern, anstatt sich selbst einem Ziel zu verpflichten.

Das Team sollte

1. Schätzen Sie, wie lange sie brauchen werden, um jede Geschichte fertigzustellen (in gemeinsamen Verfeinerungssitzungen). Idealerweise machst du das in Storypoints.
2. Verwenden Sie Daten aus früheren Sprints, um zu entscheiden, wie viel Arbeit sie in einem Sprint bewältigen können. Schauen Sie sich die letzten 2 bis 6 Sprints an, sehen Sie, wie viele Stories Sie innerhalb des Time-Box-Sprints (keine Erweiterungen!) schließen konnten (es bleibt keine Arbeit übrig, also vollständig getestet und alle Fehler behoben). Das ist deine Geschwindigkeit.
3. Verwenden Sie diese Geschwindigkeit, um eine neue Reihe von Storys auszuwählen, an denen Sie im nächsten Sprint arbeiten können

Das bedeutet, dass niemand von außerhalb des Entwicklungsteams ihnen sagen darf, woran sie arbeiten sollen und wie lange es dauern soll, bis sie fertig sind. Nicht mal du. Sie sollten ihnen sagen, was die geschäftliche Priorität jeder der Geschichten ist, und sie sollten dies bei der Auswahl der Geschichten unbedingt berücksichtigen. Aber wenn sie gute Gründe haben, sich nicht auf ein Item mit hoher Priorität festzulegen (z. B. weil es nicht in den nächsten Sprint passt, entsprechend ihrer Velocity), ist das völlig in Ordnung.

Wenn das bedeutet, dass sie externe Fristen nicht einhalten können, bedeutet das, dass die Fristen nicht realistisch sind. Sie sollten die Fristen verschieben, den Umfang des freigegebenen Produkts reduzieren oder nach Möglichkeiten suchen, die Effizienz des Teams oder die Kapazität des Teams zu verbessern. Ihr Team ist jedoch bereits ziemlich groß, daher würde ich es nicht erweitern.

Es ist vollkommen normal, dass Menschen mit unterschiedlichen Fähigkeiten und Fähigkeiten in einem Scrum-Team arbeiten. Daher ist es normal, Back-End-, Front-End- und QA-Rollen in einem Team getrennt zu haben.

Der Erfolg des Teams hängt davon ab, dass eine kleine Gruppe von Personen innerhalb des Teams nicht als Unterteam behandelt wird . Das Konzept des Subteams arbeitet gegen das Konzept des Scrum-Teams.

Es ist völlig in Ordnung, dass jeder einzelne im Team eine bestimmte Fähigkeit besitzt und somit eine bestimmte Rolle ausübt, die der Fähigkeit entspricht.

Es ist jedoch keine gute Praxis, die Personen mit ähnlichen Fähigkeiten zu gruppieren und sie als Unterteam innerhalb des Teams zu bezeichnen.

Die Bildung von Subteams führt zu dem Szenario, dass ein Subteam das andere beschuldigt.

Individuen beschuldigen normalerweise nicht die anderen Individuen. Subteams neigen jedoch normalerweise dazu, die anderen Subteams zu beschuldigen.

Unterteams führen auch unweigerlich zu einem falschen Gefühl von Hierarchie und Eskalationsprozess innerhalb des Teams, wodurch die Gesamteffizienz des Teams verringert wird.

Das Vermeiden von Unterteams, das Ermöglichen von Einzelpersonen, eine gute Beziehung zu den anderen Einzelpersonen des Teams zu haben, und das Eliminieren des falschen Gefühls der Hierarchie wird das Team automatisch selbstverwaltet machen. Dies wird definitiv den Weg zum Erfolg ebnen.

Ich denke, ich würde einen „Stopp und eine Neugruppierung aller Projekte“ fordern. Dieses Team befindet sich offensichtlich auf einem Todesmarsch, und das funktioniert nie . Sie müssen dem Team – und dem Management – ​​helfen, zu verstehen, was das Team antreibt, dies überhaupt zu versuchen.

Sind die Erwartungen realistisch? Ist der Analyseprozess gut? Weiß das Team – nun ja – wirklich , was es zu tun hat? Versuchen sie, mehr Arbeit zu übernehmen, als sie offensichtlich leisten können, und wenn ja, warum?

Sie können Scrum oder ein anderes Projektmanagement-Paradigma nicht „auf“ einen Todesmarsch legen. Sie müssen zuerst eingreifen, um den Marsch zu stoppen.

Ja, und ich werde "zurückkehren und eine weitere Antwort hinzufügen", um zu sagen, dass die Grundprobleme hier sehr offensichtlich außerhalb des Teams liegen.

• Wenn Programmierern gesagt wurde, dass sie sich umbringen müssen, um die notwendige Software zu produzieren ... werden sie nicht (!) ... jemals (!!) ... "die notwendige Software produzieren!"

Deshalb – (ich setze hier meinen abgebrühten Beraterhut auf …) „man kann ein Problem nicht lösen, bis man sich damit auseinandersetzt, was es eigentlich ist.“ Und in diesem Fall handelt es sich ganz klar um jemanden auf einer viel höheren Ebene innerhalb der Unternehmensstruktur rund um dieses Team, der von „Im Dutzend billiger“ und nicht von der eigentlichen Softwarewelt gelernt hat.

„Software(!) worker“ sind keine „Fließbandmitarbeiter“, die lediglich dafür zuständig sind, zuzusehen, wie an einer Kurbel gedreht wird. Sie sind qualifizierte Arbeiter, die leicht genauso viel "Auswirkung auf Ihr Endergebnis " haben können ... wenn nicht mehr ... wie jeder überbezahlte Anwalt. Und – ihr tägliches Arbeitsprodukt ist „völlig wertlos“ , es sei denn(!) „es ist absolut(!!)(!!)(!!) richtig!“

Also – deshalb habe ich gesagt: „Zuerst müsst ihr den Todesmarsch stoppen.“ Sie müssen aufhören, dieses Team von Arbeitern unrealistischen Erwartungen auszusetzen. Sie müssen alle Erwartungen des Managements (!) stoppen , dass "Auspeitschen" überhaupt etwas nützen wird.

Denn: Genau das Gegenteil ist der Fall.

Einfaches Beispiel: *"Sagen Sie unseren Unternehmensanwälten, dass sie nicht nur ihre Gebühren um 50 % kürzen, sondern auch ihren Anwalt in der Hälfte der Zeit produzieren müssen."

Nein. Softwarearbeiter verdienen genau(!) wie Anwälte ihr tägliches Brot mit ihrem Fachwissen. Sie können nicht einfach zählen, sagen wir, "die Anzahl der Seiten [des Quellcodes] [der juristischen Briefings], die sie produzieren". Das ist nicht der Punkt.

Tun Sie sich selbst einen Gefallen und entfernen Sie sich von Prozessen und Tools (wenn Sie mit agilen Begriffen sprechen wollen).

Versammeln Sie alle in einem Whiteboard-Übungsworkshop und finden Sie heraus, wie Sie alle gemeinsam den Status quo verbessern können. Sie werden überrascht sein, was Sie davon haben.