Soll ich als Scrum Master entscheiden oder das Team entscheiden, ob sie einen Tester brauchen?

Es werden viele Kommentare über die Größe des Teams und die Rollen darin abgegeben, also überspringe ich das.

Mein Rat (bei den meisten Fragen, Problemen oder was auch immer): Wenden Sie sich an das Team

Das Team macht die eigentliche Arbeit und sie können sagen, was sie ihrer Meinung nach brauchen oder tun sollten oder was auch immer. Dann können Sie über die Situation diskutieren und mit dem Team zu einer Lösung kommen.

Sprechen Sie nicht über das Team und seine Bedürfnisse, sprechen Sie mit dem Team

Soll ich als Scrum Master entscheiden oder das Team entscheiden, ob sie einen Tester brauchen?

So sprechen traditionelle Projektmanager, nicht Scrum Master.

Wenn Ihre Teammitglieder der Meinung sind, dass ein Tester helfen würde, und sie einen Tester wollen, dann sollten sie einen Tester haben. Das Team entscheidet.

Dies beantwortet direkt Ihre Titelfrage. Ich werde jetzt ein paar Dinge zu dem sagen, was Sie im Rest Ihres Beitrags erwähnen.

Sie haben einen Produktmanager, einen Associate Product Manager, einen Business Analyst, einen User Researcher, einen Interaction Designer und einen Content Designer in Ihrem Team, aber irgendwie denken Sie, dass ein Tester zu viel wäre? Wird ein Tester dem Team helfen, mehr oder besseren Wert zu bieten? Dann hol dir einen Tester. Wenn nicht, nicht.

Das Team scheint das Testen ohne sie gut zu handhaben, und dies ist die Richtung der Org, dh für jedes Team, das Testen kollektiv zu besitzen. Das ist meine Präferenz.

Die Richtung der Organisation? Die Organisation entscheidet, ob Entwickler Tester brauchen oder nicht? Scrum-Teams müssen sich selbst organisieren. Sie entscheiden, ob sie Tester brauchen oder ihre Arbeit nicht richtig machen.

Ich bin mir sicher, dass das Team ja sagen wird, einen Tester zu haben, aber das spricht gegen den Aufbau von Cross-Funktionalisten.

Cross-Funktionalität bedeutet nicht, dass jeder alles macht. Cross-Funktionalität in Scrum bedeutet, dass das Team über alle Fähigkeiten verfügt, die zum Erstellen des Produkts erforderlich sind. Das Team als Ganzes. Das bedeutet nicht, dass Entwickler auch die Arbeit eines Testers erledigen müssen. Sie können, aber es sollte nicht zwingend sein. Denken Sie darüber nach, ein User Researcher, der weder programmiert noch testet, spricht auch gegen den Aufbau von Cross-Funktionalisten. Was werden Sie jetzt dagegen tun, um Cross-Funktionalisten aufzubauen?

Persönlich habe ich mich oft in der Position einer One-Man-Show wiedergefunden, und obwohl ich viele Dinge aus vielen verschiedenen Bereichen alleine bewältigen könnte (ein Cross-Funktionalist sein, wenn Sie möchten), Alles wäre effizienter und besser verlaufen, wenn jemand mit spezialisierteren Fähigkeiten einige der Dinge, die ich getan habe, übernommen hätte. Wenn Ihr Team also einen Tester braucht, stellen Sie ihm einen Tester zur Verfügung. Auf diese Weise kann das Testen fokussierter und effizienter gehandhabt werden als andere, die ständig von einer Rolle in die andere wechseln.

Es liegt in der Verantwortung des Scrum Masters sicherzustellen, dass das Team Scrum befolgt, aber das Hinzufügen eines Testers zum Team steht nicht im Widerspruch zum Scrum Guide .

Der Scrum Guide empfiehlt jedoch, die Teamgröße auf 9 oder weniger zu belassen, daher lohnt es sich, dies mit dem Team zu besprechen. Ein guter Ansatz wäre, nach Problemen im Zusammenhang mit der Teamgröße Ausschau zu halten, wie z. B. Kommunikationsstörungen.

Ich bin mir sicher, dass das Team ja sagen wird, einen Tester zu haben, aber das spricht gegen den Aufbau von Cross-Funktionalisten.

