Sollen wir mehrere agile Subteams entlang von Kundengruppen oder entlang von Softwarekomponenten anordnen?

Experiment.

Keine der hier präsentierten Antworten passt zu Ihrem spezifischen Produkt, Team oder Kunden. Agile fördert die kontinuierliche Verbesserung, also machen Sie es.

In Anbetracht dessen können wir einige wichtige Punkte überprüfen, die beim Experimentieren zu berücksichtigen sind:

• Warum ändern? Klären Sie die Probleme, die das Team durch Anwenden dieser Änderungen angehen soll. Veränderung um der Veränderung willen „um agiler zu werden“ ist kein wirklicher Zweck. Ihr eigentliches Ziel ist es, häufiger und mit Vorhersagbarkeit Mehrwert zu liefern. Agile ist ein Werkzeug, das Ihnen dabei helfen kann.

• Teams sollten in der Lage sein, ein vollständiges Produkt zu liefern . Wenn Sie Teams nach funktionalen Komponenten organisieren, verfügen Sie über mehr Fachwissen zu dieser spezifischen Komponente, aber am Ende haben Sie möglicherweise ein großartiges Team in der Benutzeroberfläche, das viele Änderungen bereitstellt, die nicht aktiviert werden können, weil das Back-End-Team nicht so erfahren ist.

• Verstehen Sie Ihren aktuellen Wissenshintergrund . Wenn Sie eine einzelne Person haben, die die Benutzeroberfläche durchführt, und dies der Schlüssel für alle Lieferungen ist, wird es schließlich zu einem Engpass führen, wenn verschiedene Teams von dieser einzelnen Person abhängen.

Der Wissenshintergrund ist eine der komplexesten Veränderungen für voll funktionsfähige agile Teams. Wenn Ihr Team auf das Wissen bestimmter Personen angewiesen ist, würde ich Folgendes vorschlagen, bevor Sie die Teamstruktur ändern:

1. Überprüfen Sie den aktuellen Wissenshintergrund der Teammitglieder
2. Wo sind die Lücken oder potenziellen Engpässe, wenn jemand krank wird und dann
3. mit dem Team diskutieren, das seinen Wissenshintergrund in diesen Bereichen erweitern möchte

Denken Sie daran, dass Sie nicht in allen Bereichen Experte sein müssen (ich halte einen „Full-Stack-Entwickler“ in den meisten Fällen immer noch für einen Trugschluss). Stattdessen sollte man über ein T-förmiges Skillset verfügen , das es jedem Subteam ermöglicht, mit minimaler Abhängigkeit von anderen Teams zu liefern.

Diese Frage ist schwer zu beantworten, da sie von Ihrem Unternehmen abhängt. Die allgemeine Richtlinie lautet, das Team in Richtung Wertschöpfung zu optimieren. Normalerweise wird eine solche Frage gestellt: Sollen wir Teams um Systemkomponenten und Funktionsbereiche herum organisieren? Die Antwort auf diese Frage ist einfacher, da bei Systemkomponenten kein Team den Benutzern allein eine wertvolle Funktion liefern kann. In Ihrem Fall klingt es jedoch so, als könnten beide potenziell ein vollwertiges Feature für sich allein bereitstellen, sodass sich die Frage stellen könnte, was besser oder öfter ein wertvolles Feature für sich allein bereitstellen kann?

Ein weiteres Modell, das bei einer so kleinen Anzahl von Entwicklern in Betracht gezogen werden sollte, sind vollständig austauschbare Teams. Wenn alle Teams alle Arbeiten erledigen können, kommen Sie immer am schnellsten zu Ihren wichtigsten Funktionen.

Es scheint mir, dass es klüger ist, es um Softwarekomponenten herum zu tun, weil es so aussieht, als könnten die Teams Entscheidungen besser kontrollieren, da sie den Input von mehreren Clients in ein einziges Feature erhalten.

Wenn Sie es umgekehrt machen: Wenn mehrere Teams an derselben Komponente mit unterschiedlichen Kundeneingaben arbeiten, besteht die Möglichkeit, dass Sie sich gegenseitig auf die Füße treten.

Sie müssen Folgendes berücksichtigen:

• Wie messen Sie den Erfolg? Was denkst du, dass es nach dem Wechsel passieren wird?
• Könnten Sie schrittweise "Piloten" durchführen und sehen, ob sie tatsächlich einen Nutzen haben? (Beispiel: Verschieben Sie ein Team, das an einer einzelnen Softwarekomponente arbeitet, und prüfen Sie, ob dies die Leistung in irgendeiner Weise verbessert)