Better Definitions of Agility in Software Engineering, Agile Software Development, Agile Project Management
Agility, SCRUM, and more – Was ist das wirklich?
Wer Google nach dem Stichwort agile+scrum suchen läßt, bekommt mehr als 7 Millionen Treffer gemeldet.Niemals noch ist in der Geschichte des Software Engineerings über ein Konzept so relativ einfacher Natur mehr — und doch fast nur Triviales (!) — geschrieben worden.
Dass ein ganzer Berufsstand sich nun schon weit über ein Jahrzehnt damit aufhält und inhaltlich dennoch kaum vorankommt, scheint mir mehr als merkwürdig. Ursächlich ist wohl, dass der Begriff Agile nicht durch Methodiker definiert wurde sondern durch Personen, die nicht in der Lage waren, das WAS vom WIE zu trennen.
Und in der Tat: Im Agile Manifesto beschreiben seine Autoren umfangreich, WIE man vorgehen sollte. Ihrem Ziel aber — dem WAS — widmen ihre 5 Aussagen und 12 Prinzipien nur einen einzigen Satz:
through early and continuous delivery of valuable software.
Das Manifesto ignoriert die Tatsache, dass Auftragnehmer selten frei sind, nur die Interessen ihrer Auftraggeber zu berücksichtigen: Stets gegebene Zielkonflikte bleiben unberücksichtigt.
Genauer: Nirgendwo berücksichtigen die Unterzeichner des Manifestos, dass ihre Methodik nur dann gut funktioniert, wenn
- die Entwickler als Dienstleister arbeiten (also nicht zum Festpreis) und
- die Software über ihren ganzen Lebenszyklus hinweg i.W. durch die Entwickler selbst gepflegt werden kann.
Kein Methodiker hat diese schlampige Argumentation bisher angeprangert, und wenige nur haben sich mit dem Manifesto öffentlich kritisch auseinandergesetzt (am ehesten noch Robert Glass in 2001 und später dann auch Tom und Kai Gilb).
Am konkretesten hat Gartner mit einem guten Argument (leider erst 2011) indirekt darauf hingewiesen, wie einseitig hier weit über ein Jahrzehnt lang gedacht wurde.
Man sollte einsehen, dass die Idee agiler Vorgehensweise professioneller diskutiert werden kann, wenn sie zunächst nur von ihrem Ziel her definiert wird, nicht aber schon als ein ganz bestimmter konkreter Weg hin zu diesem Ziel (es könnte ja über noch bessere Wege erreichbar sein):
Software Developer's Definition of Agile
Agility means to have a process in place that will allow us (and urge us)
to react on changing business requirements as soon as possible
— accept that the goal is a moving target —
Die Agile Principles 2011 versuchen das konkreter zu sagen, gehen aber auch nicht darauf ein, welche wirkliche Hürde hier zu nehmen ist:
Das wirkliche Problem — und darauf wagt kaum jemand schriftlich hinzuweisen — besteht heute nämlich darin, dass Auftraggeber in aller Regel ein Festpreisangebot erwarten. Wie aber soll man das abgeben und einhalten können, wenn man einerseits verprechen soll, agil zu entwickeln, andererseits aber nicht weiß, welche Präzisierung und welche Abänderung der Requirements — der Projektaufgabe also — sich noch vor Projektende ergeben werden?
Solange Methodiker diesen Zielkonflikt nicht klar und deutlich adressieren, wird Agile nur leeres Gerede sein und bleiben: für die Wissenden ein Lippenbekenntnis, für alle anderen aber die willkommene Ausrede, ingenieurmäßiges Vorgehen vernachlässigen zu können.
Mit zur Verwirrung trägt auch bei, dass der Begriff Agile heute immer auch dort verwendet wird, wo es darum geht, flexiblere, modernen Anforderungen besser angepasste Prozesse fürs Projektmanagement zu finden. Übersehen wird, dass Agile in diesem Zusammenhag aber ganz anders zu definieren ist:
Project Manager's Definition of Agile
Agile Project Management means to have a process in place
that is to maximize team efficiency
Dass das etwas ganz anderes ist als agiles Reagieren auf neu erkannte fachliche Anforderungen, zeigt sehr schön ein Experiment, welches im Auftrag von NTT Data durchgeführt wurde: Drei Teams haben dabei — auf jeweils verschiedene Weise — auf ein und dasselbe Ziel hin gearbeitet.
WICHTIG also: Wer über agile Software Entwicklung (als Spezialfall agilen Software Engineerings) diskutiert, der versteht unter Agile etwas ganz anderes als der, welcher z.B. über SCRUM (als modernen Weg für erfolgreiches Projektmanagement) spricht.
Noch komplizierter wird es bei Feature Driven Development (FDD): Hier hat man gleichzeitig über beide Begriffe zu sprechen — ist sich dessen aber nur selten bewusst. Kein Wunder also, dass die gesamte Diskussion um Agile so fruchtlos bleibt obgleich doch fast täglich neu (in Blogs etwa) darüber geschrieben wird.
Richtig liegt auf jeden Fall, wer als Kern und Kurzfassung agiler Methodik die beiden folgenden — sehr sinnvollen — Aufforderungen sieht:
Use simple, iterative processes with emphasis on creativity and collaboration.
Was andere denken
Welches (relative) Gewicht Praktiker den 12 Prinzipien der Agilisten zuweisen, zeigt eine entsprechende Umfrage. Ihr Ergebnis einzusehen muss man dort dem Link "View Results" folgen oder — besser noch — selbst ein Votum abgeben.
Interessant ist, dass es einen Versuch gibt, die agile Idee auch im Automotive-Bereich anzwenden (beim Produzieren von Autos also, statt nur zum Produzieren von Software). Anders als die Autoren des Agile Manifesto hat das Team, welches die Idee in den Automotive Bereich tragen möchte, aber sehr wohl verstanden, dass Agilität im Sinne des Manifestos nur zu brauchbaren prototypischen Lösungen führen kann — aber eben NICHT auch zum Endprodukt, das man auf den Markt trägt. Die Leute nennen ihr Projekt WikiSPEED, und WikiSPEED's Definition of Done sagt:
We test for safety, efficiency, durability, usability, value created, simplicity, environmental impact, and regulatory compliance. Our minimum definition of done for our cars is "Road Legal and Safe".
So gesehen, und auch weil diese Aussage ein absolut präzise definiertes Ziel setzt, macht WikiSPEED's Manifest schon weit mehr Sinn als das Agile Manifesto der Software-Entwickler (die ja in Wirklichkeit, das entschuldigt sie vielleicht, einfach nur Wartungsprogrammierer waren).
stw4394ASCRUMM — Agile . SCRUM . Manifesto — News?
Mehr + B G E + S H A + More
Best Practice Agile
Perfect Agile