Es gibt keinen Grund, warum Sie keinen Tester in einem Team von funktionsübergreifenden Personen haben können. Tester können durchaus an der Analyse beteiligt sein und einige können auch Codierungs- oder Konfigurationsaufgaben übernehmen. Sie können genauso ein T-förmiges Fähigkeitsprofil haben wie ein Entwickler.

Was ein guter Tester in ein Team einbringen kann, ist eine Qualitätsmentalität. Sie können die Funktionalität des Produkts auf ungewöhnliche Weise betrachten und potenzielle Probleme erkennen, die von anderen möglicherweise nicht erkannt werden.

Vielleicht ist es hilfreich, die Frage neu zu formulieren. Wir können stattdessen fragen: „ Verfügt mein Team über die Qualitätsfähigkeiten, die erforderlich sind, um das Produktinkrement zu liefern? “ Vielleicht denken Sie, Sie kennen die Antwort auf diese Frage – vielleicht haben Sie sogar Recht. Dies ist jedoch eine Frage für das Team.

Der Scrum Guide sagt Folgendes über das Entwicklungsteam:

Sie organisieren sich selbst. Niemand (nicht einmal der Scrum Master) sagt dem Entwicklungsteam, wie es das Product Backlog in Inkremente potenziell veröffentlichbarer Funktionalität umwandeln kann;

Dies gibt dem Team nicht die Erlaubnis, Inkremente zu erstellen, die aufgrund von Qualitätsproblemen möglicherweise nicht veröffentlicht werden können. Während wir also sagen könnten, dass es nicht Ihre Rolle als SM ist, ihnen zu sagen, dass sie die notwendigen Fähigkeiten besitzen oder nicht, um ein Qualitätsinkrement zu produzieren, sollten Sie unbedingt mitteilen, was Sie sehen, was darauf hindeuten könnte, dass sie diesen Standard nicht erfüllen . Zum Beispiel, wenn Sie eine hohe Anzahl von zurückgegebenen Mängeln sehen oder Inkremente aufgrund versäumter Tests für nicht lieferbar erklärt werden.

Nun stellt sich für das Team die Frage, wie man diesem Standard gerecht wird. Vielleicht ist es ein Prozessproblem - dass sie die Fähigkeiten haben, sie aber anwenden müssen. Vielleicht haben sie nicht die Fähigkeiten, aber lernen sie von jemandem in einem anderen Team. Vielleicht entscheiden sie, dass das Hinzufügen einer weiteren Person der beste Weg ist, diese Fähigkeit zu erwerben. Dies ist wirklich der gleiche Denkprozess für jede Fähigkeit, die das Team möglicherweise benötigt.

Die rote Fahne, die ich habe, wenn ich eine andere Person brauche, ist zweierlei:

1. Wir sollten Menschen nicht mit Fähigkeiten verwechseln. Was das Team braucht, ist die Fähigkeit. Das einfache Hinzufügen von Mitarbeitern für jede Fähigkeit kann teuer werden und Engpässe verstärken.

2. Für die meisten Teams liegt dies einfach nicht in ihrer Kontrolle. Es gibt einen Genehmigungsprozess für das Budget, einen Einstellungszeitraum, einen Trainingszeitraum (in dem das gesamte Team langsamer wird, um die neue Person zu schulen). Wie wird das Team in diesem Zeitraum etwas produzieren? Sind diese Monate nur eine Wäsche?

Theorie vs. Praxis

Okay, das war alles sehr viel Hintergrundtheorie und Nachdenken. Was ist also die praktische Antwort? An deiner Stelle würde ich folgende Schritte unternehmen:

1. Stellen Sie fest, ob ein Qualitätsproblem vorliegt. Teilen Sie Ihre Beobachtungen mit dem Team. Helfen Sie ihnen, das erwartete Qualitätsniveau mit dem PO und der Organisation (und dem Kunden, wenn möglich) zu überprüfen.

2. Wenn die Antwort „Ja, es gibt ein Qualitätsproblem“ lautet, bestimmen Sie, welche Fähigkeiten und Verhaltensweisen erforderlich sind, um es zu lösen. Auch dies ist eine Übung, die wir mit dem Team moderieren.

