NBA85: Agilität vs. Gantt-Chart: Ein unlösbarer Konflikt?

Eine Auflösung mit der Stacey Matrix und warum das Magische Dreieck auf dem Kopf stehen muss.

Inspiriert von einer Diskussion auf Mastodon gehe ich darauf ein, dass agile Projekte kein klassisches Projektmanagement brauchen. Es ist eher die Frage, welche Art von Projekt wir vor uns haben. Dies erläutere ich anhand der Stacey Matrix und dem magischen Dreieck.

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile

—

NBA84: Mein Buch „Agiles Arbeiten in der Praxis“

• https://no-bullshit-agile.de/nba84-buch-agiles-arbeiten-in-der-praxis.html

Mastodon Hashtag AgilePuls

• https://mastodon.social/tags/AgilePuls

Mastodon Thread „Gantt“

• https://mastodon.social/@nobsagile/115418923432238125

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile.

Mein Name ist Thomas.

Regelmäßig spreche ich hier kurz und knapp über Themen rund um agiles Arbeiten.

In der letzten Folge habe ich mein Buch Agiles Arbeiten in der Praxis vorgestellt.

Das ist ein kostenloses Buch, wie der Titel schon sagt, wo ich so meine praktischen Erfahrungen mal runtergeschrieben habe.

Im Prinzip all das, was ich hier auch in den Podcast-Folgen gesprochen habe und ein bisschen mehr.

Wenn dich das interessiert, dann findest du den Link dazu in den Shownotes.

In der heutigen Folge möchte ich gerne ein Thema aufgreifen, das in einer sehr schönen Mastodon-Diskussion aufgetaucht ist.

Nämlich, ganz grob gesagt, klassisches Projektmanagement wird immer benötigt, selbst wenn die Umsetzung des Projekts agil ist.

Bevor wir damit anfangen, aber ein bisschen Housekeeping.

Ich habe angefangen auf Mastodon jeden Freitag eine kleine Zusammenfassung zu schreiben zu den, ja ich sag mal Top-Themen aus der agilen Community.

Du findest das immer unter dem Hashtag AgilePulse.

Auch den Link zum Hashtag, den packe ich dir in die Shownotes.

Ja, wenn dich das interessiert, schau da gerne rein.

Gut, dann würde ich sagen, wir steigen mal in das Hauptthema ein.

Also, es gab im Prinzip durch eine Diskussion übrigens unter anderem angeschubst durch genau diese Wochenzusammenfassung AgilePulse.

Ja, eine Diskussion, wo es zwei grundsätzliche Positionen gab.

Angefangen hat das Ganze über das Thema Gantt-Diagramm, aber schlussendlich meiner Meinung nach ging es in der Diskussion darum, dass es auf der einen Seite die Position gab, egal welches Projekt du machst und egal wie du es umsetzt, es braucht immer ein Projektmanagement darüber, das den Entwicklungsprozess steuert.

Wir brauchen Ziele, wir brauchen einen Plan und entsprechend eine Steuerung.

Gantt-Diagramm ist halt ein Teil dieser Steuerung.

Also im Gantt-Diagramm plane ich ja Phasen des Projekts und definiere entsprechend auch, welche Phase abgeschlossen werden muss, damit die nächste Phase anfängt und dann stehen horizontale Balken, die zeitlich voneinander abhängen.

Das sieht halt sehr nach Wasserfall aus und das ist es ja im Zwerhwitz-Fall auch.

Ich war eher auf der Seite zu sagen, naja, Agilität, agiles Arbeiten, auch hier wieder, egal welche Methode, beinhaltet schon Projektmanagement und wir reden auf zwei verschiedenen Ebenen.

Wir können nicht planen, da komme ich gleich auch nochmal drauf, warum das nicht möglich ist, wenn wir in einem bestimmten Projektumfeld sind.

Und ja, wie gesagt, also die Meinungen waren sehr klar auf beiden Seiten und ich will gerne mal erläutern, warum ich glaube, dass es eben kein klassisches Projektmanagement braucht, wenn wir denn in einem bestimmten Umfeld sind.

Ja, und um das ein bisschen besser zu erläutern, fange ich mal an, jetzt Modelle zu benutzen.

Und ein Modell ist eben die Stacy Matrix.

Das zeigt eigentlich ganz gut, dass es verschiedene Arten von Projekten gibt.

Wie können wir uns die Stacy Matrix vorstellen?

Wir haben auf der Y-Achse Anforderungen und die Anforderungen, die unten auf der Y-Achse sind, die sind relativ klar und je weiter ich nach oben komme, desto unklarer werden die Anforderungen.

