Follow my new blog

Mittwoch, 1. August 2012

Agil persönlich definiert

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

image

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

imageDie 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:

  1. Herausfinden, was gewünscht ist
  2. Inkrement herstellen
  3. Ü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:

  1. Geht es um ein Entwicklungsvorhaben? Stichwort: Kreativität
  2. Wird das Ergebnis inkrementell hergestellt? Stichwort: Durchstiche
  3. Wird bewusst lernend vorgegangen? Stichwort: Reflexion
  4. 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.

3 Kommentare:

Frank hat gesagt…

Da sieht man es wieder: Provokatives ("Pseudowissenschaft Agilität") reizt mehr zum Kommentieren als Konstruktives ("Agil persönlich definiert"). In dem vorigen Blog-Artikel gab es den ersten Kommentar nach gut einer Stunde. Nach 1,5 Stunden waren es schon 4. Und nach gut 24 Stunden waren satte 14 Kommentare zusammengekommen. Und hier? In fast 24 Stunden bisher kein einziger!

Leider kenne ich mich mit der Agilität nicht so gut aus, dass ich irgendetwas substantielles beitragen kann, aber ich bitte all diejenigen, die das können, das auch zu tun. Ich muss Ralf recht geben: Eine - allgemein anerkannte - Definition der Agilität wäre wünschenswert und wohl auch möglich. Daher haut in die Tasten, damit die bisher rein persönlichen Definition anhand eures Feedbacks weiterentwickelt werden kann.

Thomas hat gesagt…

Ich habe über dieselbe Frage im Rahmen meiner Arbeit als Scrum Master ebenfalls nachgedacht. Vor einigen Wochen durfte ich anlässlich meiner CSM-Zertifizierung einige Gedanken zu dem Thema mit Jeff Sutherland austauschen. Ich habe anschliessend die wichtigsten "Grundpfeiler" der Agilität für mich so definiert:

1) Inkrementelles Produktwachstum
2) Stetiges Feedback in verschiedenen Zeiträumen
3) Stetiges Lernen in verschiedenen Bereichen
4) Direkte Kommunikation
5) Vermeidung von unnötigem Overhead

Das spiegelt (teilweise) sich auch in den vom Scrum Guide erwähnten Grundprinzipien wieder: Transparency, Inspection and Adaption.

Auf jeden fall vielen Dank für den Blog-Artikel. Hat mir gut gefallen. :)

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: "Transparency, Inspection, Adaption" ist mir zu wenig. I und A gehören für mich zusammen. Und T ist ziemlich unspezifisch.

Da sehe ich auch nicht so grundsätzlich die Neuerung, die die Agilität auf die Straße bringen wollte.

Und das, was Jeff Sutherland da sagt... Bei 1-4 bin ich dabei. 5 halte ich reingeschmuggelt. "Overhead" ist aus meiner Sicht kein originär agiles Thema.

Klar, man möchte schnell lernen, deshalb kein B*UF. Das ist Overhead-Vermeidung. Doch so wie du 5 formuliert hast, hört sich "Overhead" wie "Waste" an. Und "Waste" gehört zu Lean und nicht zu Agile.

Ich denke, insofern sollte die Agilitätsbewegung auch konsequent sein und sich nicht selbst verwässern. Nach Agil kommt eben noch was, z.B. Lean, das weitere nützliche Aspekte einbringt. Die Agilisten müssen nicht alles schon erfunden haben.