Wer sollte für die Aufteilung von Scrum-Teams verantwortlich sein?

So viele Antworten darauf. Es wird von Ihrer Organisation abhängen. Irgendwo wie Zappos oder Valve ist völlig selbstorganisiert und sogar selbstgesteuert. Lassen Sie uns jedoch mit Ihrer durchschnittlichen Softwareentwicklungsfirma als Ihrer "durchschnittlichen" Antwort fortfahren.

Dann haben Sie noch zwei Antworten, „jetzt“ und „Zukunft“.

Mit 100 Entwicklern sprechen Sie von einer großen Organisation. Selbst wenn Sie sehr knapp mit Personal umgehen, haben Sie wahrscheinlich insgesamt über 200 Mitarbeiter im Unternehmen. Denken Sie vorerst an 150, da dies wichtig ist. Nach 150 überschreitet man die „Stammes“-Grenze des menschlichen Geistes. Wenn Ihr Unternehmen über 150 ist, können nicht alle verbunden bleiben.

Wenn Sie sich auf die 100 Entwickler konzentrieren, sprechen Sie von 11 bis 15 Scrum-Teams. Nicht 10. Das ist wichtig, da die Teamgröße auf der tatsächlichen Größe basiert. Ab acht wird es immer schwieriger, Kommunikation und Zusammenarbeit zu managen. Es gibt einen Grund, warum Telefonnummern in den USA aus sieben Grundziffern bestehen.

„Jetzt“ – Scrum Master, Product Owner und das Team sollten unbedingt alle ihren Beitrag zum Prozess leisten. In einer durchschnittlichen Softwareorganisation muss jedoch das Management die endgültige Entscheidung treffen. An diesem Punkt einer agilen Transformation sortieren Sie noch viel aus und beschäftigen sich mit Legacy-Modellen. Sie müssen auch die Produktanforderungen berücksichtigen. Wenn sich alle UI-Jungs selbst in einem Team organisieren, werden sie nicht die Fähigkeiten haben, die sie brauchen, um ein gutes Team zu bilden (ganz zu schweigen von dem Mangel an QA).

Beginnen Sie damit, zu verstehen, was Sie tun müssen. Möglicherweise haben Sie einige spezifische Anforderungen, wie z. B. eine API, die die Zusammensetzung bestimmter Teams vorantreiben.

Dann verstehe die Leute. Es kann sehr hilfreich sein, wenn jeder in der Organisation ein Kommunikationsprofil erstellt. Persönlich empfehle ich DISC. Sie möchten ein Team nicht mit nur einem Kommunikationstyp besetzen, es wird unabhängig vom Kommunikationstyp scheitern.

Endlich verstehen, was jetzt funktioniert. Sie haben wahrscheinlich Leute, die bereits gut zusammenarbeiten. Versuchen Sie, dies zu nutzen, um den Teambildungszyklus (Forming, Storming, Norming, Performing) zu verkürzen.

„Zukunft“ – Der erste Schritt zu einem Zukunftsmodell besteht darin, es Teams so zu gestalten, dass sie einen Mechanismus haben, um zu beantragen und zu gewähren, dass jemand aus ihrem Team entfernt wird. Das Team wird als Team gemessen. Wenn sie jemanden haben, der nicht passt oder seinen Teil der Arbeit nicht erledigt, muss das Team wissen, dass es verlangen kann, dass diese Person versetzt wird.

Später können Sie zu einem flexibleren Modell wechseln, das es Teams ermöglicht, neue Formationen vorzuschlagen. Das ist jedoch seine eigene Ebene der Transformation und jenseits dessen, was Sie meiner Meinung nach gerade wollen.

Dies ist ein guter Artikel (von Craig Larman und Ahmad Fahmy) , der dieses Problem in realen Situationen beschreibt.

Laut diesem Artikel:

• Teams sollten selbst entworfen werden (es bedeutet , dass es den Leuten erlaubt sein sollte, selbst Teams zu bilden ).

• Dieser Prozess sollte einen Moderator haben , der den Menschen hilft, sich in ausgewogenen funktionsübergreifenden Teams zu organisieren.

Craig Larman ging von folgendem Ansatz aus (der von einem anderen Manager in China verwendet wurde):

Anstatt über die neuen Teams zu entscheiden, lud der chinesische Abteilungsleiter Lv Yi (zusammen mit Bas Vodde, einem Scrum-Experten, der in der Gruppe arbeitete) alle in einen großen Raum ein, erklärte das Ziel neuer Scrum-Teams und fragte einfach nach Gruppenmitglieder untereinander entscheiden. Die Gruppe war sich einig, dass dafür vier Stunden benötigt würden, und Lv Yi sagte: „Ich werde in vier Stunden wiederkommen, und wenn einige Leute sich bis dahin nicht entschieden haben, werde ich entscheiden.“ Vier Stunden später und nach vielen Gesprächen und Aktivitäten hatte die Gruppe ihre neuen Teams selbst entworfen. Dann wurden freiwillige ScrumMaster in die Mitte des Raums gebracht, und die Teams wählten die ScrumMaster aus, die sie wollten.

Dann verbesserte er diesen Ansatz und erleichterte ihn (um selbst entworfene Teams ausgewogener und funktionsübergreifender zu machen).

Alle weiteren Details zu diesem Teilungsprozess können Sie im obigen Artikel nachlesen.

Ich bin auf die gleiche Frage gestoßen, als ich die PSM-Prüfung von Scrum.org abgelegt habe. Die kurze Antwort lautet:

• Sie geben den Menschen die Vision – wofür sollen die Teams zusammengesetzt werden? An welchen Projekten werden sie arbeiten? Wie sind die Liefererwartungen etc
• Lassen Sie die Leute sich selbst in die Teams aufteilen.

So können Sie es tun

1. Der aktuelle Scrum Master muss das Team mit Hilfe des Product Owners und basierend auf den Modulen/Features brechen.

2. Sie erhalten also ein funktionsorientiertes Team, und der Scrum Master kann seine Verantwortung an ein berechtigtes Mitglied jedes Teams delegieren, und dieses Mitglied fungiert als Scrum Master für dieses bestimmte Team.