Agile Projekte und Deadlines – ein unvereinbarer Widerspruch? Nicht unbedingt! Flexible Scopes, laufender Dialog und clevere Priorisierung ermöglichen es in agilen Projekten, feste Termine einzuhalten. So meistern Sie den Balanceakt.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Agile Projekte und Deadlines – ein unvereinbarer Widerspruch? Nicht unbedingt! Flexible Scopes, laufender Dialog und clevere Priorisierung ermöglichen es in agilen Projekten, feste Termine einzuhalten. So meistern Sie den Balanceakt.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Es ist ein weit verbreitetes Missverständnis, dass sich agile Methoden wie Scrum oder Kanban nicht mit Deadlines oder fixen Lieferterminen in Einklang bringen lassen. Diesem Missverständnis möchte ich mit diesem Artikel widersprechen und Wege aufzeigen, wie agile Methoden unter festen Lieferzusagen vorteilhaft eingesetzt werden können.
In über zwölf Jahren praktischer Erfahrung mit agilen Projekten habe ich durchweg gute Erfahrungen mit den folgenden Ansätzen gemacht, die auch in der Fachliteratur ausführlich beleuchtet worden sind.
Agile Methoden spielen ihre Stärken vor allem in Problemstellungen aus, in denen eine ausführliche Analyse und eine Planung im Vorfeld schwierig, aufwendig oder fehleranfällig sind. Dafür kann es eine Reihe von Gründen geben:
Je mehr dieser Herausforderungen gegeben sind, desto wahrscheinlicher (und häufiger) werden im Projektverlauf Anforderungen, Lösungsentwürfe und Projektpläne angepasst werden müssen. Das bedeutet nicht, dass eine vorherige Planung deshalb weniger wichtig wäre! Planen ist eine zentrale Aktivität agiler Methoden (in Scrum z.B. im Sprint Planning ritualisiert). Es stellt aber besondere Anforderungen an die Projektpläne, die jederzeit änderbar und daher besonders schlank und leichtgewichtig sein müssen. Projektskizzen auf einem Whiteboard oder dynamische Backlogs sind schneller angepasst als detaillierte Feinspezifikationen oder vertraglich vereinbarte Pflichtenhefte.
Für den Fall, dass bereits eine detaillierte Feinplanung vorliegt, plädiere ich dafür, das Projekt einfach klassisch umzusetzen. Agile Methoden können kaum einen Mehrwert stiften, wenn bereits eine exakte Durchführung mit fixen Lieferobjekten vereinbart wurde und im Verlauf nicht mit größeren Änderungen zu rechnen ist. Im Folgenden gehe ich daher davon aus, dass es im Projekt zwar feste Liefertermine geben mag, aber zumindest bei Umfang und Funktionalität noch Entscheidungsspielräume offen sind.
Ein bewährter Standardansatz in agilen Projekten mit festen Lieferterminen besteht darin, den Zeit- und Kostenrahmen im Vorfeld zu fixieren, innerhalb dessen Ergebniswert und Kundennutzen über den Projektverlauf hinweg maximiert werden. Mit agilen Methoden für die Planung von Umfang und Aufwand, wie z.B. User Story Mapping (Patton, 2015) und Magic bzw. Affinity Estimation (Gloger, 2014), kann dieser Rahmen initial festgelegt werden, ohne dabei den Funktionsumfang schon allzu genau festlegen zu müssen.
Insgesamt empfiehlt es sich auch bei festen Lieferterminen, das Projekt auf Basis bewährter agiler Prinzipien aufzubauen. Hierzu gehört unter anderem
Eine Herausforderung des Ansatzes "Zeit/Kosten fix, Inhalt/Umfang variabel" ist, dass Projekte in der Regel bestimmte Mindestziele erreichen müssen, ihr Scope also nicht komplett frei gestaltet werden kann. Beispielsweise wird ein neues Onlinebanking-System ohne grundlegende Funktionen wie An- und Abmeldung, Kontoübersicht, Überweisungen und Daueraufträge nicht in den Produktivbetrieb gehen können. Diese Kernfunktionen sind bereits zum Projektstart ermittelbar und stehen in den meisten Fällen auch nicht zur Diskussion.
Eine nützliche Technik ist hier das bewusste Unterspezifizieren von Anforderungen. Es spricht auch in agilen Projekten nichts dagegen, Anforderungen wie "Nutzer müssen sich anmelden und ihren Kontostand überprüfen können" bereits zu Projektstart in Form von Akzeptanzkriterien festzuhalten und ihre Umsetzung zu vereinbaren. Der genaue Funktionsumfang, mögliche Komfortfeatures, Feinschliff im Design und ähnliche Aspekte können dann noch während der späteren Umsetzung entschieden werden und bieten dem Team wichtige Entscheidungsspielräume. Viele Teams nutzen die Formulierung von User Storys als Hilfsmittel, um kritische Anforderungen schon früh grob festzuhalten, ohne dabei schwerfällige Feinspezifikationen erstellen zu müssen.
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
Das ist ja mal ein toller Ratschlag
18.09.2024
Zitat: "Für den Fall, dass bereits eine detaillierte Feinplanung vorliegt, plädiere ich dafür, das Projekt einfach klassisch umzusetzen."
Genau das ist aber bei mir der Fall. Ich habe aber kein Mitspracherecht bei der Implementierung der Prozesse, sondern "agil" ist gesetzt und zwar ausnahmslos für die ganze Firma.
Unsere Kunden (Automobilhersteller) geben auch ganz klare Vorgaben hinsichtlich detaillierte Lastenhefte und zu erreichenden Projektmeilensteinen und Performancezielen zu definierten Zeitpunkten.
Da bleibt kein Raum für das im eigentlichen agilen Gedanken des "Backlog" und "komm ich heut' nicht, komm ich morgen"
Diese Dinge sind einfach UNVEREINBAR!
Und daraus erklärt sich auch, warum Projekte so katastrophal laufen: Es ist die einzige Möglichkeit, wenn sich einige Zahnräder im Getriebe vorwärts drehen und die andere rückwärts.
Ich hatte gehofft in diesem Artikel Lösungshinweise für die existierenden Probleme zu bekommen, aber stattdessen wurde ich vollumfänglich in meiner Meinung bestätigt: Es geht (zumindest bei uns( NICHT!
Hallo Herr Geiger,…
18.09.2024
Hallo Herr Geiger,
herzlichen Dank für Ihren wichtigen Kommentar. Ich habe unseren Autor Herrn Pukall um einen Kommentar gebeten. Hier seine Antwort.
Viele Grüße
Nathalie Röseler
Redaktion projektmagazin.de
------------
Hallo Herr Geier,
ich kann Ihren Frust verstehen, auch wenn ich nicht weiß, ob ich der richtige Adressat dafür bin. Ein paar Gedanken dazu kann ich Ihnen allerdings anbieten.
Zuallererst ist es natürlich weiterhin ein Markenzeichen einer professionellen Dienstleistung, seine Kunden und Stakeholder zur Methodik zu beraten, die ihren Interessen am meisten dient. Das muss, zu dieser Aussage stehe ich, nicht unbedingt etwas Agiles sein oder man gestaltet sich den Prozess so, wie es für das Projektziel und das Umfeld am besten passt. Vorgaben wie "Agil ist gesetzt" lassen weiterhin große Spielräume offen, wobei ich natürlich nicht weiß, wie detailliert die Vorgaben bei Ihnen sonst sind.
Pflicht und Privileg eines jeden Dienstleisters ist es, individuell zu prüfen, ob und unter welchen Umständen man einen Auftrag annehmen kann. Sollte ein Projekt unter den gegebenen Rahmenbedingungen nicht zur Zufriedenheit des Kunden realisierbar sein, sehe ich es als den professionellen Weg, den Auftrag abzulehnen und Verhandlungen über Ziele und Rahmenbedingungen anzubieten. Eventuell liegt das ja im Rahmen ihrer Möglichkeiten.
Falls nicht, wäre mein nächster Impuls, sich Unterstützung bei Kolleginnen und Kollegen zu suchen. Sie sind sicher nicht der Einzige, der von einer firmenweiten Vorgabe betroffen ist - wie gehen denn andere in Ihrer Situation mit dieser Herausforderung um? Falls sich intern niemand findet, kann man auch externe Kontakte suchen. Ihre lokale Agile User Group bespricht Situationen wie Ihre sicher regelmäßig.
Nicht zuletzt steht Ihnen natürlich immer ein großer und vielfältiger Beratungsmarkt zur Verfügung. Ihre Situation ist weiter verbreitet, als Ihnen vielleicht bewusst ist, und es gibt fähige Dienstleister da draußen, die mit Ihnen gerne das Problem und mögliche Lösungen im Detail besprechen.
Ich hoffe, hier ist für Sie etwas dabei. Viel Erfolg bei Ihren Herausforderungen.
Beste Grüße!
Kai Pukall
Hallo Herr Pukall Vielen…
20.09.2024
Hallo Herr Pukall
Vielen Dank für ihre Antwort.
Lassen sie mich auf die Punkt ihrer Antwortmail eingehen. Ich hoffe sie nehmen es nicht persönlich, wenn ich in einigen Punkten sehr direkt werde.
Sie schrieben: “... auch wenn ich nicht weiß, ob ich der richtige Adressat dafür bin.”
Sie sind aus meiner Sicht auf jeden Fall ein richtiger Adressat, denn
1.) haben sie in ihrer Überschrift angekündigt:
“Agile Methoden und feste Liefertermine: ein Widerspruch? Der richtige Umgang mit Deadlines in agilen Projekten”
Das hat mich sehr interessiert, denn dieser Widerspruch war so ziemlich das erste Problem, dass mir bei Einführung agiler Methoden bei uns aufgefallen ist, was ich auch thematisiert habe. Ich bekam allerdings nie befriedigende Antworten, was mich wie gesagt auf ihren Beitrag sehr neugierig machte.
Nur um dann beim Lesen festzustellen, das man, sobald man mit Deadlines und anderen Projektvorgaben konfrontiert ist, besser einen anderen Prozess wählen sollte.
Wenn das keine Enttäuschung ist! Dazu brauche ich auch keinen Berater, soviel weiß ich selbst.
Wie ich schon in meinem ersten Kommentar schrieb, steht mir diese Wahl eben nicht frei da eine firmenweite Vorgabe ohne Alternative. Im Übrigen eine Vorgabe die
2.) dem Management unserer Firma von Beratern wie ihnen für viel teures Geld anempfohlen wurde, auch wenn er bei der Entwicklung von Produkten wie unseren aus meiner Sicht eher ungeeignet ist.
Lassen sie mich das etwas ausführen.
Das Thema “agil” ist entstanden in einer Gruppe von einigen wenigen Software-Entwicklern. Entwicklern für Computerprogrammen wie z.B. “Word” (nur als Beispiel) die auf PCs, Smartphones, Tablets, etc. laufen.
Diese Art von Software hat in der Regel keine Echtzeitanforderungen, sie läuft nicht auf Embedded-Steuergeräten und es hängen normalerweise keine Leben oder Sachschäden von der richtigen Funktion ab.
Da spielt es auch keine große Rolle, wenn sie Inhalte über das Backlog verschieben und ich kann quasi jede Woche eine neue Version "raushauen". Wenn was nicht passt, gibt es halt noch ein neues Release, davon wird niemand verletzt. Tests lassen sich oft sehr gut weitgehend automatisieren.
All das funktioniert bei der Entwicklung von echtzeitkritischen, sicherheitsrelevanten embedded (Regelungs)-Systemen nicht oder zumindest nicht gut.
Das agile Manifest auf dem "agile" ja beruht, umfasst nur 4 Punkte (https://agilemanifesto.org):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Das ist alles. Nicht mehr, nicht weniger.
Was "ihre" (Berater-) Branche allerdings aus dieser sehr “leanen” Idee (zum Zweck des Geldverdienens) gemacht hat, ist ein Monster Frankenstein’scher Art.
SAFe, Scrum, Certified Scrum-Master (Zertifikate, die man im Übrigen dann (praktischerweise für die Berater –> more money) auch noch alle 2 Jahre erneuern soll, SAFe Process Charts, die komplexer sind als die Prozesse, die sie abgelöst haben, zersplitterte Zuständigkeiten, die sich eigentlich “selbst organisieren” sollen (“agile” sollte eigentlich keine Projektmanager benötigen), was aber hinten und vorne nicht funktioniert, zumindest nicht in meiner mittlerweile mehrjährigen Erfahrung.
"Lean" und "agile" ist davon nichts. Man hat mehr oder weniger die alten Prozesse in ein neues Gewand gepackt. Was hat das noch mit den 4 Punkten des agilen Manifests zu tun?
Die Urheber des agilen Manifests wenden sich mittlerweile selbst mit Grausen von dem ab was die Industrie aus ihren 4 Sätzen gemacht hat.
Und viele Entwickler selbst sind wirklich angewidert z.B. von nutzlosen Standup-Meetings und anderen Vorgaben, die der Software nicht weiterhelfen aber viel Zeit und Nerven kosten.
Das geht so weit, dass Mitarbeiter kündigen und die Firma verlassen oder zumindest teilweise die innere Kündigung vollziehen und den Wahnsinn still erdulden.
Weiter schrieben sie: “Falls nicht, wäre mein nächster Impuls, sich Unterstützung bei Kolleginnen und Kollegen zu suchen. Sie sind sicher nicht der Einzige, der von einer firmenweiten Vorgabe betroffen ist - wie gehen denn andere in Ihrer Situation mit dieser Herausforderung um? Falls sich intern niemand findet, kann man auch externe Kontakte suchen. Ihre lokale Agile User Group bespricht Situationen wie Ihre sicher regelmäßig.”
Dazu kann ich ihnen sagen, dass Kollegen in der Regel eher mich fragen, was sie tun sollen, als umgekehrt. Ich bin gewiss nicht der Einzige, der diese Probleme hat und sieht.
Und aus meiner Sicht sind “externe Kontakte” (d.h. noch mehr Berater für noch mehr Geld?) keine Lösung, denn da haben wir unsere “agile Hölle” ja erst her.
Und andere “externe Kontakte”, d.h. Bekannte und Freunde, die auch in der SW-Entwicklung arbeiten, klagen mir so ziemlich das gleiche Leid, dass ich gerade versuche zu beschreiben.
Mein Fazit:
Aus meiner Sicht ist das agile Manifest so nicht auf die Produkte anwendbar, die ich/wir entwickeln (als Stichworte dazu noch VDA 6.3, Automotive SPiCE) oder nur unter massiver Verformung der Grundideen. Alles, was daraus in der Industrie erwachsen ist, wie z.B. SAFe, Scrum, etc., hat sich bzw. wurde aktiv zu einer “Money-Making-Machine" für das Berater-Business entwickelt, die die beratenen Firmen viel Geld kostet, der Gegenwert aus meiner Sicht zweifelhaft ist.
Und wenn es nicht funktioniert, dann liegt es am Anwender und er braucht noch mehr “Beratung” 😉.
Mit freundlichen Grüßen,
Andreas Geier
Antwort von Kai-Marian…
23.09.2024
Antwort von Kai-Marian Pukall:
Hallo Herr Geier,
danke für Ihre ausführliche und ehrliche Antwort. Wie gesagt, kann ich Ihren Frust gut verstehen, und in vielen Punkten teile ich ihn auch. Mein Verständnis von Agilität orientiert sich sehr stark an den ursprünglichen Ideen u.a. des Manifests; Zertifizierungen und komplizierte Frameworks sehe ich ähnlich kritisch wie Sie. Agiles Arbeiten sollte aus meiner Sicht schlank und pragmatisch ablaufen und nur die Werkzeuge verwenden, die es dafür unbedingt braucht. Ich habe den Eindruck, dass Ihr Umfeld diesem Anspruch nicht immer gerecht wird. Nachvollziehbar, dass eine Überschrift wie meine bei Ihnen die Hoffnung weckt, hier eine Lösung für dieses Grundproblem Ihrer Organisation zu finden - an dieser Erwartung kann mein bescheidener Artikel über ein paar simple Planungshilfsmittel natürlich nur scheitern.
Tatsächlich bin ich nicht (mehr) als Berater tätig, aus einem persönlichen Bedürfnis heraus, mein eigenes Arbeitsumfeld aktiv zu verändern, anstatt von außen Ratschläge zu erteilen. Am Ende braucht eine erfolgreiche Organisation vor allem Menschen, die von innen heraus anpacken und Dinge verbessern. Vor diesem Hintergrund möchte ich Ihnen hier keine Leistungen verkaufen und Ihnen auch nicht sagen, was Sie tun oder lassen sollten, dafür fehlt mir ohnehin das Kontextverständnis. Ich wünsche Ihnen aber für Ihre Herausforderungen viel Erfolg.
Kai-Marian Pukall
Vielleicht hilft eine neue Perspektive?
24.09.2024
Hallo Herr Geier, hallo Herr Pukall,
vorab: Ich bin Berater, allerdings kein "Agile Coach", sondern ganz trivialer PM-Berater. Mein Schwerpunkt ist die Kommunikation.
Dass Sie in Ihren Erwartungshaltungen und Lösungsvorschlägen ein wenig aneinander vorbei reden, haben Sie ja bereits beide festgestellt.
Vielleicht helfen Ihnen ein paar andere Perspektiven, auf die ich Sie gerne aufmerksam machen möchte.
1. Agiles vs. traditionelles PM: Dieses Dilemma wird hier bilderbuchhaft deutlich. Hier könnte die Perspektive des hybriden Projektmanagements helfen. Ich habe verstanden, Herr Geier, dass in Ihrem Unternehmen "agile" gesetzt ist. Aber Sie als Projektverantwortlicher sind - insbesondere gegenüber den Auftraggebern - im hybriden Setting. Ihre Herausforderung (und das ist eine echte Herausforderung) besteht darin, nach außen klassisch, nach innen agil agieren zu müssen.
2. "Komme ich heut nicht, komme ich morgen" ist KEIN agiles Konzept. Wer so arbeitet, missbraucht Agilität "sträflich". Die Strafe besteht in dem von Ihnen, Herr Geier, beschriebenen Durcheinander. Nicht umsonst gibt es explizit ein Sprintziel bei Scrum. Wer ohne ein klar vereinbartes Sprintziel startet, arbeitet nicht agil. Dies gegenüber dem Entwicklungsteam durchzusetzen, kann anstrengend sein, ist aber 100 Prozent agil.
3. Aus traditioneller Sicht ist - und das dürfen Sie, Herr Geier, nicht intern kommunizieren, agiles Arbeiten (insbes. Scrum) lediglich das Abarbeiten einer To-do-Liste in einem kleinen Team. Und hier helfen IMHO die Tipps von Herrn Pukall sehr wohl: Die spezifizierten Anforderungen des AG müssen hierzu allerdings ganz oben im Backlog stehen. Und nichts anderes. Es ist allerdings oft sehr schwer, Spezifikationen in ein Backlog umzuschreiben. Die größte Gefahr dabei: Die Entwickler schreiben selbst (!) Backlog-Items dazu, die gar nicht erforderlich sind. ("Wenn wir schon xy machen, dann ist es doch ganz logisch, dass wir noch z dazu machen").
4. Agilität sind keineswegs nur die vier erwähnten Prinzipien! Hier empfehle ich wärmstens den Beitrag von Timm Richter: https://www.projektmagazin.de/artikel/agilitaet-wieder-ins-gleichgewich…
Dies ist wie gesagt, nur der Versuch, weitere Perspektiven aufzuzeigen.
Mein Plädoyer an alle: Kommuniziert offener und klarer, insbesondere über Ziele und Commitments. Denn meine ganz persönliche Meinung: Ob agile oder traditionell ist völlig Banane. Es kommt ausschließlich darauf an, was das Team wirklich will.