Agile Elemente in sequenzielles Vorgehen integrieren
Beim Stuttgarter Stammtisch wurde die Frage gestellt, ob und wenn ja wie sich agile Elemente ins sequenzielle Vorgehen nach Wasserfall integrieren lassen. Gestellt hat die Frage ein Student der DHBW Stuttgart, der dieses Thema in seiner Studienarbeit erörtert. Im Rahmen der Diskussion konnten folgende Punkte festgehalten werden.
1. Planung / Iteration
Der PMBoK® fordert grundsätzlich eine Planung, die dem Vorhaben angemessenen ist. Die Arbeitspakete, Meilensteine oder Quality Gates können eingeplant werden, um z.B. zusätzliche Qualitätssicherungsmaßnahmen durchführen oder Zwischenergebnisse bewerten zu können. Dies ist meistens mit zusätzlichem Aufwand verbunden. Deshalb müssten Projektleitende ggf. eine Kosten-Nutzen-Rechnung vorlegen, um sich einen entsprechenden Projektplan genehmigen zu lassen.
Im Rahmen von Software-Projekten waren sich die Teilnehmenden einig, dass bei individuell angepasster Software, bei Software mit vielen Schnittstellen und bei Einbindung von Software in eine komplexe Systemlandschaft eine vorangestellte Konzeptionsphase von Vorteil ist. In dieser Konzeptionsphase können Rahmenbedingungen eingeplant werden, bevor mit dem eigentlichen Coding begonnen wird.
Beides führt dazu, dass im plangetrieben Vorgehen „Schleifen" integriert werden können.
2. Umsetzung / Kommunikationsanlässe
Im Rahmen der Umsetzungsphase wurden folgende Elemente aus dem agilen Vorgehen als hilfreiche Methoden betrachtet:
Das Daily Standup hilft Team in herausfordernden Projektsituation, von Tag zu Tag kleine Fortschritte zu erkennen. Außerdem hilft das Standup, die Kommunikation zu fördern und aus dem Team Impulse für benötigte Lösungen zu bekommen. Weiter kann das Daily Standup in einer Projektkrise eingesetzt werden, um Vertrauen zurückzugewinnen. Den Projektleitenden können die täglichen Minuten mit dem Team helfen ein besseres Gespür für aktuell benötigte Informationen, Hindernisse oder die Teamperformance zu bekommen. Das Daily Standup muss deshalb nicht entsprechende Reportings ersetzen.
Der Einsatz eines (Kanban)Boards kann genutzt werden, um z.B. Überlastung, Ausfälle oder Engpässe in Abläufen und gemeinsam agierenden Teams aufzudecken. Der Vorteil eines haptischen Boards ist, dass es im Gegensatz zu einer Software oder Datei visueller und damit sichtbarer ist. Die eigentliche Herausforderung ist, eine für das Vorhaben bzw. die Situation geeignete Visualisierung zu finden, um die neuralgischen Punkte aufzudecken. Sind diese neuralgischen Punkte bekannt, kann relativ einfach für Abhilfe gesorgt werden. Diese einfachen „Erfolge" (Quick Wins) zahlen hoffentlich schnell auf die Zufriedenheit und somit die Performance und Qualität ein.
3. Optimierungen / Feedback
Ein dritter Aspekt, der in Projekten nicht erst am Ende durchgeführt werden sollte, ist das Lessons Learnd. Im agilen Umfeld wird das als Retrospektive bezeichnet. Wenn diese positiven Elemente bereits im Projektverlauf genutzt werden, dann erinnert das an CMM oder TQM. Dabei können kleine Veränderungen oder Investitionen einen großen Einfluss auf die Zufriedenheit und somit die Performance und Qualität haben, so dass sich das rentiert.When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
Comments 1
Ich finde es prima, wenn klassische und agile Vorgehensweise voneinander lernen. Auch im agilen Umfeld wird gerne zu Beginn eine Konzeptionsphase genutzt, um die (meist ungenauen) Anforderungen klarer zu bekommen. Die Erstellung eines Pflichtenheftes - so es denn gefordert ist - kann in dieser Phase gemeinsam im Team erfolgen. Der Kunde kann nach dieser Phase erneut entscheiden, ob er das Projekt immer noch mit dem Auftragnehmer durchführen will. Der Auftragnehmer bekommt durch die Ausarbeitung (vorzugsweise mit dem Kunden) ein Gespür dafür, was dem Kunden wichtig ist. Idealerweise werden diese "(Feedback-)Schleifen" regelmäßig mit dem Kunden durchgeführt. Je nach Laufzeit der Phasen gibt es dann kaum noch einen Unterschied zwischen klassisch und agil.
Das Daily Standup habe ich an vielen Stellen gesehen: in Projekten, in agilen Vorgehensweisen und auch bei Fehlersituationen in Bestandssoftware. Ich habe mehrfach erlebt, dass sich das Daily einfach angeboten hat, ohne das jemand etwas von "Agilität" wusste. Es wurde einfach so gemacht. Bei agilen Projekten ist sehr stark die Timebox (meist 15 Minuten) im Fokus. Je größer die Runde wird und je weiter weg von agilen Methoden, desto undisziplinierter und länger habe ich solche "Dailys" erlebt. Wenn sich alle auf die Blockaden beschränken und das nicht zur Informationsveranstaltung für den Projektleiter verkommt, kann es ein großer Hebel sein.
Was das Board angeht, sehe ich das differenziert: In Corona-Zeiten hat sich das digitale Board bewährt, denn es gab keine andere Möglichkeit. Jeder kann jederzeit den Status der eigenen Aufgaben anpassen, Kommentare zum Fortschritt an die Aufgaben schreiben und die Aufgaben können klarer an einer Stelle beschrieben werden. Vor der Pandemie wäre ich mit einem Team immer erst haptisch gestartet. Mittlerweile würde ich die digitale Variante mit entsprechend großem Display bevorzugen. In Produktionsbetrieben, wo alle vor Ort sind und sich nicht erst an den Computer setzen wolle, ist meiner Ansicht nach ein haptisches Board und zumeist ein Kanban-System sinnvoller. Und mit Kanban meine ich nicht nur das Board.
Beim letzte Punkt sehe ich oftmals einen großen Unterschied zwischen Lessons Learned und Retrospektive. Bei Lessons Learned fragte uns meist die Projektleitung: was würdet ihr beim nächsten Projekt / Projektphase anders machen? Eine Retrospektive ist weit mehr als das. Hier machen wir uns große Gedanken darüber, wie so eine Runde am besten funktionieren kann. Der Fokus liegt im Team und nicht auf dem Projekt. Allerdings hält auch niemand die Projektleitung davon ab, ein Retro-Format als Lessons Learned oder als Team-Workshop zu bezeichnen.