Ein Blick in die Zukunft und auf das bereits Erreichte

Wie sieht Agilität in 20 Jahren aus?

Arne Roock

Wie wir alle wissen, besitzt die CIA nicht nur die Technologie, um die Gedanken von Menschen zu manipulieren, sondern auch Geräte, mit denen man für kurze Zeit in die Zukunft blicken kann. Wenn wir uns so einen Apparat einmal ausleihen dürften, um einen Blick auf den Stand der Softwareentwicklung im Jahre 2031 zu wagen, dann würden wir wahrscheinlich Folgendes sehen.

Der Begriff „agile Softwareentwicklung“ ist aus dem Sprachgebrauch in der IT verschwunden. Nur noch einige alte Hasen können mit Wörtern wie „Scrum“ oder „eXtreme Programming“ etwas anfangen. Und von dem Agile Manifest hat kaum jemand je etwas gehört. Auf der anderen Seite hat sich der Ruf der IT deutlich verbessert. Dass Software in hoher Qualität pünktlich und regelmäßig an den Kunden ausgeliefert wird, ist nun die Regel und nicht mehr die Ausnahme.

Wie ist es dazu gekommen? Sind agile Methoden gescheitert? Ganz im Gegenteil! Die Werte und Prinzipien, die Agilität ausmachen, werden sich durchsetzen. Nur die Namen der einzelnen Methoden und Praktiken werden sich vermutlich ändern. Scrum wird vielleicht abgelöst werden von etwas, das „Borgli“ heißt oder „Lobster“ oder „Nabnak“. Der Begriff „agile Softwareentwicklung“ wird vermutlich so sehr zum Modewort werden, dass ihn niemand mehr verwenden mag. Und natürlich wird es dann eine Reihe von Leuten geben, die verkünden: „Ich hab immer gesagt, dass dieser agile Kram sich nicht durchsetzt.“ Auf der einen Seite haben sie auch Recht damit, denn es wäre vermessen, heute zu behaupten, Scrum (oder irgendein anderes Vorgehen) werde in 20 Jahren der aktuelle Stand der Kunst sein. Auf der anderen Seite greift diese Sichtweise zu kurz, denn die grundlegenden Werte und Prinzipien hinter Agilität haben längst ihren Siegenszug angetreten.

Unternehmen wie Amazon, Google oder flickr sind nicht nur deshalb so erfolgreich, weil hinter ihnen eine sensationell innovative Idee steht (was genau betrachtet bei keinem der drei Beispiele der Fall ist), sondern weil sie konsequent daran arbeiten zu verstehen, was wirklich Wert für ihren Kunden darstellt, diesen Wert kontinuierlich auszuliefern und sich immer wieder Feedback darüber einzuholen, in welche Richtung sie sich weiterentwickeln müssen. Ausschlaggebend sind hier also Punkte wie der enge Kontakt zum Kunden, kurze Feedbackzyklen, eine Kultur der kontinuierlichen Verbesserung (Kaizen) und kontinuierliche Auslieferung.

Nennt Amazon sich agil? Geht Google nach Scrum vor? Praktiziert flickr eXtreme Programming? Keine Ahnung, und es spielt auch letztlich keine Rolle. Denn das, worauf es wirklich ankommt, ist der Erfolg – unabhängig davon, welche Namen und Schlagworte man damit verknüpft. Aber die genannten Grundideen sind so fundamental wichtig, dass es in Zukunft immer schwieriger für Unternehmen sein wird, diese Ideen zu ignorieren. Die Frage wird immer weniger lauten, welche Organisationen agil sein wollen und welche nicht, sondern welche Organisationen es sich noch erlauben können, nicht agil vorzugehen – und wie lange noch!

Also ist doch alles ganz einfach: Wir wissen, was die Bausteine für erfolgreiche Softwareentwicklung sind, und wir kennen Unternehmen, die es uns eindrucksvoll vormachen. Also müssen wir uns doch einfach nur ein bisschen mehr anstrengen, um auch so erfolgreich zu werden. Oder etwa doch nicht? Leider gilt es hier, noch eine große Herausforderung zu meistern. Denn so allgemeingültig die Werte und Prinzipien hinter Agilität auch sein mögen, so abstrakt sind sie auf der anderen Seite. Wir wissen zwar, dass enge Zusammenarbeit mit dem Kunden wichtig ist, aber wir wissen nicht für jeden Kontext, wie wir diese Zusammenarbeit im konkreten Fall am besten institutionalisieren können.

Für einige Kontexte, Domänen, Geschäfts- und Vertragsmodelle mag es hierfür bereits Best Practices geben, aber in anderen Bereichen betreten wir immer noch Neuland. Dass es zwei verschiedene Paar Schuhe sind, ob wir Scrum in einem Startup mit 10 Entwicklern einführen, das einen Web Service für Endanwender anbietet, oder in einem Großkonzern mit 10 000 Entwicklern, dessen „Kunden“ im Wesentlichen andere interne Abteilungen sind, sollte jedem einleuchten. Das Wissen um die richtigen Prinzipien entbindet uns also leider nicht von der Anstrengung, nach spezifischen Lösungen für den eigenen Kontext zu suchen. Wer hingegen einfach nur funktionierende Lösungen aus anderen Kontexten kopiert, wird sehr wahrscheinlich damit scheitern.

Geschrieben von
Arne Roock
Kommentare

Schreibe einen Kommentar

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