„Wir sind jetzt agil“ – und was nun?

Manchmal bekommt man das Gefühl, jedes Unternehmen, das etwas auf sich hält, nimmt Teil am „Buzzword Bingo“ und erwähnt neben dem Schlagwort „agil“ am besten auch noch „Scrum“, „Kanban“ und „Design Thinking“. Ziel soll sein, die Unternehmensvision neu und vor allem modern auszurichten. Die Begriffe sind allgegenwärtig und werden inflationär genutzt. Haben Sie das nicht in den letzten Monaten auch häufig aus Unternehmenskreisen gehört, stolz vorgetragen auf einer Fachkonferenz oder als Inhalt eines zukunftsweisenden Artikels online veröffentlicht?

Doch was genau verbirgt sich hinter dem Begriff „agil“ und wieso möchte es nun jeder sein? Dieser Blogbeitrag soll dazu beitragen, einen praxisnahen Einblick in agile Herangehensweisen zu gewähren. Wichtige Voraussetzungen für eine Entwicklung Richtung Agilität sind Offenheit der Mitarbeiter, eine gewisse Nähe zum Digitalen und im besten Fall flache Hierarchien. Zudem einerseits die Bereitschaft zur Veränderung auf Mitarbeiterseite und andererseits der Rückhalt der Unternehmensführung, dass Veränderung auch gewünscht ist.

Was ist das Ziel einer agilen Herangehensweise?

Primär ist es die Zufriedenheit des Kunden, die wachsen soll.

Schnelle Erfolge durch Transparenz und konkreten Nutzen für den Kunden zu erreichen lautet die Devise. Das Abarbeiten von Projektplänen, Erledigen von endlosen To-do-Listen und das Erreichen von Meilensteinen, von denen der Kunde nichts mitbekommt oder nach langen Projektphasen Ergebnisse erhält, die aus seiner Sicht anders gewünscht waren, sind aus agiler Sicht eher „Scheinerfolge“.

Agile Herangehensweisen brauchen das iterative Vorgehen eines selbstorganisierten Teams sowie schnelle Zyklen der Auslieferung und ermöglichen damit ein schnelles Feedback des Kunden. Dieses schnelle Feedback holt Änderungswünsche des Kunden bewusst frühzeitig ab, um kurzfristig eine Möglichkeit für Änderungen am Produkt zu erwirken. So erhält der Kunde in regelmäßigen Abständen ein Inkrement, also ein Teilprodukt, das er bereits „anfassen“ und zu dem er Feedback geben kann. Das Projektteam freut sich also über Änderungswünsche. Die Zufriedenheit mit dem Endprodukt im Vergleich zum Endprodukt bei Wasserfallprojekten können Sie sich vorstellen. Denn wenn der Kunde zu spät oder erst ganz zum Schluss eingebunden wird, bemerkt man erst wenn es zu spät ist, wenn sich der Kunde den Dialog, den Prozess oder die Verarbeitung doch irgendwie anders vorgestellt hat. Das ist ein perfekter Nährboden für zähe Diskussionen und Unzufriedenheit.

Doch Agilität misst seinen Erfolg auch an bezahlten Rechnungen. Wenn schon das Ergebnis zu Beginn nicht im Detail definiert ist, so müssen es doch das Budget und die Laufzeit sein. Natürlich wird auch ein zugesichertes minimales Endprodukt mit „MUSS-Features“ beschrieben, das sogenannte Minimum Viable Product. Diverse SOLL- und KANN-Features am Endprodukt sind je nach Fortschritt und Budget möglich oder eben nicht.

Ein Beispiel

Eine Firma möchte einen neuen Prozess einführen. Da die Projektbeteiligten den neuen Prozess in der Theorie noch nicht zu 100% im Detail beschreiben können und wollen, verzichten sie auf das Anfertigen eines Pflichtenhefts. Der Prozess muss auf Vorgabe der Firma in X Monaten eingeführt sein, das Budget bemisst sich auf Y Euro. Also beschreiben die Projektmitarbeiter sukzessive und pro Sprint anstehende Aufgaben und testen die Ergebnisse des vorherigen Sprints. Änderungswünsche sind willkommen und werden ad hoc angepasst, jedoch separat beschrieben und abgenommen. Bei jeder Änderung wird die Auswirkung auf das Endprodukt und die Features beschrieben. Sollten sich daraus Engpässe ergeben, können die Beteiligten aus der Situation heraus entscheiden, ob sie den Anpassungswunsch zu Lasten eines anderen Features umgesetzt haben möchten oder nicht. Mit Ablauf der Projektlaufzeit (oder des Budgets) wird die Firma in der Regel mit dem Ergebnis zufrieden sein, da die Entscheider an der Entwicklung beteiligt waren und das Endprodukt genau die Funktionalitäten aufweist, die sie sich vorgestellt haben.

Im Bereich Agilität kommt schnell der Irrglaube auf, es handle sich um ein chaotisches System und jeder mache, was er will. Das ist so nicht richtig, denn Struktur, Leitsätze und Prinzipien sind im sogenannten Agilen Manifest beschrieben: http://agilemanifesto.org/iso/de/manifesto.html. Im Endeffekt geht es doch auch gar nicht darum, ob agil JA oder NEIN, sondern wie viel agil und ob diese Methodik überhaupt zum Unternehmen passt. Diese Entscheidung muss jeder für sich selbst treffen.

Hinterlassen Sie einen Kommentar

Nach oben