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.
×
Stay Informed

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.

3 Möglichkeiten – „Projekte visualisieren“
7 Tipp zur schwierigsten Disziplin – dem Risiko-Ma...
 

Comments 1

Marco Jacob on Sonntag, 04. September 2022 16:40

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.

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.
Already Registered? Login Here
Sonntag, 01. Oktober 2023

Sponsoren & Partner

Premier Sponsoren

Campana Schott Logomodul RGB 380px 72dpi        haufe akademie        TPG Logo CMYK rot 2022        Xuviate

Sponsoren

Logo Alvission   Logo Amontis  Blue Ant neu 2016 ohne flag cando Logo Contec X 300x90  Hexagon Logo Korn_Ferry_Logo.jpg maxpert logo microTOOL Logo nextlevel 300x90  Logo Planisware 300x90   PMSmart Logo plusDV Logo Projektmanagement Software BCSPS Consulting 2017 neu 300x90  Sonoxo web  Thinking Portfolio logo 192x192  WuttkeTeam Gita


Chapter-Partner

      Projektmagazin Logo2019 300x90 CMYK    BENU pmpodcast Logo    smbs logo new     Logo Thesis 300x90  Arden University

Cookies helfen uns, den Besuch der Website komfortabler für Sie zu machen. Dazu gehören bei uns auch anonymisierte statistische Auswertungen, aber keine Werbetracker! Bitte akzeptieren Sie also Cookies.