Der Bezeichnung „agil“ entkommt man im modernen Geschäftsleben praktisch nicht mehr. Sie ist zu einem Schlüsselwort geworden, welches einerseits Modernität signalisiert, andererseits aber auch von der unterschwelligen Botschaft von Schnelligkeit und Flexibilität profitiert (laut Duden steht „agil“ für „von großer Beweglichkeit zeugend, regsam und wendig“).
Aber ist diese Allgegenwärtigkeit berechtigt?
Wir bei Nagler & Company sehen Agilität als Zukunftschance und sind erfahren bei der Umsetzung agiler Arbeitsweisen und der Digitalisierung von Prozessen. Bei Migrations-Projekten, welche beispielsweise ein Versions-Upgrade zum Ziel haben, oder durch welche die Migration der Geschäfts-Prozesse von einem Anbieter zu einem anderen durchgeführt werden soll, steht das Datum und der Scope schon zu Beginn fest. Das bedeutet, dass am Ende die vordefinierte Funktionalität zur Verfügung stehen muss, man aber versucht ist, den Weg dorthin nach eigenem Ermessen zu gestalten. Das widerspricht zum Teil den Ideen agiler Arbeitsweisen – vor allem der von Scrum, die von einer iterativen Verbesserung pro Sprint ausgeht und am Ende eines Sprints dem Kunden ein lauffähiges Produkt ausliefern möchte.
Bei Kanban – um ein anderes Beispiel zu nennen – repräsentiert der Fluss den wichtigsten Punkt des Prozesses. Im Releasewechsel oder in einem Migrationsprojekt gestaltet es sich allerdings schwierig, schnelle, kleine Releases durchzuführen, wenn die produktive Version nur einmal am Ende umgestellt werden soll.
Daraus resultiert, dass sich solche Projekte, obwohl sie sich agil nennen, häufig wenig bis gar nicht an das Manifest für Agile Softwareentwicklung bzw. an deren Prinzipien halten.
Unabhängig davon, ob Lean, Scrum, Kanban oder eine der zahlreichen Hybridversionen angewendet wird, werden in agilen Projekten die Aufgaben so zerlegt, dass diese vom Projektteam in Eigenverantwortung selbstständig bewältigt werden können.
Dadurch können, unter anderem, folgende Vorteile realisiert werden:
- Die Kommunikation innerhalb des agilen Teams intensiviert sich – Entscheidungen bezüglich Design und Realisierung können ohne Eskalation getroffen werden und anstatt Top-Down bzw. Bottom-Up Kommunikation findet der Informationsaustausch lateral auf Team-Ebene statt.
- Demonstrierbarer Fortschritt wird kurzfristig erzielt und ermöglicht die Einbindung der Anwender zu einem sehr frühen Zeitpunkt. Dadurch können sich im Laufe der Zeit ergebende Impulse eingebracht bzw. kann im Bedarfsfall korrigierend eingegriffen werden.
- Alle Stakeholder sind permanent in den Fortgang des Projektes eingebunden – dies schafft einerseits ein Maximum an Transparenz, was wiederum Vertrauen schafft und somit den Buy-In der Entscheider fördert.
Die Realisierung dieser Vorteile erfordert allerdings ein gehöriges Maß an Konsequenz und Disziplin. Um diese Disziplin sicherzustellen, gibt es in den verschiedenen agilen Vorgehensweisen – ebenso wie im klassischen Wasserfallmodell – etablierte Prozesse, die in ihrer Gesamtheit als Regelwerk zur konsequenten Anwendung dienen.
In jenen Fällen, wo dieses Regelwerk im Projektalltag konsequent gelebt wird, ist die Allgegenwärtigkeit von „agil“ durchaus berechtigt – ja sogar erwünscht.
Wird andererseits das Regelwerk gar nicht oder nur teilweise angewendet, so läuft man als Organisation Gefahr, sich zwar „agil“ auf die Fahnen geschrieben zu haben, kann aber die Vorteile des agilen Vorgehens nicht lukrieren, was im Worst-Case-Szenario zum Scheitern des Projektes führt.
Würde man also beispielsweise in einem Projekt die Arbeitspakete (Backlog-Items) von vornherein zukünftigen „Sprints“ zuordnen, dann widerspricht dies dem agilen Gedanken, da solche Entscheidungen (in welchem Sprint ein Arbeitspaket erledigt wird) auf Team-Ebene getroffen werden sollen. Im noch schlimmeren Fall werden Arbeitspakete, die zwar für Sprint x geplant waren, dann aber nicht zustande gekommen sind, hurtig einfach in den nächsten Sprint geschoben. Man hat dann zwar den „agilen Werkzeugkasten“ bei der Hand (Sprints, Backlog-Items, Daily Standup-Meetings…), lebt aber den agilen Gedanken nur oberflächlich und zwingt die agile Methode eigentlich ins Korsett des klassischen Wasserfallmodells.
Obiges Beispiel ist nur eines von vielen – Stolpersteine bei der Umsetzung von Agilität gibt es zahlreiche.
Nagler & Company hat zahlreiche Erfahrungen auf diesem Gebiet gesammelt und als „Agile Best Practice“ kondensiert. Dabei wird im Zuge eines Workshops die aktuelle Situation eines Projektes analysiert, Fallstricke werden aufgezeigt und gemeinsam eine Lösung zur Vermeidung derselben erarbeitet.
Change is constant – wir unterstützen Sie dabei.
