"Wir arbeiten agil, denn wir verwenden SCRUM." So oder so ähnlich tönt es aus Unternehmen und Konzernen, welche den Wind der Veränderung (oder doch eher den vermeintlichen Braten der Kostenersparnis?) geschnuppert haben. Ein Schelm, der da nachfragt, wie sich dieses "agil" da bemerkbar macht.
SCRUM ist nicht agil
Der Duden nennt als ein Synonym für Agilität das Wort "Wendigkeit". Die meisten Projekte, die ich kenne, haben allerdings eher die Wendigkeit eines 15 Tonnen Sattelzuges auf einem Feldweg. SCRUM oder Kanban macht eben noch kein agiles Projekt. Vielmehr handelt es sich bei SCRUM oder Kanban um Werkzeugkästen, die uns bewährte Praktiken für die Handhabung von Projekten in Form von Prozessen und Zeremonien zur Verfügung stellen. Das "
Manifest für Agile Softwareentwicklung" ist hier eigentlich sehr deutlich; dort steht geschrieben, dass Individuen und Interaktion über Prozessen und Werkzeugen stehen sollten.
Wie passt das zusammen?
Sind Agilität und die Werkzeugkästen eventuell als orthogonal oder gegenläufig zueinander zu betrachten?
Ich weiß nur eines: Ein für die nächsten fünf Jahre gefülltes Backlog hat mit Agilität nichts zu tun. Ein Projekt, bei dem im Voraus feststeht, was heraus kommen soll? Auch nicht agil. Regelmäßig, die vom Project Owner bis ins Detail spezifizierten User-Stories, auf Verständlichkeit prüfen und eine Schätzung dafür abgeben? Nicht agil. Jeder Softwareentwickler kann diese Liste endlos fortsetzen.
Was ist agil dann?
Nun, das ist einfach und gleichzeitig schwierig. Das liegt daran, dass die meisten Personen ihre ganz persönliche Definition von Agilität entwickelt haben. Verwenden wir deshalb, um dem Bullshit-Bingo mit der Agilität zu entkommen, das im Duden genannte Synonym "Wendigkeit".
Wendige Projekte?
Ein Projekt ist dann wendig, wenn es reagieren kann, z.B. auf sich ändernde Anforderungen. Das ist nur möglich wenn die Anforderungen kleine Happen sind, die schnell erledigt sind und die Entwickler nicht tage-, wochen- oder monatelang in eine Aufgabe binden.
Am besten bekommt man diese Anforderungen vom Endanwender selbst und in seiner primitivsten Art, z.B. den Wunsch etwas bis dato unmögliches erledigen zu können. Aber bitte nicht "Ich brauche hier einen Knopf. Wenn man darauf klickt, geht ein Dialog auf. Im Dialog sind zwei Eingabefelder mit den Labels..." Stattdessen lieber "Ich möchte (so einfach wie möglich und ohne 20 Knöpfe zu lesen, deren Bedeutung zu verstehen und Knopfologie studiert haben zu müssen) hier eine Notiz dran kleben". Um den Rest kümmern wir uns.
Aber niemand weiß, wie ich mir das vorstelle
Ja, das ist richtig. Wir können uns jetzt über ein Luftschloss unterhalten, oder etwas bauen und das als Grundlage verwenden. Falls das nicht passt, machen wir es das nächste mal besser. Das wiederholen wir so lange, bis es gut genug ist. Und weil das alles nur kleine Dinge sind, können wir ein gutes Duzend dieser Änderungen an einem Tag durchspielen. Es gilt: Diskutiere nicht Stunden drüber, mach es einfach. ABER: Mach es wirklich einfach, also mit möglichst wenig Aufwand. Wenn es nicht passt, mach es nochmal, ein kleines bisschen besser.
Kleine Inkremente, kleine Runden, große Wendigkeit - agil.
Und was ist mit SCRUM/Kanban?
Die Werkzeugkisten sind voller nützlicher Dinge. Projekte würden im Chaos versinken, wenn nicht hier und da Ordnung und Struktur rein gebracht wird. Man sollte nur permanent auf der Hut sein, dass das Regelwerk nicht die Arbeit selbst verdrängt. Letztlich sind alle Werkzeuge nur Hilfsmittel, die man verwenden, aber auch verändern und optimieren darf. Wenn das Meeting um 15 Uhr immer total ätzend/nicht produktiv/verschwendete Zeit ist, darf man das Meeting hinterfragen, anpassen oder einfach sein lassen.
Also bin ich nicht agil?
Vielleicht, aber ist das denn so schlimm? Selbstverständlich lässt sich SCRUM und Kanban für relativ starre Softwareprojekte verwenden. Da spricht sogar sehr viel dafür. Aber bitte, bitte, bitte - hört auf das als agile Softwareentwicklung zu bezeichnen oder zu verkaufen.
Kommentare
Kommentar veröffentlichen