In meiner Kritik an Martin Fowlers Absage an die Wissenschaftlichkeit habe ich anklingen lassen, dass ich selbst eine Definition für Agilität hätte. Darauf bin ich nun ein paar Mal angesprochen worden. Nun muss ich wohl Butter bei die Fische machen und sie einmal beschreiben.
Meine Definition
Also gut… Hier sind meine persönlichen Kriterien für agiles Vorgehen oder eine Haltung der Agilität. Sie sind natürlich nicht rigoros im mathematischen Sinne. Das habe ich auch nicht von Martin Fowler erwartet. Aber ich halte sie für klar genug, um mit ihnen in der Hand an ein Projekt herantreten zu können für eine Prüfung, ob es agil durchgeführt wird.
Inkrementell
Die wesentliche Neuerung, die die Agilität in die Softwareentwicklung aus meiner Sicht gebracht hat, ist das Denken in und die Entwicklung von Durchstichen. Software wird nur in nützlichen Inkrementen ausgeliefert. Agilität liefert “Anforderungsscheiben”, d.h. sie macht vertikale Schnitte durch ein Softwaresystem. Als fertig und somit projektfortschrittsrelevant wird angesehen, was dem Kunden etwas wert ist.
Was war vorher? Vorher war die Entwicklung in Meilensteinen. Zum Begriff Meilenstein gehört aber nicht notwendig der Durchstich. Ein Meilenstein kann auch sein “Datenbankschicht fertig” oder “ESB aufgesetzt”. Solche Infrastrukturbelange mögen irgendwie wichtig sein, ohne Datenbankzugriff oder ESB läuft das Softwaresystem nicht. Allerdings interessieren die den Kunden nicht direkt; sie sind nicht nützlich. Er will seine Aufträge bearbeiten, Planungen durchführen, Ressourcen verwalten usw.
Eine Datenbank oder ein ESB sind einfach keine funktionale und auch keine nicht-funktionale Anforderung. Sie sind Mittel zur Realisierung von Anforderungen. Deshalb sind die für sich genommen nicht wertvoll.
Aus meiner Sicht ist es genau diese Unterscheidung, die Agilität vor allem auszeichnet. Den Blick auf die Erfüllung von Anforderungen zu konzentrieren und sich nicht von Mitteln ablenken zu lassen, das macht Agilität für mich aus.
Lernend
Die zweite Neuerung, die Agilität in die Softwareentwicklung gebracht hat, war aus meiner Sicht die Haltung des ewigen Schülers. Wer agil arbeitet, bewegt sich in einer Lernschleife:
- Herausfinden, was gewünscht ist
- Inkrement herstellen
- Überprüfen, ob das Inkrement für den Kunden akzeptabel ist
In der agilen Softwareentwicklung gibt es also keine Phase, die je abgeschlossen wäre.
Agilität läugnet insofern nicht, dass Softwareentwicklung in sequenziellen Phasen abläuft. Man muss zuerst herausfinden, was gefordert ist, dann muss man die Realisierung planen, dann kann man den Plan implementieren [1] und erst danach kann man die Implementierung überprüfen und schließlich abnehmen lassen.
Aus Sicht der Agilität ist nichts gegen solche Phasen zu sagen. Sie sind sozusagen unterhalb des Radars der Agilität. Deshalb kann man aus meiner Sicht auch nicht mit der Agilität begründen, dass man nicht dokumentiert oder entwirft. Agilität wendet sich nicht dagegen. Es ist ihr schlicht egal. Sie sagt: Mach, was nötig ist, um Inkremente heute und in Zukunft zügig herstellen zu können. Denn nur so kann ihr Anspruch des Lernens erfüllt werden.
Zunächst hatte ich gedacht, dass ein wichtiger Baustein der Agilität Iterationen seien. Inzwischen sind für mich Iterationen allerdings nur noch ein Mittel. Und der wirkliche Baustein der Agilität ist das Lernen. [2] Ebenso sind z.B. Scrum Retrospektiven auch nur ein Mittel, um den Baustein Lernen in ein Projekt zu setzen.
Das bedeutet im Umkehrschluss: Agilität ist dort unnötig, wo nicht gelernt werden muss. Wenn glasklar ist, was zu tun ist, wenn es nur marginale Unwägbarkeiten gibt… dann muss man nicht agil sein.
Agilität ist also kein Ansatz für die Produktion, sondern für jede Form von Entwicklungstätigkeit, sei das “bei den Kreativen” oder bei Ingenieuren.
Unmittelbar
Die dritte Neuerung der Agilität ist dann die Betonung der unmittelbaren Kommunikation. Die, die ein Ergebnis sehen wollen und die, die es herstellen sollen, sitzen im selben Boot. Also ist es wichig im Sinne der Lernschleife und zügiger Inkremente, dass diese Beteiligten möglichst barrierefrei Kontakt haben.
Wie das konkret geschieht, ist der Agilität wieder egal. Aber typische Maßnahmen im Sinne der Unmittelbarheit sind cross-functional Teams und co-location. Auch das Verhältnis ProductOwner zu Entwicklern in Scrum ist dafür Ausdruck.
Informationen sollen fließen, Entscheidungen sollen zügig getroffen werden. Bürokratie jeder Art (Hierarchien, Verträge, Dokumente, Konventionen, …) gehört für die Agilität deshalb auf den Prüfstand. Was nicht unmittelbar dem Ziel “Nützliches Produkt” dient, soll weggeschnitten werden.
Meine Hypothese
Agilität zu definieren ist kein Selbstzweck. Eine Definition macht nur Sinn, wenn daraus etwas abgeleitet wird. Eine Hypothese kommt erst zustande, wenn der Definition auch eine Ergebniserwartung zugeordnet wird.
Aus meiner Sicht lautet die Vorhersage der Agilität:
Wer agil Software entwickelt, der hat größere Chancen, bei gegebenen Budgets (Geld, Zeit, Ressourcen) hohen Nutzen für den Kunden herzustellen.
Oder etwas konkreter: Mit Agilität werden weniger Projekte abgebrochen und die Überziehungen werden geringer und das Supportaufkommen fällt auch nicht so hoch aus.
Natürlich ist diese Vorhersage im Komparativ formuliert. Agilität ist ja als Gegenentwurf zu etwas Bestehendem entstanden. Demgegenüber will sie bessere Ergebnisse liefern. Aber sie ist zumindest so “bescheiden”, sich nicht als das Ende der Fahnenstange zu sehen. Zumindest sollte sie das sein, denke ich. [3]
Zusammenfassung
Das war´s. Mehr gehört für mich derzeit nicht zur Definition von Agilität. Bestimmt ist es weniger, als viele von Ihnen erwartet hätten. Mir reicht es aber. Denn mit diesen Kriterien an der Hand kann ich jedes Projekt, jedes Unternehmen beurteilen. Und Sie können das auch. Dafür muss ich Sie nicht “weihen” ;-)
Gehen Sie einfach diese Checkliste durch:
- Geht es um ein Entwicklungsvorhaben? Stichwort: Kreativität
- Wird das Ergebnis inkrementell hergestellt? Stichwort: Durchstiche
- Wird bewusst lernend vorgegangen? Stichwort: Reflexion
- Sind die Vorhabenbeteiligten in unmittelbarem Kontakt? Stichwort: Kommunikationsfluss
Wenn jede Frage mit eine Ja beantwortet werden kann, dann liegt grundsätzlich Agilität vor.
So einfach ist das :-) Dazu müssen Sie - aus meiner Sicht - nicht Martin Fowler anrufen und fragen, ob er Agilität erkennt.
Sie können jetzt selbst beurteilen, ob Agilität etwas bringt. Wenn ein Vorhaben inkrementell, lernend und unmittelbar durchgeführt wird, aber sich kein Erfolgsmesswert verbessert… dann nützt ihm Agilität nichts. Dann kann man auch wieder wie früher arbeiten, falls das irgendwelche Vorteile haben sollte. [4]
Und Sie können überlegen, ob gewisse Methoden agil sind oder inwiefern sie der Agilität dienen. Fragen Sie, wie sie das Lernen oder die Unmittelbarheit oder die Lieferung von Inkrementen unterstützen.
Wenn Sie mögen, übernehmen Sie meine Definition von Agilität. Und wenn nicht, dann lassen Sie uns drüber reden, was fehlt. Ich behaupte nicht mal, dass sie gut sei jenseits dessen, dass ich sie für mich praktisch finde. [5] Ich sage nur, dass es überhaupt eine Definition ist und damit das Minimum, was wir von einem Ansatz zur Softwareentwicklung erwarten können.
Fußnoten
[1] Wie umfangreich ein solcher Plan ist, sei dahingestellt. Er mag für Triviales quasi nicht existent sein, so dass die Codierung gleich starten kann. Für anderes mag dann aber durchaus etwas Nachdenken/Entwurf angezeigt. Die Agilität sagt nicht, wieviel Planung nötig ist. Das ist nicht ihr Thema. Sie beschränkt sich auf die Anerkennung von Phasen in der Herstellung von Inkrementen. Wieviele und welche Phasen das sind… ist eine Sache des Herstellungsprozesses. Der sieht für Software anders aus als für ein Auto.
[2] Zu meiner Liste von Agilitätskriterien gehörte zunächst auch noch “Haldenreduziert”. Damit wollte ich dem Aversion gegen “B*UF” (Big {Design, Documentation, …} Up Front) Ausdruck geben. Inzwischen sehe ich es aber so, dass auch das nur eine Folge der Lernwilligkeit ist. Große Halden an Anforderungen, Entwürfen usw. erzeugen einfach Trägheit, die das Lernen behindern. Sie reduzieren die Lernschleifenfrequenz.
[3] Vielleicht ist das unnötig zu erwähnen. Denn wenn Lernen ein Bestandteil der Agilität ist und sie sich so minimal definieren sollte, wie ich das hier zunächst mal nur für mich persönlich tue, dann gibt es erstens daran keinen Zweifel und zweitens steht nicht zu erwarten, dass Agilität dann abgelöst würde. Sie wäre vielmehr der Kern von Weiterentwicklungen.
[4] Selbstverständlich gibt es noch eine andere Möglichkeit: Es könnte sein, dass das mit dem inkrementellen, lernenden und unmittelbaren Arbeiten noch nicht optimal ist. Man kann ja besser oder schlechter inkrementell vorgehen usw. Kritik an der Implementation von Agilität darf also sein. Da gibt es Interpretationsspielraum. Und damit gibt es Raum für die Entwicklung der Agilität. Es können sich ja über die Zeit Best Practices herauskristalisieren, die dann in die Definition von Agilität einfließen.
[5] Allerdings impliziere ich, dass meine Definition in Linie steht mit dem agilen Manifest und beliebten Methoden der Agilisten. Das ist für mich ein Hinweis auf eine gewisse Grundqualität.