3. Bestimmen Sie, wie wir den Standard in diesem Sprint erfüllen können . Ich würde hier anfangen, weil wir durch das Gespräch erfahren, was jetzt möglich ist, was mit einer anderen Person möglich sein könnte und ob wir ohne eine andere Person mit tieferem Wissen einfach festsitzen.

4. Schaffen Sie Raum dafür. Hier wird Ihr Job hart. Sofern Nr. 3 nichts Praktisches entdeckt, benötigt Ihr Team möglicherweise Hilfe von anderen Teams, anderen Teilen der Organisation oder einer Vielzahl anderer Dinge, selbst wenn Sie keine andere Person benötigen (und wenn Sie dies tun, gibt es einen Prozess, mit dem Sie beginnen müssen das auch).

   Das Team sollte nicht arbeiten, um beschäftigt zu wirken – es sollte Produkte entwickeln. Wenn sie nicht das haben, was sie brauchen, können sie das Produktinkrement nicht erstellen, und sie sollten nicht nur an nichts Veröffentlichbarem arbeiten. In der realen Welt wird diese Antwort natürlich vielen Leuten nicht gefallen. Hier ist es sehr wichtig, andere in Ihrer Organisation zu coachen, damit sie verstehen, was auf dem Spiel steht und was das Team braucht, ohne nur wie ein Eiferer zu klingen.

   Ich hoffe, das ist nicht zu unverblümt, aber dafür hat das Team einen Scrum Master. Es ist ein großer Teil dessen, was Scrum zum Funktionieren bringt. Und wie es geht, ist so gut wie unmöglich, eine Stack Exchange-Antwort einzugeben (sorry).

5. Stellen Sie erstaunliche Produkte her! Feiern Sie eine gut gemachte Arbeit.

Dieser Artikel von Mike Cohn beantwortet weitgehend meine Frage:

https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

„Das Management übt subtile Kontrolle über die Selbstorganisation aus

In der Originalarbeit, in der Scrum beschrieben wird, identifizierten Takeuchi und Nonaka „subtile Kontrolle“ als eines seiner sechs Prinzipien. Sie führen Personalentscheidungen als eine Schlüsselverantwortung des Managements auf.

Die Auswahl der richtigen Personen für das Projektteam bei gleichzeitiger Überwachung von Veränderungen in der Gruppendynamik und das Hinzufügen oder Entfernen von Mitgliedern bei Bedarf [ist eine Schlüsselverantwortung des Managements]. „Wir würden dem Team ein älteres und konservativeres Mitglied hinzufügen, sollte sich das Gleichgewicht zu sehr in Richtung Radikalismus verschieben“, sagte ein Honda-Manager. „Wir wählen die Projektmitglieder nach langer Überlegung sorgfältig aus. Wir analysieren die verschiedenen Persönlichkeiten, um zu sehen, ob sie sich vertragen würden.

Die richtigen Leute für das agile Team gewinnen

Wenn Sie ein Personalmanager sind oder die Teamzusammensetzung in Ihrer Organisation anderweitig beeinflussen, sind hier einige der zu berücksichtigenden Faktoren.

Beziehen Sie alle erforderlichen Disziplinen in agile Teams ein

Als funktionsübergreifendes Team ist es wichtig, dass alle Fähigkeiten, die erforderlich sind, um von der Idee zum implementierten Feature zu gelangen, im Team vertreten sind. Dies kann zunächst bedeuten, dass die Teamgröße etwas größer ist als gewünscht. Aber im Laufe der Zeit werden Einzelpersonen in einem Scrum-Team einige der Fähigkeiten erlernen, die ihre Kollegen besitzen. Dies ist ein natürliches Ergebnis der Zugehörigkeit zu einem Scrum-Team. Da einige Teammitglieder breitere Fähigkeiten entwickeln, können andere Personen in andere Teams versetzt werden.

Mischung aus technischen Qualifikationsniveaus in agilen Teams

