Interaktionen zwischen agilen Teams in einem Softwareunternehmen

Wir versuchen, Kanban in unserem Entwicklungsprojekt einzusetzen. Unser Team ist eines von vielen anderen agilen Entwicklungsteams in unserem Unternehmen. Die anderen Teams können entweder Scrum oder Kanban oder etwas anderes verwenden (manchmal nichts, nehme ich an).

Alle Teams arbeiten an einem großen Projekt, aber dieses große Projekt ist in Teilprojekte unterteilt und jedes Team arbeitet an einem Teilprojekt.

Es gibt eine ziemlich starke Interaktion zwischen den Teams:

  • Ein Team kann ein anderes Team bitten, eine Codeüberprüfung seines Pull-Requests durchzuführen
  • Ein Team kann für eine Expertenberatung zu einem anderen Team kommen
  • Ein Team kann ein anderes Team bitten, einen kritischen Fehler zu beheben
  • usw

Diese Interaktionen fallen in zwei Gruppen:

  • zusätzliche Arbeit (verringern Sie die Geschwindigkeit unseres Teams und erhöhen Sie den Kontextwechsel)
  • Blocker (z. B. Warten auf eine Codeüberprüfung)

Also denke ich über Möglichkeiten nach, diese Interaktionen effektiv zu verwalten. Wir haben immer viele Aufgaben mit hoher Priorität in unserem eigenen Projekt, ebenso wie die anderen Teams, also sollten die Manager anscheinend zuerst zu einer gemeinsamen Richtlinie über diese Interaktionen kommen.

Haben Sie Erfahrung mit einem solchen teamübergreifenden Aufgabenmanagement? Wie kann man das alles angehen?

Arbeiten diese Teams alle an demselben Produkt oder gibt es mehrere Produkte und einige Fälle teamübergreifender Interaktion, die einfach eine Frage des Wissens und der Erfahrung sind?
Warum versuchen Teams, den internen Zustand für Externalitäten zu verfolgen? Entweder Sie haben ein gemeinsames Projekt oder nicht. Anstatt sich auf Framework-spezifische Lösungen zu konzentrieren, möchten Sie vielleicht das tatsächliche geschäftliche oder politische Problem beschreiben, das Sie letztendlich zu lösen versuchen.
Alle Teams arbeiten an einem großen Projekt, aber dieses große Projekt ist in Teilprojekte unterteilt und jedes Team arbeitet an einem Teilprojekt.
Wer ist in Ihrem Projekt für die Integration zwischen Workstreams, Funktionen und Ergebnissen verantwortlich ?

Antworten (2)

Hier gibt es einiges zu bedenken.

Erstens: Wie definieren Sie Ihre Prioritäten? Wenn sie nur auf individueller Teamebene definiert werden, wird es schwierig, Anfragen von anderen Teams zu priorisieren.

Im Idealfall muss dort, wo die Arbeit geteilt wird, eine klare Priorisierung auf oberster Ebene vorhanden sein, damit die Teams leicht wissen, woran sie als Nächstes arbeiten sollten.

Zweitens sollten Sie versuchen, die Teams zur Selbstorganisation zu befähigen. Zeremonien wie Scrum-of-Scrums können hilfreich sein, um den Teams zu ermöglichen, regelmäßig miteinander zu sprechen.

Schließlich wäre es sinnvoll, darüber nachzudenken, wie teamübergreifende Abhängigkeiten reduziert werden können. Zusätzliche Schulungen und Wissensaustausch können dabei wirklich helfen. Es hilft auch, wenn Sie über eine konsistente Codebasis verfügen, sodass es für Teams relativ einfach ist, an Bereichen des Codes zu arbeiten, in denen sie normalerweise nicht arbeiten. Dies, kombiniert mit einer guten automatisierten Regressionstestabdeckung, kann Teams ermutigen, ihre eigenen zu reparieren Probleme, anstatt sich darauf verlassen zu müssen, dass andere Teams dies für sie erledigen.

Eine „konsistente Codebasis“ wird „Teams ermutigen, ihre eigenen Probleme zu lösen“? In einem Setup, in dem Teams andere Teams bitten, "Fehler zu beheben"? Sie werden einfach den Code für diesen Eckfall ändern, in dem das Verhalten nicht angegeben wurde?
Das ist definitiv eine Gefahr und unterstreicht, warum die Teams häufig miteinander sprechen müssen. Zum Beispiel würde ich hoffen, dass jemand, der kurz davor steht, einen Fehler in einem Code zu beheben, an dem er normalerweise nicht arbeitet, sich zuerst mit jemandem unterhalten würde, der damit besser vertraut ist. Chapters und Communities of Practice sollten ebenfalls helfen.
Ich habe eine Geschäftslogik gesehen, die aufgrund eines hässlichen Designfehlers (unglückliche und unnötige Annahme) über mehrere Ebenen verteilt ist, andere Entwickler stoßen auf einen Teil davon und finden, dass es falsch ist, studieren das Multithread- und asynchrone Verhalten und ändern den Code zum schlechteren. Und am Ende scheint die Hauptursache ein einzelner technischer Schuldposten zu sein, der das gelegentliche Publikum hinsichtlich seiner Schwere etwas irreführt. Reden half hier nicht viel.
@loomwithacrew, das Gerede hätte bewirken sollen, dass die unvorsichtigen Entwickler auf den Designfehler aufmerksam wurden und mit äußerster Vorsicht vorgehen sollten.
@BartvanIngenSchenau wirklich "sollte mit Vorsicht vorgehen", das Designproblem nicht beheben?
@loomwithacrew, das Beheben des Konstruktionsfehlers könnte bevorzugt werden, ist aber wahrscheinlich wirtschaftlich nicht machbar oder ich denke, es wäre in Betracht gezogen worden.