Auf der X-Achse habe ich den Lösungsweg und auch da ist es so, ganz links ist der Lösungsweg sehr klar und je weiter ich nach rechts komme, desto unklarer wird der Lösungsweg.

Ich teile also meine Projekte ein in zwei Dimensionen, die Klarheit der Anforderungen und die Klarheit der Umsetzung dieser Anforderungen, also des Lösungswegs und dann habe ich ganz unten links einfache Projekte.

Da ist die Anforderung klar und der Lösungsweg klar.

Keine Ahnung, einfachstes Beispiel, ein Logo soll getauscht werden auf einer Webseite.

Und je weiter ich jetzt nach rechts oben in diesem Diagramm komme, desto schwieriger, sage ich jetzt erstmal für Allgemeinheit, werden diese Projekte.

Also das geht dann, wie gesagt, von ganz einfach über kompliziert zu komplex bis hin ganz oben rechts.

Die Anforderungen sind unklar und der Lösungsweg ist unklar, sagt man sehr oft, ins Chaotische.

Und wenn man sich dieses Bild vor Augen führt, das ist im Podcast immer ein bisschen schwer, dann sieht man, dass es eben unterschiedliche Arten von Projekten gibt.

Vielleicht gibt es Projekte, wo die Anforderungen nicht ganz klar sind, aber der Lösungsweg ist jetzt nicht komplett unklar.

Wir haben Ähnliches vielleicht schon mal gemacht und können schon ableiten, okay, dann wird es ungefähr in diese Richtung gehen.

Und dann müssen wir natürlich den Weg gehen, dass wir sagen, okay, wir müssen uns den Lösungsweg Schritt für Schritt erarbeiten.

Und das ist was ganz anderes, als wenn die Anforderung klar ist und der Lösungsweg klar ist.

Das klassische Projektmanagement kommt ja ganz ursprünglich mal aus dem Schiffsbau.

Bau ein Schiff, das habe ich vielleicht sogar schon mal gebaut.

Dann plane ich dieses Schiff, was es alles können soll.

Dann plane ich, wie es gebaut wird und welche Materialien ich brauche.

Und anhand dieser Fakten kann ich im Prinzip ermitteln, wann ist das Schiff fertig.

Und dann ermittle ich einen kritischen Pfad.

Also was auf all den Dingen, die wir tun müssen, sind die kritischen Dinge, die vielleicht am längsten dauern.

Und kann jederzeit gucken, bin ich noch innerhalb dieses kritischen Pfads.

Zeitlich gesehen zum Beispiel.

Und dann kann ich, wenn ich feststelle, ich hänge im Zeitplan, sagen, okay, ich besorge mir drei mehr Leute, die Metallplatten an die Schiffswand schweißen können.

Und dann sind wir schneller.

Und da ist ein bisschen die Voraussetzung drin, dass diese Schweißtätigkeit ja alle gleich gut sind im Schweißen.

Und dann kann ich so ein Projekt auf dieser Ebene managen.

Ich würde aber sagen, so ein Schiffsbau, so wie ich jetzt das gerade skizziere, da ist die Anforderungen eher klar und auch der Lösungsweg eher klar.

Wir sind also eher unten links in dieser Stacy-Matrix.

Wenn wir eine Softwareentwicklung haben, ist es oft so, dass selbst die Anforderungen nicht klar sind.

Viele behaupten, die sind klar.

Aber wir alle wissen, während wir dann entwickeln, ja, kommen wir in den Dialog, wir denken mehr über das Projekt nach.

Und dann stellen wir fest, ah, die Anforderungen waren nicht gut.

Wir brauchen eine andere Anforderung oder eine Veränderung.

Und das gleiche gilt dann für den Lösungsweg.

Und das bedeutet eben, ganz fundamental, je nachdem, in welchem Umfeld ich arbeite und was ich mache, Unterschiede in Projekten.

Und das zeigt eben die Stacy-Matrix sehr schön.

Und in der Mastodon-Diskussion hat mir diese Ebene halt einfach gefehlt.

Wir sagen einfach Projekt, aber wir kommen gar nicht zu der Definition, was ist ein Projekt und ganz konkret, in welchem Umfeld ist dieses Projekt.

Der nächste Punkt, den man machen kann, da hilft uns dann das magische Dreieck im Projektmanagement.

Wieder ein ganz schönes Bild.

Ich versuche das auch hier einmal zu erklären.

Wir haben in einem Projekt eigentlich drei Parameter, vielleicht einen versteckten vierten, der das Projekt bestimmt.

Das ist die Zeit, die mir zur Verfügung steht.

Das Budget, das mir zur Verfügung steht.

Und der Projektumfang.

Welche Features brauche ich für das Projekt?

So.

