Einführen einer agilen Kultur

Wenn es eine Lektion gibt, die aus dem letzten Jahrzehnt der „Agile-Transformationen“ gewonnen werden kann, ist es diese: Es gibt keine einheitliche Lösung für die Einführung oder Implementierung eines Agile-Ansatzes. Jede Organisation hat unterschiedliche Bedürfnisse, Einschränkungen und Anforderungen. Einer Vorgabe blind zu folgen, führt nicht zwangsläufig zum Erfolg.

Bei der Agile-Methode geht es darum, kontinuierlich Möglichkeiten zu finden, die Praxis beim Erstellen von Software zu verbessern. Es geht nicht um ein perfektes tägliches Standup oder eine Retrospektive. Stattdessen geht es darum, eine Kultur zu schaffen, in der oft das Richtige passiert. Aktivitäten wie Standups und Retrospektiven haben ihren Platz, aber sie ändern die Kultur einer Organisation nicht.

In diesem Artikel werden grundlegende Elemente beschrieben, die für jede Organisation erforderlich sind, um eine Agile-Denkweise und -Kultur zu schaffen. Die Empfehlungen sollten nicht blind befolgt werden. Jede Organisation sollte anwenden, was in einer bestimmten Umgebung sinnvoll ist.

Zeitplan und Rhythmus

Es gibt keine perfekte Sprintlänge. Teams waren erfolgreich mit Sprintlängen, die von einer bis vier Wochen reichen. Am wichtigsten ist die Konsistenz.

Wählen Sie eine Sprintlänge, die zur Kultur, dem Produkt und dem Wunsch Ihrer Organisation, Aktualisierungen bereitzustellen, passt. Beispielsweise arbeitet die Abteilung „Entwicklertools“ bei Microsoft (rund 6.000 Personen) in dreiwöchigen Sprints. Diese Sprintlänge wurde nicht vom Führungsteam ausgewählt. Sie entstand aus dem direkten Feedback der Ingenieurteams. Die gesamte Abteilung arbeitet nach diesem dreiwöchigen Sprintplan. Die Sprints sind seitdem zum Mittelpunkt der Organisation geworden. Jetzt bewegt sich jedes Team im gleichen Rhythmus.

Es ist wichtig, eine Sprintlänge zu wählen und dabei zu bleiben. Wenn es mehrere Agile-Teams gibt, sollten alle die gleiche Sprintlänge verwenden. Wenn Feedback zu einer Veränderung führt, dann seien Sie offen dafür. Es wird deutlich, wenn die richtigen Bedingungen vorhanden sind.

Eine Kultur der Auslieferung

Peter Provost, Principal Group Program Manager bei Microsoft, sagte: „Der Termin der Auslieferung steht.“ Die Einfachheit und Wahrheit dieser Aussage ist ein Eckpfeiler der Agile-Kultur. Was Peter meint, ist, dass Sie durch die Auslieferung Ihrer Software Dinge lernen, die Sie nicht verstehen können und werden, wenn Sie Ihre Software nicht tatsächlich ausliefern.

Es liegt in der Natur des Menschen, Dinge zu verzögern oder zu vermeiden, bis sie absolut notwendig sind. Dies könnte nicht zutreffender sein, wenn es um die Softwareentwicklung geht. Teams verzögern Fehler bis zum Ende des Zyklus, denken erst dann über die Einrichtung oder Aktualisierung nach, wenn sie dazu gezwungen werden, und vermeiden in der Regel Dinge wie Lokalisierung und Zugänglichkeit, wo immer es möglich ist. Wenn dieses Muster entsteht, bauen Teams technische Schulden auf, die zu einem späteren Zeitpunkt gezahlt werden müssen. Eine Auslieferung verlangt, dass alle Schulden bezahlt werden. Der Termin der Auslieferung steht. Um eine Agile-Kultur zu etablieren, versuchen Sie zunächst, das Produkt am Ende jedes Sprints auszuliefern. Anfangs wird es nicht einfach sein, aber wenn ein Team es versucht, entdeckt es schnell alle Dinge, die passieren sollten, aber nicht passieren.

Gesunde Teams

Es gibt kein Rezept für das perfekte Agile-Team. Einige Schlüsselmerkmale machen den Erfolg jedoch viel einfacher.

Teams nach Möglichkeit am selben Ort unterbringen