(Meine Erfahrung ist mit agilen Frameworks, die in Timebox-Sprints funktionieren. Einige dieser Punkte gelten nicht direkt, wenn Sie einem kontinuierlichen Prozess-Framework wie Kanban folgen.)

Die beste Antwort hängt davon ab, warum diese Interaktionen zwischen den Teams stattfinden.

Hier sind einige Möglichkeiten, die ich mir vorstellen kann:

  1. Problem mit der Teamzusammensetzung

Ein agiles Team sollte über alle notwendigen Fähigkeiten verfügen, um seine Arbeit zu erledigen. Gilt das für diese Teams? Wenn nein, warum nicht? Kann die Zusammensetzung der Teams überprüft werden?

  1. Problem mit Projekt -> Teilprojektzerlegung

Wurden die Teilprojekte mit dem Ziel definiert, sie zu orthogonalen, unabhängigen Projekten zu machen, die von unabhängigen Teams mit minimaler Koordination bearbeitet werden können? Oder wurden sie auf einer anderen Grundlage geteilt, die jetzt Schwierigkeiten bereitet, und wenn ja, kann dies erneut geprüft werden?

  1. Problem mit Team-Overcommitment

Bittet Team A um Arbeit von Team B, weil es Hilfe braucht, um seine Aufgaben innerhalb der definierten Zeit zu erledigen? Wenn dies der Fall ist, müssen die Teams bei der Kapazitätsplanung besser werden: Fähigkeiten wie Backlog-Verfeinerung und -Schätzung.

Auf einer etwas anderen Anmerkung: Kein Team sollte Arbeit planen, um 100 % seiner theoretischen Kapazität auszuschöpfen. Ein Ziel von ~70 % lässt den Entwicklern Raum für andere Arbeiten, die während der Timebox anfallen: ob es sich dabei um neu entdeckte Komplexität oder überraschende Fehlerbehebungen, laufende Wartung oder Schulung handelt ... oder um Anfragen von anderen Teams, ihr Fachwissen zu teilen .

  1. Sorge um Silobildung

Dies ist wahrscheinlich der beste Grund, der mir einfällt, weil es eine gute Absicht hat, obwohl die Implementierung Probleme verursacht. Wenn es der Wunsch der Organisation ist, dass Teams zum Zweck des Wissenstransfers an den Code-Reviews der anderen teilnehmen usw., dann gibt es vielleicht weniger störende Möglichkeiten, dies zu tun.

Ein paar andere Gedanken:

  • Wenn Team A im Voraus weiß, dass es Hilfe von Team B benötigen wird, um ein Arbeitselement in einem zukünftigen Sprint erfolgreich abzuschließen, ist es eine gute Idee, Team B früh genug darüber zu informieren, damit es in die Planungsdiskussionen von Team B einbezogen werden kann für ihren jeweiligen Sprint.

Aus praktischen Gründen habe ich damit begonnen, Etiketten wie „teamb_support“ auf solche Tickets zu kleben, damit wir diese Support-Anfrage schnell genug sehen und daran erinnert werden können, Team b nicht zu überraschen.

  • Ein Grund für die Verwendung relativ kurzer Timeboxes für Sprints ist es, die Leute leichter bitten zu können, bis zum Ende des aktuellen Sprints zu warten. „Respektiere die Timebox“ bedeutet normalerweise „lass die Dinge nicht darüber laufen“, aber es bedeutet auch „schieb nicht noch mehr Dinge hinein“. Allen in der Organisation schrittweise beizubringen, die Timebox in beiderlei Hinsicht zu respektieren, erfordert Zeit und die Fähigkeit, alle Anfragen tatsächlich bis zum nächsten Sprint aufzuschieben (was möglicherweise die Unterstützung des Managements und/oder der anderen Teamleiter erfordert).

Diese beiden Punkte wirken zusammen: Während Team A erfährt, dass Team B mitten in einem Sprint nicht auf eingehende Anfragen reagieren wird, lernt Team A auch, wie der Sprint- (oder andere Planungs-) Rhythmus von Team B ist, und lernt, im Voraus zu fragen .

Interaktionen zwischen agilen Teams in einem Softwareunternehmen
AntwortenHierDatenschutz-Bestimmungen1y, 0v