Und der versteckte Parameter ist vielleicht die Qualität.

Also, man kann sich schon vorstellen, je nachdem, wie man jetzt Zeit, Budget und Umfang verändert, kann unter anderem zum Beispiel auch die Qualität leiden.

Und im klassischen Projektmanagement wird davon ausgegangen, dass Zeit und Budget fest sind.

Also, in sechs Monaten mit so und so viel tausend Euro muss das Projekt fertig sein.

Und wir haben als einzige Variable den Umfang.

Also, was alles machen wir?

Und die Idee ist zu sagen, wir planen mit den verbindlichen Elementen Zeit und Budget, welcher Umfang jetzt möglich ist und schreiben das runter.

Dann entsteht eben ein Pflichtenheft und der Auftragnehmer schreibt sein Lastenheft dazu.

Und die Idee ist so lange gut, wie wir in der Stacy Matrix, Matrix, ja, ich sag mal eher unten links sind, in dem klareren Umfeld.

Und was auch in solchen Projekten natürlich immer passiert, auch da wird oft festgestellt, Mist, die Anforderung ist doch anders, als wir gedacht haben.

Und dann kommt man in solchen Projekten sehr schnell in so einen Change-Prozess.

Ja, wir brauchen doch mehr Geld, ja, wir brauchen doch mehr Geld und Projekt wird zeitlich verzögert und so weiter und so fort.

Das ist diese, ja, das klassische Dreieck.

Im agilen Arbeiten dreht sich dieses, ja, magische Dreieck jetzt um.

Wir stellen das auf den Kopf.

Wir stellen das auf den Kopf.

Zeit, also zum Beispiel Iteration und Budget, zum Beispiel in Sprintgrößen oder Teamgrößen, die sind jetzt fest.

Variabel ist jetzt der Umfang.

Wir fragen nicht, wie lange brauchen wir für all diese Features.

Wir fragen, welches wertvollste Feature können wir in der vorgegebenen Zeit und mit dem gegebenen Team umsetzen.

Und wir schneiden die Features so, dass die wichtigsten auf jeden Fall in diesem Rahmen erledigt werden.

Und wir akzeptieren, dass wir auf diesem Weg Dinge dazulernen und die Reihenfolge der Features und, ja, ich sag mal, der Gehalt der Features sich natürlich ändern kann.

Das ist halt einfach ein ganz anderer Ansatz als im klassischen Projektmanagement.

Und der ist auch nötig aufgrund, ja, des Projektumfelds, ne.

Verweis nochmal auf die Stacy Matrix.

Der Lösungsweg ist vielleicht nicht so klar.

Die Anforderungen sind vielleicht nicht so klar.

Vielleicht sogar eine Kombination aus beiden.

Und dann ist dieses Vorgehen eben besser.

Und wenn ich so ein Vorgehen habe, kann ich nicht am Anfang vom Projekt ein Gutschart malen.

Wie auch, ne.

Und ich glaube, das ist so ein ganz großer Teil in dieser Diskussion gewesen.

Ja, und wie gesagt, ich wollte da einmal drauf eingehen.

Ich denke, das ist ganz nett, da nochmal zu reflektieren und drüber nachzudenken.

Ich denke einfach, wenn man ein Projekt vor sich hat, muss man halt tatsächlich gucken.

Und ich glaube, das tun einfach auch ganz viele aus dem Bauch heraus allein schon.

Was ist das für ein Projekt?

Ist das einfach?

Ist das komplex?

Da hilft uns dann die Stacy Matrix.

Uns sind das ein bisschen, ja, als Modell geistig nochmal, ja, präsent zu machen.

Und dementsprechend wählen wir unser Vorgehen.

Und wir wissen aufgrund des magischen Dreiecks, welche Parameter wir zur Verfügung haben.

Ja, um eben das zu erfüllen, was die Anforderung ist.

Oder um das zu erfüllen, was der Kunde wirklich braucht.

Einen echten Wert eben zu schaffen, ne.

Ja, und das soll es dann tatsächlich für heute auch gewesen sein.

Kurze Knapp wie immer.

Ich hoffe, dir hat das hier gefallen.

Wenn dir das gefallen hat, freue ich mich darüber, ja, wenn du das teilst, ne.

Wenn du Kolleginnen oder Kollegen Bescheid sagst, hier, hör da mal rein, das ist ganz interessant.

Wenn du es auf Social Media teilst, das wäre alles ganz toll.

Und ja, wie gesagt, das soll es dann für heute gewesen sein.

Habt noch eine ganz tolle Woche.

Und bis zum nächsten Mal bei No Bullshit Agile.

Bis zum nächsten Mal bei No Bullshit Agile.

Vielen Dank.