Agilität, Projektmanagement
Schreibe einen Kommentar

Ein bisschen agiler, bitte

Mehr als ein Jahrzehnt nach dem agilen Manifest ist agiles Vorgehen im Mainstream angekommen. Bei den kleinen Softwareunternehmen sowieso, aber zunehmend auch bei großen Konzernen. Wo bisher strikt nach Wasserfall vorgegangen werden musste, finden immer mehr agile Ansätze Einzug in die Projekte. Meist aber ausschließlich für die Phase der Programmierung der vorab im Detail spezifizierten Anforderungen. Ein Anfang immerhin, der allerdings nur einen Bruchteil des wahren Potential agilen Vorgehens hebt.

Das klassische Wasserfallvorgehen produziert anfangs gewaltige Mengen Papier bevor am Ende Software entsteht: angefangen bei einem Grobkonzept über ein Fachkonzept zu einem IT-Konzept. Stufe für Stufe werden die fachlichen Anforderungen detailliert und mit allen Beteiligten abgestimmt bis endlich mit der Umsetzung der Anforderungen begonnen werden kann.

Was theoretisch nach einem brauchbaren Vorgehen klingt, hat in der Praxis einige Tücken. Zum einen ist der Prozess langwierig und schwerfällig: Vom Erkennen einer Anforderung bis zu ihrer Umsetzung in der Software können durchaus Jahre vergehen. Zum anderen fehlt Flexibilität: Anforderungsänderungen sind zwar möglich, werden aber als Ausnahmen betrachtet und meist recht schwergewichtig verwaltet. Im Ergebnis führt das zu langen Projektlaufzeiten für Softwaresysteme, die dann teilweise nicht mehr zur mittlerweile veränderten Realität passen, dafür aber viele Anforderungen zweifelhaften Nutzens enthalten. Diese Kluft zwischen echten und Nutzen stiftenden Anforderungen einerseits und im System umgesetzten Anforderungen andererseits tritt zudem meist erst ganz am Ende des Wasserfalls zu Tage und kann dann schwierig oder nur mit erheblichen Mehrkosten wieder geschlossen werden.

Working software over comprehensive documentation.
Manifesto for Agile Software Development

Mittlerweile haben auch große Unternehmen eher klassischer Branchen diese Problematik durchaus erkannt und wollen agiler werden. Ohne sich allerdings komplett vom Wasserfall zu verabschieden. Was liegt also näher als einfach auf Basis des detaillierten Fachkonzept die agile Umsetzung zu starten? Aus den Anforderungen des Fachkonzepts wird schnell das Backlog erstellt und in kleinen Häppchen vollständig abgearbeitet. So entsteht nach jedem Sprint benutzbare Software und es fühlt sich irgendwie dynamisch an. Ziel erreicht.

Ein Etappenziel jedenfalls. Jeder neue Softwarestand erzeugt nämlich neue Rückmeldungen und neue Erkenntnisse. Und zwar oft solche, die leider bisher nicht oder nicht richtig im Fachkonzept berücksichtigt wurden. Schnell wächst das Backlog und es muss nun wirklich priorisiert werden in dem Sinne, dass die Anforderungen im Backlog nicht vollständig umgesetzt werden, sondern eben nur bis der erwartete Nutzen erreicht oder das Budget aufgebraucht ist. Nun wird nicht nur in kurzen Iterationen ausgeliefert, sondern nutzenorientiert mit flexiblem Umfang gearbeitet. Ein weiteres Etappenziel erreicht.

Nach einigen Sprints erkennt man allerdings ein wiederkehrendes Muster: Viele fachliche Anforderungen klären sich tatsächlich erst im Laufe der Umsetzung am konkreten Objekt und im Dialog mit echten Anwendern. Viel der mühsamen Detailarbeit eines Fachkonzepts, beispielsweise die Erstellung von GUI-Prototypen, wird während der Sprints im Prinzip nochmals durchgeführt allerdings unter anderen Voraussetzungen und mit anderem Ergebnis. Ein deutlich schlankeres Fachkonzept oder ein etwas detaillierteres Grobkonzept hätte als Aufsatzpunkt für das agile Vorgehen genauso gute Dienste geleistet und wäre schneller und billiger zu haben gewesen.

Fazit

Es spricht absolut nichts dagegen Ideen oder Konzepte zu Papier zu bringen und gemäß Wasserfall abzunehmen. Es spricht aber auch viel dafür diese Konzepte möglichst schnell und möglichst konkret zu erproben. Wenn am Ende ohnehin eine agile Umsetzung angestrebt wird, würde ich mir in vielen Fällen mehr Mut wünschen, frühzeitig und auf gröberem Niveau in den agilen Modus zu wechseln. So lässt sich viel fruchtlose Doppelarbeit in der Feinspezifikation von Anforderungen vermeiden. Es entsteht früher produktiv einsetzbare Software, die am Ende dann wirklich zu den Anforderungen passt, die sich auf dem Weg dorthin ergeben und klären.

Artikelbild: Vincent Lock bei flickr.com (CC BY 2.0)

Dir hat dieser Beitrag gefallen? Dieses Blog ist bewusst werbefrei, weil nur der Inhalt zählt. Wenn du deine Wertschätzung für diesen Beitrag zeigen willst, dann teile ihn wo auch immer. Und ich freue mich, wenn du einen kleinen Beitrag zu den Unkosten leistet. Das geht ganz unkompliziert mit Steady

NEU: Das Manifest für menschliche Führung als Taschenbuch.

Taschenbuch Cover Manifest Zum ersten Jahrestag gibt es das Manifest für menschliche Führung nun in ausführlicher Fassung (inkl. Workshop-Format) als Taschenbuch bei Amazon (auch als E-Book erhältlich). Ich freue mich über Rezensionen und viele Empfehlungen an Freunde und Bekannte.

Buch Kaufen

Kategorie: Agilität, Projektmanagement

von

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.