Abhängig von Überlegungen zur Teamgröße sollten Sie sich bemühen, das Qualifikationsniveau im Team auszugleichen. Wenn ein Team aus drei Senior-Programmierern und nicht weniger erfahrenen Programmierern besteht, müssen die Senior-Programmierer einige Funktionen mit geringer Kritikalität codieren, die sie langweilig finden könnten. Ein Junior-Programmierer mag es nicht nur genossen haben, an solchen Features zu arbeiten, dieser Programmierer würde auch davon profitieren, durch die Zusammenarbeit mit den Senior-Programmierern zu lernen.

Balancieren Sie Domänenwissen in agilen Teams

So wie wir uns bemühen, technische Fähigkeiten auszugleichen, sollten wir uns um ein Gleichgewicht zwischen denen bemühen, die über fundierte Kenntnisse des Bereichs, in dem wir arbeiten, oder des Problems, das wir zu lösen versuchen, verfügen. Das soll nicht heißen, dass wir die Gelegenheit, ein Team aus Fachexperten zusammenzustellen, nicht nutzen sollten. Vielmehr sollten wir die langfristigen Ziele unserer Organisation berücksichtigen. Eines dieser Ziele ist wahrscheinlich der Aufbau von Domänenwissen in der gesamten Organisation. Sie werden es schwer haben, dies zu erreichen, wenn Sie alle Domänenexperten in einem Team zusammenstellen.

Streben Sie nach Diversität in agilen Teams

Vielfalt kann viele verschiedene Dinge bedeuten – Geschlecht, Rasse und Kultur sind nur drei davon. Vielleicht ebenso wichtig kann sein, wie Einzelpersonen über Probleme denken, wie sie Entscheidungen treffen, wie viele Informationen sie benötigen, bevor sie eine Entscheidung treffen, und so weiter. Untersuchungen zeigen, dass homogene Teams schneller einen Konsens erreichen als heterogene Teams, aber sie tun dies, indem sie nicht alle Optionen in Betracht ziehen.

Berücksichtigen Sie Beharrlichkeit bei der Bildung agiler Teams

Es braucht Zeit, bis agile Teammitglieder lernen, gut zusammenzuarbeiten. Bemühen Sie sich daher, Teammitglieder zusammenzuhalten, die in der Vergangenheit gut zusammengearbeitet haben. Überlegen Sie bei der Bildung eines neuen Teams, wie lange die Mitglieder zusammenarbeiten können, bevor einige oder alle auf andere Verpflichtungen verteilt werden.“

Ich stimme ausdrücklich zu, dass "Teams nicht zufällig zusammengestellt werden". Unabhängig davon, ob Ihr Team in seiner Zusammensetzung strikt den in „irgendeinem Buch“ beschriebenen Organisationsprinzipien folgt und ob Sie sich selbst mit einem Titel bezeichnen, der in „irgendeinem Buch“ enthalten ist, lautet das Fazit, dass es Ihre Aufgabe ist, dafür zu sorgen, dass das Team funktioniert produziert qualitativ hochwertige Software, stetig und konsistent.

Daher: Sehen Sie ein Qualitätsproblem? Glauben die Entwickler, dass sie davon profitieren würden, eine engagierte Person zu haben, deren Aufgabe es ist, nichts anderes als das Testen zu tun? Du ?

Wenn das Team einen Meilenstein abschließt und abzeichnet, bleibt die Arbeit anschließend stabil?

Unabhängig davon, ob Sie eine separate Person haben, die testet, was andere getan haben, muss das Testen immer in den Softwareentwicklungsprozess eingebettet sein. Es reicht nicht aus, einen Block Quellcode zu schreiben: Sie müssen beweisen, dass es funktioniert. Und Sie müssen in der Lage sein, kontinuierlich zu testen, um sicherzustellen, dass das, was früher funktionierte, später nicht kaputt geht. Die Entwickler müssen dafür die erste und primäre Verantwortung tragen: "Sie schreiben den Code, und Sie schreiben die Tests." In der Zwischenzeit habe ich in einem großen Team wie Ihrem gerne jemanden, dessen Vollzeitjob darin besteht, den Überblick zu behalten, nach Regressionen zu suchen, jeden Knopf zu drücken und jedes Feld anzuklicken, während die Entwickler weitergezogen sind.

Ich glaube nicht wirklich, dass Entwicklungsteams „selbststeuernd“ sind, sein sollten oder wirklich sein können. Sie brauchen Führung und das bedeutet Sie.