Was genau ist eigentlich Agile?
Wiki sagt, dass agil semantisch gesehen seinen Ursprung im lateinischen agilis hat und “flink, beweglich” bedeutet. Ist “agile Softwareentwicklung” schneller (flinker) oder beweglicher als herkömmliche Programmierung? Wohl kaum.
Ich persönlich bevorzuge “flexibel” als Synonym für agil und bin der Meinung, dass nicht die Softwareentwicklung selbst, sondern die Projektumsetzung agil – also flexibel – ist / sein soll.
Meiner Ansicht nach liegt die Agilität / Flexibilität in dem Aspekt, dass der Kunde (der Requester) nicht mehr das ganze Vorhaben in voller Detailtiefe beschreiben muss (= Lastenheft), sondern viel Freiheit – also Flexibilität – in der Ausgestaltung des Weges zum Ziel hat.
Beschreiben lässt sich das ganz gut mit der Analogie einer Reise. Der Kunde weiß, dass er innerhalb Deutschland ans Meer reisen möchte. Er möchte Matjes essen und Meerluft schnuppern. Soviel ist gewiß. Ob es die Nordsee oder die Ostsee werden soll, weiß er noch nicht. Das ist zum jetzigen Zeitpunkt auch noch gar nicht wichtig.
Analog zur Umsetzung einer Kundenanforderung: Der Kunde weiß in etwa, was er mit seiner Anforderung erreichen möchte. Damit ist – wenn auch noch nicht die genaue Zielkoordinate – zumindest die grobe Richtung bekannt.
Der Kunde, ein alter, in München wohnhafter Bayer in Lederhosen, weiß, dass er auf seiner Reise ans Meer (ganz gleich ob Nord- oder Ostsee) als erstes Nürnberg, als nächstes Frankfurt und dann auch auch mal Kassel im Rücken haben muss. Ob er nur den schnellen Weg über die Autobahnen der Republik oder auch Landstraßen nutzen möchte, weiß er bis dato noch nicht.
Analog zur Umsetzung einer Kundenanforderung: Der Kunde kennt bereits seine ersten Milestones (= Objectives).
Ob er dabei jeweils durch die Städte und damit mitten durchs Verkehrsgewühl fährt oder Umgehungsstraßen weitab der Städte nutzen wird, weiß er derzeit noch nicht. Das ist zum jetzigen Zeitpunkt auch noch gar nicht wichtig.
Nachdem die ersten Zwischenziele (Milestones / Objectives im Projektgeschehen) bekannt sind, kann sich der (Scrum) Product Owner zusammen mit seinem Team schon einmal Gedanken über die Wegstrecke zum ersten Milestone / Objective machen. Das Zwischenziel – der Milestone – wird in User Stories zerlegt. Sie sind die kleinsten Einheiten einer fachlichen Beschreibung dessen, was umgesetzt werden soll. Diese entsprechen zum gegenwärtigen Zeitpunkt den Weg vom Startpunkt hin zum ersten Zwischenziel. Sie müssen über einen Detaillierungsgrad verfügen, bei dem der Developer weiß, was der Product Owner – als Stellvertreter für den Kunden – umgesetzt haben möchte. Damit kann sich der Softwareentwickler … äh, der Fahrer, auf den Weg machen.
Während die erste Wegstrecke – bis Ingolstadt – im ersten Sprint des Geschehens umgesetzt wird und das Team parallel dazu schon die Wegstrecke – als die User Stories – für den nächsten Sprint “refined”, fällt dem Kunden ein, dass er doch gerne einen Abstecher ins schöne Altmühltal machen würde. Ein kleiner Umweg auf seiner Reise ans Meer. Dieser kleine Umweg entspricht im Projektgeschehen einer kleinen User Story, die mal eben erstellt und “refined” wird. Der Product Owner platziert sie alsdann ganz oben im Product Backlog. Sie – die User Story – wird im nächsten Sprint Planning berücksichtigt werden. Das ist Flexibilität und schimpft sich auch Agilität.
Während die Wegstrecke zum ersten Zwischenziel – zum ersten Milestone – Nürnberg schon recht gut bekannt ist, konkretisiert der Product Owner zusammen mit dem Kunden den weiteren Weg, der sie Richtung Frankfurt führen wird. Mehr und mehr konkretisiert sich die genaue Ausgestaltung der Wegstrecke und immer mehr lassen sich konkrete User Stories aus dem Zwischenziel ableiten. Der Kunde hat noch bis Kasel Zeit sich zu entscheiden, ob er nun an die Nordsee oder an die Ostsee reisen möchte. Er muss sich zum gegenwärtigen Zeitpunkt – wir nähern uns gerade Frankfurt – gar nicht entscheiden. Immer mal wieder erfolgt ein Rollout der umgesetzten Funktionalität und der Kunde kann diese kleinen Ergebnisse der Arbeit des Teams relativ zeitnah zum Einsatz bringen. Ist schon toll, wenn man den Weg genießen und die Freude nicht erst nach langer Reise am Ziel ankommt. Das ist einer der Vorteile von Agilität.
Ein gutes Stück vor Kassel ist die Entscheidung dann getroffen. Cuxhaven soll es werden. Dort möchte der Kunde Matjes essen und Meerluft schnuppern.
Das agile Prozedere
Zuerst gilt es das ungefähre Ziel eines Vorhabens auszumachen. Die genaue Zielkoordinate muss noch gar nicht bekannt sein. Es reicht die Zielrichtung. Anschließend steckt man die Zwischenziele – auch als Milestones oder Objectives bekannt – ab. Auch hier müssen noch gar nicht alle Zwischenziele bekannt sein. Es wäre aber nicht schlecht, wenn schon einmal die ersten beiden Milestones benannt werden könnten. Der Product Owner und sein Team zerlegen nun den Milestone / das Objective in User Stories. Diese konkretisieren das Zwischenziel. Die User Stories sollten nun über ein Refinement bis zu einem in einer DoR (Definition of Done) beschriebenen Reifegrad gebracht werden.
Conclusio
Es ist die Art und Weise der Projektumsetzung, die agil ist / sein kann / sein sollte, keinesfalls aber ist die Softwareentwicklung selbst agil. Auch wenn viele Wege nach Rom führen und die Umsetzung einer Kundenanforderung auf verschiedenen programmiertechnischen Wegen erreicht werden kann, spricht man hier nicht von agiler Softwareentwicklung.
Ist das Verständnis über Agilität in Ihrem Projekt / Unternehmen nur unzureichend ausgeprägt? Wir unterstützen bei der Entwicklung des richtigen Mindsets dafür.
2 Kommentare. Hinterlasse eine Antwort
Ist es Ihre persönliche Erfahrung, dass Sofrwareentwicklung nicht agile sein kann, oder die Behaptung der Verfasser von Agile Manifest, indem das Mindset und die Semantik der Agilität bzw. Agile Softwareentwicklung definiert ist?
Ja, das ist meine eigene Erfahrung. Ich habe auch Software entwickelt und bin seit fast 20 Jahren nahezu ausschließlich in SWE-Projekten tätig. Es gibt (in der IT) heute kaum noch etwas, was nicht mit dem Präfix „agil“ versehen wird. Viele Kollegen sind sich heute darüber einig, dass für das Wort „agil“ das Wort „flexibel“ wohl das passendste Synonym ist. Wenn die Softwareentwicklung sich als agil bezeichnen darf, dann stellt sich mir schon die Frage, ob das nicht jedes andere Gewerk auch tun darf.