Was sind Lieferpläne?
Wenn Entwicklungsorganisationen wachsen, müssen sie sich in kleineren Teams neu organisieren, die portionierte Arbeitseinheiten effizient verwalten können. Diese Teams verfügen in der Regel über Arbeitszeitpläne, Boards und andere Prozesse, die den individuellen Anforderungen im Kontext der größeren Organisationsziele gerecht werden. Im Laufe der Zeit stellen Organisationen möglicherweise fest, dass sie von Netzwerkvorteilen profitieren können, wenn sie ihre Prozesse um ein einheitliches Framework konsolidieren.
Bei einem Lieferplan handelt es sich um eine Visualisierung mindestens eines Arbeitszeitplans. Er soll den Teams und der Verwaltung einen Gesamtüberblick darüber geben, was die einzelnen Teams wann produzieren möchten. So können Entscheidungen getroffen werden, mit denen sich die Investitionen in der gesamten Organisation optimieren lassen.
Teams müssen ihre Lieferpläne regelmäßig prüfen, um sicherzustellen, dass ihr Arbeitszeitplan den Terminplänen anderer Teams entspricht. Dabei sollten sie sich Fragen wie den folgenden widmen:
- Können wir uns darauf verlassen, dass wir das, was wir zugesichert haben, nach unserem aktuellen Zeitplan liefern können?
- Können wir uns darauf verlassen,dass die Teams, auf die wir angewiesen sind, das, was wir benötigen, nach ihrem aktuellen Zeitplan liefern?
- Gibt es in unserem Zeitplan Lücken, die wir mit Arbeit füllen könnten?
- Gibt es Probleme mit Abhängigkeiten innerhalb eines Teams oder teamübergreifend?
Lieferpläne stellen zu jedem Zeitpunkt im Lebenszyklus eines Projekts einen Mehrwert dar. Da sie basierend auf dem Backlog eines Teams dynamisch generiert werden, sind sie immer aktuell und liefern neueste Erkenntnisse.
Begleiten wir das Webteam von Tailspin bei einer Besprechung.
Andy: Ich hatte gerade ein gutes Gespräch mit dem Engineering Management. Ich habe unsere Arbeit mit Azure Boards vorgestellt, und das Management ist begeistert von der Aussicht, andere Teams an Bord zu holen.
Mara: Prima. Wann geht es los?
Andy: Das ist das Beste daran. Das haben sie bereits! Gestern Abend hat der Leiter des Spiel-Engine-Projekts ein Team mit ein paar Sprints erstellt und bereits Arbeitselemente hinzugefügt. Ich habe heute Morgen einen kurzen Blick darauf geworfen, und es sieht ganz gut aus. Ich zeige mal, was sie vorhaben.
Andy navigiert zum aktuellen Sprint-Board der Spiel-Engine. Er und Mara sehen sich die Arbeitselemente mit großem Interesse an.
Andy: Hmm...Mir fällt gerade auf, dass das Team die Bereitstellung der Betaversion bis zum Ende dieses Sprints nicht eingeplant hat. Wollten wir nicht bei unserem nächsten Sprint unser Leaderboard auf die Betadatenbank abstimmen? Das ist nicht möglich, wenn das Team die Betaversion nicht vorher ausliefert.
Mara: Das stimmt. Wir sind darauf angewiesen, dass das Team seine Projektleistung erbringt, damit wir unsere eigene Projektleistung erbringen können.
Andy: Das könnte unserer Produktivität beim nächsten Sprint schaden. Ich werde das Team anrufen, um herauszufinden, was los ist.
Leider kann es bei komplexeren Teamstrukturen zu Lücken oder Verzögerungen in der Kommunikation kommen. Wenn ein Team blockiert ist, kann es möglicherweise etwas nicht produzieren, das von einem anderen Team benötigt wird. Für eine kleine Gruppe von Teams mit täglichen Besprechungen für alle Beteiligten, ist dies möglicherweise kein großes Problem. Je größer Teams werden und je mehr Standorte es gibt, umso schwieriger wird es, dass immer alle darüber informiert sind, was im Einzelnen vor sich geht. Irgendwann ist der Punkt erreicht, an dem Organisationen von einem reinen Pushmodell (wie persönliche Ankündigungen oder Ankündigungen per E-Mail) zu einem Pullmodell (bei dem Teams die Zeitpläne der anderen einsehen und nachverfolgen können) wechseln müssen.
Andy: Okay, ich habe eben mit der Entwicklungsleiterin gesprochen. Sie hat mir gesagt, dass ihr Team die Betaversion erst ausliefern kann, wenn das Grafikteam aus Cliffchella zurückgekehrt ist.
Mara: Vom Mountaintop-Musikfestival?
Andy: Ja, anscheinend ist das in der Designcommunity eine wichtige Veranstaltung, und das gesamte Team hat sich für eine ganze Woche verabschiedet, um daran teilzunehmen. Das Spiel-Engine-Team ist ziemlich verärgert, weil sich dadurch der Zeitplan um drei Wochen verschiebt. Wenn das Team das vorausgesehen hätte, hätte es dafür gesorgt, dass es die benötigten Artefakte vorher bekommen hätte. Das Team hat sich auch entschuldigt, dass es uns nicht früher informiert hat. Dem Team war nicht klar, dass wir für die Lieferung unseres Teils auf seine Betaversion warten.
Mara: Nun, zumindest können wir froh sein, dass das Team für die Spiele-Engine seine Sprintpläne veröffentlicht. Das hat uns geholfen, dieses Abhängigkeitsproblem frühzeitig zu erkennen, sodass wir unseren Zeitplan anpassen können.
Andy: Ich wünschte nur, es gäbe eine Möglichkeit, diese potenziellen Risiken leichter zu erkennen. Zwischen unseren Teams bestehen so viele Abhängigkeiten im gesamten Unternehmen, dass es nicht möglich ist, an allen Besprechungen teilzunehmen und alle Verteilergruppen zu abonnieren.
Mara: Wir sollten einen Lieferplan erstellen, sodass unsere Teamsprints nebeneinander angezeigt werden. Dadurch können beide Teams leichter erkennen, wie sich die beiden Zeitpläne gegenseitig beeinflussen.
Empfehlungen für die Verwaltung verschiedener Agile-Teams
Projekttransparenz und Vorhersagbarkeit können mit einem Agile-Ansatz und Azure DevOps erheblich verbessert werden. Allerdings können bei Projekten weiterhin herkömmliche Herausforderungen auftreten, die häufig auf das Personal oder eine Fehlkommunikation zurückzuführen sind. Folgende Aspekte sollten Sie beim Skalieren Ihres Agile-Aufwands berücksichtigen.
Aufbau von Vertrauen in Mitarbeiter und Prozesse
Anfängliche Kritiker von Agile-Implementierungen zweifeln häufig an ihrer Fähigkeit, die Teamleistung verbessern zu können. Daher ist es wichtig, dass Vordenker in der Organisation Vertrauen aufbauen, indem sie zeigen, welche Ergebnisse die Tools und Prozesse liefern. Manchmal bedeuten diese Ergebnisse Produktivitätsverbesserungen, die leicht zu quantifizieren sind. Vergessen Sie jedoch nicht, die Teamgewinne hervorzuheben, die sich aus der Umgehung potenzieller Probleme wie vermeidbare Zeitplanverschiebungen oder Qualitätsprobleme ergeben. Wenn Mitarbeiter*innen beginnen, die Vorteile mit dem Prozess in Verbindung zu bringen, der sie erreicht hat, werden sie mehr Begeisterung aufbringen.
Erheben der Organisation über das Team (und den Einzelnen)
Einige Teams und Mitarbeiter sind eher reserviert, wenn neue Prozesse oder Richtlinien vorgeschlagen werden. Anstatt neue Richtlinien so zu gestalten, dass sie die Leistung bestimmter Teams oder Mitarbeiter negativ darstellen, sollten Sie hervorheben, wie durch die neue Transparenz in der gesamten Organisation alle über Erwartungen informiert werden. Wenn es einen zentralen Ort gibt, an dem jeder nachverfolgen kann, welchen Beitrag seine Arbeit zum Erreichen der Organisationsziele leistet, wird deutlich, wie wichtig das Engagement des Einzelnen für den Prozess ist.
Fördern einer Kultur der Transparenz
Leider hat der Begriff „Transparenz“ einen schlechten Unterton. Niemand fordert mehr Transparenz, wenn alles gut läuft. Vielmehr wird häufig mangelnde Transparenz dafür verantwortlich gemacht, wenn Teams Probleme haben. Selbst bei allen Möglichkeiten der Transparenz, die sich für Agile-Teams ergeben, unterliegt sie immer noch der Ehrlichkeit der einzelnen Mitarbeiter und der Teams. Erläutern Sie, dass für Transparenz spricht, dass potenzielle Probleme rechtzeitig erkannt und behoben werden können, bevor es zu spät ist. Jeder weiß, dass es manchmal Situationen gibt, die uns daran hindern, Termine einzuhalten. Wenn Mitarbeiter sich jedoch nicht trauen, enttäuschende Nachrichten zu überbringen, und bis zur letzten Sekunde damit warten, kann das viel verheerendere Auswirkungen haben. Der Aufbau einer Vertrauensbasis mit Transparenz kann damit beginnen, dass Sie sich bei Ihren Mitarbeitern dafür bedanken, dass diese erwartete Verzögerungen so früh wie möglich melden.