Gedanken zur Weiterentwicklung des Agilen Manifests

Foto von Mike Cohn
Mike Cohn
4 Min. Lesezeit

Das „Agile Manifest” entstand vor über zehn Jahren. Seitdem hat es viele Veränderungen wie beispielsweise die kontinuierliche Verbesserung gegeben. Damals existierten die zum Manifest gehörenden Prozesse (Extreme Programming, Scrum, DSDM, Feature Driven Development etc.) nur in der Welt der Softwareentwicklung. Daher war es ziemlich einfach, sie als ungeeignet für das echte Leben abzutun.

Auch in meiner Abteilung stellten wir damals unsere Entscheidung, Scrum anzuwenden, infrage. Immerhin waren zu dieser Zeit fast alle vom „Unified Process” überzeugt. Wenn man noch nicht damit arbeitete, hatte man das Gefühl, dass es vielleicht besser wäre, es doch in Erwägung zu ziehen. Wir waren äußerst erfolgreich mit Scrum aber hatten trotzdem große Zweifel – wären wir vielleicht noch erfolgreicher, wenn wir eine vollständige Methode statt dieses kleinen Spielzeugs namens Scrum nutzen würden? Schließlich kannten wir sonst niemanden, der mit Scrum arbeitete und der Begriff „agile Softwareentwicklung” existierte noch nicht. In Zeiten, in denen sich die ganze Welt auf den Unified Process zu konzentrieren schien, kamen wir jedoch nicht umhin, uns zu fragen, ob wir die einzigen waren, die das nicht taten.

Eines Morgens bekam ich dann eine E-Mail von Ward Cunningham. „Schau mal, womit ich die letzten Tage verbracht habe”, schrieb er. Er hatte einen Link zu seiner neuen Internetseite, www.agilemanifesto.org, sowie ein Bild von einigen Leuten, die an einem Whiteboard standen, hinzugefügt. Das traf mich wie ein Schlag – wir waren doch nicht die einzigen. Plötzlich wusste ich, dass es mindestens noch 17 andere Leute gab, die so dachten wie wir. Und jeden Tag besuchten mehr Leute agilemanifesto.org und bekundeten ihre Solidariät.

Nun hatten wir einen Namen für das, was wir taten – „Agile” – und immer mehr Gleichgesinnte tauchten auf. „Ja, das machen wir auch!”, wurde der meistgesagte Satz all derer, die herausfanden, dass sie damit nicht alleine waren.

Und jetzt, über ein Jahrzehnt später, haben sich die Dinge um 180 Grad gedreht. Wenn man nicht mit agilen Methoden arbeitet oder zumindest darüber nachdenkt, hat man höchstwahrscheinlich das Gefühl, dass man es bald tun sollte. Der größte Unterschied ist wohl, dass agile Prozesse mittlerweile eine Berechtigung haben, bei jeder Diskussion zur Sprache zu kommen, bei der es darum geht, welcher Prozess genutzt werden soll. Wenn ich heute der Leiter der Entwicklungsabteilung eines großen Konzerns wäre und den Leitern anderer Abteilungen „Agile” vorschlagen würde, könnten sie es nicht mehr einfach abwinken. Agile ist in vielerlei Hinsicht eine sinnvolle und glaubwürdige Alternative. Auch wenn es nicht für jedes Unternehmen oder jedes Projekt sinnvoll ist, wird man nicht mehr dafür ausgelacht, es vorgeschlagen zu haben.

Vom ausgelacht werden zur glaubwürdigen Alternative in circa zehn Jahren – wie geht es mit Agile weiter?

Hoffentlich kommen als nächstes zwei Dinge auf uns zu:

Als Erstes fände ich es gut, wenn all die „Marken” verschwinden würden. Kein Scrum. Kein XP. Kein Kanban oder Lean. Kein DSDM. Kein Crystal. Einfach nur Agile. Das ist vor etwa zwei Jahrzehnten bereits bei der objektorientierten Softwareentwicklung geschehen. Dort gab es verschiedenste Modelle und Methoden von Rumbaugh, Booch, Meyer, Jacobson und anderen. Die Unterschiede verschwanden irgendwann und nun gibt es lediglich objektorientierte Programmierung und UML (Unified Modeling Language, dt. vereinheitlichte Modellierungssprache).

Die zweite Veränderung, die ich in den nächsten zehn Jahren gerne sehen würde (und die mit Sicherheit auch kommen wird), ist ebenfalls bereits bei der objektorientierten Softwareentwicklung aufgetreten: Wir hören auf, über Agile zu reden. Vor einiger Zeit haben wir schon aufgehört, über die Objektorientierung (OO) zu sprechen – sie hat den Kampf gewonnen. Niemand diskutiert mehr über OO. Natürlich gibt es einige Anwendungen, wie solche mit harten Leistungsanforderungen, bei denen die objektorientierte Entwicklung keine Rolle spielt. Es gibt auch Projekte, die nicht in OO-Sprachen geschrieben werden. Dennoch glaube ich, dass der Code auch in diesen Fällen durch Objektorientierung beeinflusst wurde.

Ich hoffe, dass auch Agile an diesen Punkt kommen wird, an dem man nicht mehr darüber sprechen muss. Keine „agile Softwareentwicklung” sondern „Softwareentwicklung”. „Projektmanagement” statt „agiles Projektmanagement”. Natürlich ist das alles agil. Niemand fragt mich mehr, ob der Ruby Code, den ich schreibe, objektorientiert ist. Natürlich ist er das. Ich hoffe, dass eines Tages niemand mehr fragen muss, ob man agile Methoden für ein Projekt genutzt hat. Natürlich hat man das.

Wenn ich in zehn Jahren erneut darüber nachdenke, was sich seit der Entstehung des Agilen Manifests verändert hat, hoffe ich, sagen zu können, dass es zu einem in Vergessenheit geratenen Dokument geworden ist – wie die Magna Carta. Das verstaubte, alte Ding hat immer noch Einfluss auf mein Leben und vor Kurzem wurde ich daran erinnert, als ich als Geschworener geladen wurde. Darüber nachgedacht habe ich allerdings nicht wirklich. Ich hoffe, dass es bei dem Agilen Manifest ähnlich ablaufen wird und dass wir in zehn Jahren nicht mehr von „agiler” Softwareentwicklung sprechen. Hoffentlich sprechen wir überhaupt nicht mehr davon und machen es stattdessen einfach.

Mehr zu diesem Thema

Agiles Manifest

Erfahren Sie alles über das Agile Manifest, seine Grundlagen und Bedeutung für agile Methoden und Praktiken. Von der Agile Academy. Jetzt lesen!

Continuous Integration (CI)

Continuous Integration bzw. kontinuierliche Integration bedeutet, dass geschriebener Code umgehend in die bestehende Codeabsis deployed wird.

Pair Programming

Pair Programming wird in der agilen Softwareentwicklung eingesetzt um die Kommunikation zu fördern und Entscheidungswege zu beschleunigen. Mehr im Lexikon.