Suche

Wie sieht Agilität in 20 Jahren aus?

Nachdem wir einen Blick in die Zukunft geworfen haben, ist es auf jeden Fall interessant, sich auch einmal das bereits Erreichte anzusehen: Auf der einen Seite ist es durchaus ernüchternd, dass das Agile Manifest schon zehn Jahre alt ist und sich die beschriebenen Werte und Prinzipien erst seit Kurzem durchzusetzen beginnen. Auf der anderen Seite hat es in den vergangenen Jahren auch sehr viele neue Entwicklungen gegeben, die uns durchaus positiv stimmen dürfen. Da ist zuerst einmal die Erkenntnis, dass weder die agilen Programmiertechniken allein, wie sie eXtreme Programming stark in den Vordergrund stellt, noch ein reines agiles Managementframework à la Scrum für sich isoliert betrachtet zum langfristigen Erfolg führen. Scrum lässt sich leichter einführen und zeigt schneller erste positive Ergebnisse, weshalb es auch in vielen Fällen den besseren Startpunkt bildet. Aber um tatsächlich regelmäßig funktionierende Software auszuliefern und möglichst flexibel bleiben zu können, sind Praktiken wie inkrementelles Design oder testgetriebene Entwicklung früher oder später unerlässlich. Deshalb ist es auch nur folgerichtig, dass die Scrum Alliance den „Certified Scrum Developer“ als dritten großen Bereich in ihr Zertifizierungsprogramm mit aufgenommen hat (obwohl sich über den Sinn und Unsinn von Zertifizierungen natürlich trefflich streiten lässt).

Eng zusammen mit diesem Punkt hängt die Erkenntnis, dass man nicht nur die Rückendeckung des Managements braucht, um eine Organisation auf agile Verfahren umzustellen, sondern auch die Akzeptanz der Abteilungs- und Entwicklungsleiter sowie der Teammitglieder. Agilität bedeutet eben nicht nur ein paar Änderungen an der Oberfläche, sondern einen grundlegenden Kulturwandel, der sich nicht von heute auf morgen durchführen lässt. Aus diesem Grund ist es auch nicht verwunderlich, dass agile Trainer und Coaches ihren Werkzeugkoffer immer häufiger durch Ideen aus anderen Disziplinen bereichern: psychologische Teambildungsmodelle oder das Satir-Change-Model sind hier nur zwei Beispiele.

Erfreulich ist darüber hinaus eine andere Entwicklung, die sich seit ca. zwei Jahren immer stärker zeigt: Agilität wird nicht mehr als etwas betrachtet, was nur die reine Entwicklung von Software angeht, sondern die gesamte Organisation – einschließlich Produkt- und Portfoliomanagement, Betrieb, Support und Administration. In diesem Punkt haben es sich agile Ansätze wie Scrum in den Anfangsjahren sicherlich etwas zu einfach gemacht mit der Aussage: „Der Product Owner stellt dem Cross-funktionalen Team regelmäßig kleine Anforderungshäppchen zur Verfügung, die es in kurzen Entwicklungszyklen umsetzt und dann gemeinsam mit ihm begutachtet.“ Fragen wie „Wo kommen denn gute Anforderungen her?“, „Wie schneidet man Anforderungen sinnvoll klein?“, „Was genau macht ein Cross-funktionales Team aus?“, „Was passiert mit dem Produktinkrement, nachdem es vom Product Owner abgenommen wurde?“ oder auch „Wie plane ich über Projektgrenzen hinweg?“ blieben dabei lange Zeit unterbelichtet. Glücklicherweise hat sich hier in den letzten Jahren viel getan. Zu vielen Fragen rund um agile Planung sowie Anforderungszuschnitt hat Mike Cohn hervorragende Arbeit geleistet [1], [2], auf viele Probleme rund um Product Ownership geht Roman Pichler ein [3], und für agiles Portfoliomanagement scheint Kanban ein hervorragendes Mittel zu sein [4].

Zum Abschluss seien noch kurz zwei aktuelle Entwicklungen erwähnt, die sich seit wenigen Monaten abzeichnen und die agilen Vorgehen bereichern/ergänzen: Lean und Kanban werden immer populärer. Dies liegt nicht nur an der Einfachheit der Konzepte, sondern auch daran, dass sie durch den Fokus auf kurze Durchlaufzeiten die gesamte Wertschöpfungskette betrachten. Darüber hinaus werden sie leichter vom Topmanagement akzeptiert, weil durch die lange, erfolgreiche Tradition der Lean-Konzepte in der Produktion die Ideen und Terminologie bereits bekannt und erprobt sind. Die zweite aktuelle Entwicklung, die sich (zu Recht) rasend schnell verbreitet, nennt sich DevOps – also eine Kombination aus „Developers“ und „Site-Ops“. Die Idee dahinter ist so einfach wie bestechend: Wenn wir wirklich flexibel sein wollen, dann müssen wir die traditionellen Gräben zwischen Entwicklern und Admins zuschütten. Denn Anforderungen sind nicht fertig umgesetzt, wenn sie zu ende programmiert und getestet sind, sondern letztlich erst dann, wenn sie auf der Liveplattform laufen („Done means deployed“). Nur wenn wir es schaffen, schnell, regelmäßig und stabil auszuliefern, werden wir die Vorteile von Agilität wirklich vollständig genießen können.

Arne Roock arbeitet bei it-agile in Hamburg. Als studierter Germanist interessiert er sich für informative, leicht verständliche und kooperative Kommunikation. Außerdem beschäftigt er sich seit Jahren mit den Themen Selbstorganisation und Zeitmanagement in der IT.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.