Kann ein Team Erfolg haben, wenn die Mitglieder über verschiedene Regionen verteilt sind? Ja, aber es ist schwieriger. Wenn sich Personen am selben Ort befinden und im selben Raum sitzen, kommt es meist zu den richtigen Gesprächen. Es ist weiterhin möglich, mit Teams auf der ganzen Welt und verschiedenen Zeitzonen erfolgreich zu sein. Aber hätte das gleiche Team keinen Vorteil ohne all diese Hindernisse?

Teams für eine angemessene Zeit intakt halten

Ermöglichen Sie Teams, die Kunst der gemeinsamen Erstellung von Software zu meistern. Wenn Teams neu gemischt werden, gerät die Chemie ins Wanken, die sie entwickelt haben. Manchmal ist eine Umstrukturierung angebracht, aber Teams sind in der Regel produktiver, wenn sie Zeit haben, zu lernen, wie man zusammenarbeitet. Versuchen Sie als Richtlinie, Teams mindestens 12 Monate lang intakt zu halten.

Verteilen Sie Arbeit, keine Mitarbeiter

Manchmal fallen Teams zurück und benötigen Hilfe. Eine gängige Taktik, dieses Problem anzugehen, besteht darin, eine Person von einem Team an ein anderes auszuleihen. Das kann jedoch kontraproduktiv sein. Eine bessere Lösung besteht darin, die Arbeit auf ein anderes Team zu verteilen, anstatt die Last zwischen den einzelnen Teams zu verteilen. Wenn Sie eine Person aus einem Team ziehen, um einem anderen zu helfen, stört dies beide Teams und kann die Person, die versetzt wird, frustrieren, selbst wenn es nur vorübergehend ist. All dies hat Auswirkungen auf die Teamproduktivität und wirkt sich höchstwahrscheinlich negativ auf die Fähigkeit aus, den Zeitplan wieder einzuhalten.

Durch die Lastverteilung von Arbeit anstelle von Mitarbeitern kann ein bereits etabliertes Team eingreifen und helfen. Es wird ein Gespräch über Prioritäten, nicht ein Gespräch über Mitarbeiter.

Teams Besitzer von Funktionsbereichen und nicht von Architekturebenen sein lassen

Bemühen Sie sich, vertikale Teams aufzubauen, die über Funktionsbereiche verfügen. Diese Teams sind für alle Arbeiten verantwortlich, die zum Hinzufügen von Funktionen zu ihrem Bereich erforderlich sind, von der Datenbank bis hin zu Änderungen an der Benutzeroberfläche. Das Team ist in der Lage, eine End-to-End-Erfahrung bereitzustellen und zu besitzen.

Wenn horizontale Teams eigene Architekturebenen besitzen, ist kein einzelnes Team für die End-to-End-Erfahrung verantwortlich. Das Hinzufügen einer Funktion erfordert die Koordination mehrerer Teams und ein höheres Maß an Abhängigkeitsmanagement. Um Fehler zu beheben, müssen mehrere Teams untersuchen, ob sie über den Code verfügen, der zur Behebung des Fehlers erforderlich ist. Fehler werden umgangen, wenn die Teams feststellen, dass es sich nicht um ihren Fehler handelt, und einem anderen Team zugewiesen.

Featureteams haben diese Probleme nicht. Besitz und Verantwortlichkeit sind klar. Möglicherweise gibt es einen Platz für einige Architekturteams. Vertikal fokussierte Teams sind jedoch effektiver.

Nächste Schritte

Wenn Teams ihre eigene Agile-Transformation in Angriff nehmen, sollten Sie diese Grundprinzipien im Hinterkopf behalten. Denken Sie daran, dass es kein einziges Rezept gibt, das für jede Organisation funktioniert. Agile-Transformationen sind eine Reise. Nehmen Sie Änderungen vor, und lernen Sie daraus. Im Laufe der Zeit wird die Organisation die Agile-Kultur entwickeln, die sie benötigt.

Microsoft ist einer der weltweit größten Agile-Unternehmen. Erfahren Sie mehr darüber, wie Microsoft eine Agile-Kultur für die DevOps-Planung eingeführt hat.

Erfahren Sie, wie Azure DevOps es Teams ermöglicht, eine Agile-Kultur einzuführen und zu skalieren.