Was ist agiles Projektmanagement?

Was ist agiles Projektmanagement?

Im Internet habe ich viel Quatsch darüber gelesen, was agiles Projektmanagement sein soll. Viele vertun sich und meinen, damit sind agile Frameworks gemeint wie zum Beispiel Scrum. Wieder andere meinen, agiles Projektmanagement gibt es gar nicht. “Also entweder wir machen die Entwicklung agil oder wir benutzen klassische Methoden wie zum Beispiel PMI”. Schwarz oder Weiß und Grau gibt es nicht.

Und dann habe ich einen Artikel in einem großen deutschen Magazin im Internet gelesen, welches auch vom Top-Management regelmäßig gelesen wird. Der Artikel kam im August 2020 raus mit dem Thema „Das Wichtigste, was Sie über agiles Projektmanagement wissen müssen“ und dort habe ich mal 3 kurze Ausschnitte mitgeschrieben. Die würde ich dir gerne mal vorlesen.

1. „Das Wörtchen „agile” entstammt dem relativ weiten Feld des Projektmanagements und bezeichnet eine Methode desselbigen.“
Das stimmt natürlich nicht. Agile beschreibt ein Mindset und hat absolut gar nichts mit Projektmanagement zu tun.

2. „Die erste tiefgehende Diskussion zum Thema Agile wurde in den 1970er Jahren von Winston Royce angestoßen.“
Winston Royce? Winston Royce gilt als der Erfinder des Wasserfallmodells.
 
3. „Was sind die Nachteile von Agile? Es fokussiert sich nicht auf die User Experience.“
Das ist natürlich totaler Quatsch, weil gerade der Kunde im Mittelpunkt bei dem Ganzen steht. Das erste Prinzip vom Agilen Manifest lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.“
 
Und daher dachte ich mir, ich mache darüber mal eine Folge, auch um mir selbst mal Klarheit zu verschaffen bei der ganzen Abgrenzung. Das heißt, wir schauen uns das Wort „agile“ an. Wo kommt das her? Warum heißt das so? Und was ist agiles Projektmanagement?
 
Fangen wir an mit „agile“. Also, wo kommt das her?

Was ist Agilität?

2001 haben sich 17 clevere Entwickler und Methodengurus für ein Wochenende in Utah getroffen in den USA und wollten dort Skifahren, essen, trinken und über Best Practices bei der Softwareentwicklung sprechen. Ich glaube, da ist auch schon der erste Unterschied zum Skiurlaub mit der Familie. Ziel war es, ein gemeinsames Verständnis auszuarbeiten, wie man grundsätzlich Softwareentwicklung machen sollte. Das heißt, weg von den schwergewichtigen Prozessen und dicken Lastenheften und hin zu leichtgewichtigen Prinzipien, bei denen alle 17 Entwickler übereinstimmen. Viele von denen haben später auch gesagt, die hätten nie gedacht, dass man sowas aufstellen kann mit 17 Leuten, aber nach 2 Tagen Diskussion wurde daraus dann wirklich das Manifest für agile Softwareentwicklung. Und da sieht man ja schon: Da ist das Wort „agil“ drin. Und was bedeutet das Manifest für agile Softwareentwicklung? Darin sind 4 Werte und 12 Prinzipien definiert.

Woher kommt das Wort “agile”?

In einem amerikanischen Podcast habe ich eine Interviewfolge mit Mike Beedle gehört. Mike Beedle war einer von den 17 Mitzeichnern von diesem Agilen Manifest und der war auch stark an der Konzeption von Scrum beteiligt damals. Und der erinnert sich an das Jahr 2001 zurück, als sie diese 2 Tage in dem Skiurlaub waren. Und er hat nur beschrieben:

• Warum heißt es eigentlich nicht „adaptive“? Dieses Wort war schon für eine der Arbeiten von Jim Heisman vergeben.
• Warum nicht „essential“? „Essential“, meinte er, klang zu angeberisch für alle.
• Dann war ein Vorschlag „lean“. „Lean“ war schon vergeben durch „Lean Production“, Toyota. Wahrscheinlich von Toyota auch geclaimt.
• Dann war ein Vorschlag „lightweight“, aber dafür hat einfach niemand gestimmt. Das wollte keiner.

Und Mike Beedle hatte die Idee mit dem Wort „agile“ und er schreibt, das Wort „agile“ kam ihm in den Sinn, weil er ein Buch zu Hause hatte mit dem Titel „Agile Competitors and Virtual Organizations“.

Also noch mal zusammengefasst: Wenn wir von „agile“ sprechen, dann steht das für die Werte und Prinzipien des Agilen Manifests. Und das bedeutet nicht: Scrum, Kanban, kennt keine Product Owner, kein Timeboxing, sondern es sind 4 Werte und 12 Prinzipien. Wenn dich das Agile Manifest interessiert, dann höre doch mal in die Folge 6 und Folge 7 rein. Dort haben wir die wichtigsten Erfolgsprinzipien anhand von Fußball erklärt.

Was ist Agiles Projektmanagement?
 

OK, und jetzt kommen wir zu dem Wort „Projektmanagement“. Und dazu würde ich gerne mal beispielhaft überlegen: Wie kommt man grundsätzlich von der Idee zur Auslieferung bei einem Kunden?

Also als erstes muss ein Kunde eine Idee haben, was er machen möchte, dann findet der uns als Dienstleister irgendwann und nimmt Kontakt mit dem Vertrieb auf.

• Als nächstes erklärt der Kunde seine Wünsche, Ziele, grobe Anforderungen, Epics, und bis wann das Ganze fertig sein soll und wie teuer das alles sein soll maximal.
• Dann wird darauf ein Auftragsklärung gemacht, das heißt, intern muss abgestimmt werden:
• Hätten wir überhaupt Kapazität?
• Bis wann ist das fertig?
• Schätzungen, Angebotserstellung und Vertrag wird geschlossen.
• Jetzt müssen wir einen Mitarbeiter dafür abstellen – muss ja auch nicht Vollzeit sein, aber es muss einen Mitarbeiter geben, der kontinuierlich für den Kunden als SPOC bereitsteht, als Single Point of Contact. Und der muss diese Anforderungen iterativ bearbeiten oder zumindest weiterverteilen in die Teams, dass die etwas damit machen.
• Dann müssen die Anforderungen iterativ realisiert werden. Spätestens da kommt dann auch wieder das agile Framework ins Spiel, sowas wie Scrum zum Beispiel, und
• dann wird dem Kunden die fertige Software iterativ gezeigt und
• zum Schluss wird fertiggemeldet, Abschlussarbeiten werden durchgeführt und Champagner wird getrunken.

Jetzt könnte man sich natürlich fragen: Wo sind hier Projektmanagement-Aufgaben?

Das kann doch eigentlich alles am Anfang der Vertriebler, dann der Product Owner, dann Realisierung durch das Team und zum Schluss wieder der Product Owner machen.

Schauen wir uns mal beispielhaft an, was neben der reinen Softwareentwicklung noch alles für Tätigkeiten anfallen.

• Wer plant und kontrolliert das begrenzte Budget? Es können zum Beispiel Ausgaben anfallen für Test-Hardware, die beschafft werden muss, Lizenzen, AGBs und Datenschutzerklärungen mit Anwälten oder Medieninhalte, wie zum Bespiel die Erstellung von Videos, Zulieferung von fremden Subunternehmen. All das muss budgetiert werden, also geplant werden, und man muss darauf achten, ob man auch in dem Budget bleibt. Dann:
• Wer plant und kontrolliert die Zeit, wenn es einen Endtermin gibt? Und den kann es durchaus geben, auch in der agilen Softwareentwicklung. Wir erinnern uns beispielsweise an DSGVO. Da gab es einen harten Stichtag und an dem Tag musste alles umgestellt werden. Also auch in der agilen Softwareentwicklung gibt es harte Deadlines. Und jetzt schreiben ganz viele Agilisten, dass bei agiler Softwareentwicklung Geld und Zeit fix sind und alles über den Scope geregelt wird.

Das Dreieck im agilen Projektmanagement

Es gibt da sogar das agile Projektmanagement-Dreieck, was umgedreht ist, und diese beiden Punkte sind fix gemacht. Und das ist Quatsch, weil neben der Softwareentwicklung auch noch Kosten für ganz andere Dinge anfallen. Und es könnte auch durchaus sein, dass der Kunde sich während der Entwicklung noch viel mehr Features wünscht, die Deadline trotzdem bleibt und warum sollte man sich jetzt eingrenzen und sagen: „Nein, können wir nicht. Das ist fix bei Agil“? Warum? Wir können doch zwei Entwickler temporär hinzukaufen. Gerade im Nearshoring zum Beispiel: Da kann man innerhalb von 10 Tagen 2 weitere Entwickler und einen Tester an Bord holen. Und wenn ich das von Beginn an einschränke, dann verschenke ich Potenzial. Weitere Beispiele, die nicht direkt etwas mit der Produktentwicklung zu tun haben, aber trotzdem häufig anfallen, wären zum Beispiel:

• Wer steuert die Vertragsgestaltung?
• Wer organisiert die Rechtssicherheit?
• Was ist mit Datensicherheit und Datenschutz?
• Müssen wir vielleicht Change Management mit einbeziehen?
• Wer bindet den Einkauf ein?
• Und zum Schluss: Wer organisiert den Betrieb?Diese Fragen müssen auch alle beantwortet werden.
   
  Und hier kommt für mich agiles Projektmanagement ins Spiel. Und was ich darunter verstehe, sind 3 Dinge:

1. Ich verwende ein Projekt als Container von der Idee bis zur Abnahme. Was heißt „Container“? „Container“ heißt: Ich gehe zu Beginn die Wissensbereiche von dem klassischen Projektmanagement durch und überlege, wo und wie diese abgedeckt sind. So wie eine Checkliste. Also zum Beispiel Stakeholder-Analyse: Es kann ja sein, dass ich gar nicht nur einen Product Owner habe, sondern ich brauche Zulieferungen von 3 verschiedenen Product Ownern. Dann Projektauftrag mit Zielen. Also ich möchte in irgendeiner Form etwas Schriftliches haben: Wann bin ich erfolgreich gewesen? Bis wann muss ich was tun? Und das kann klassisch die Project Charter sein, also der Projektauftrag mit den Zielen, das kann aber auch zum Beispiel eine Produktvision sein. Dann das Thema Scope Management: Erstelle ich einen klassischen Projektstrukturplan? Auch da könnte ich sagen, die Epics sind zum Beispiel die Arbeitspakete. Oder gibt es ein Backlog? Also wichtig ist, dass ich alle Wissensgebiete einmal abklappere wie eine Checkliste und dann schaue: Habe ich nichts vergessen!
2. Ich habe eine Person, die die genannten Themen koordiniert und die der “Single Point of contact” Richtung Kunde ist. Ich nenne die den „Projektleiter“.
3. Die Entwicklung verläuft iterativ, das heißt, wir liefern kontinuierlich zum Kunden raus und können flexibel auf Änderungen reagieren.

Zusammenfassung, was agiles Projektmanagement für mich bedeutet

1. Ich habe ein Projekt und nutze dies wie einen Container – von der Idee bis zur Abnahme.
2. Der Projektleiter ist der Single Point of Contact zum Kunden.
3. Der Kern der Softwareentwicklung verläuft iterativ.

Dann spreche ich von agiles Projektmanagement.

Wenn man sich mal davon trennt, dass nur agil gut oder schlecht ist, oder nur traditionell, oder es wird auch „predictive“ gennant, gut oder schlecht ist, und man für das Beste aus beiden Welten offen ist, dann kann man damit maßgeschneiderte Lösungen finden.

Das Ganze hat nur ein Problem: Man braucht eine Menge Erfahrung und Fingerspitzengefühl, was man alles vom traditionellen Projektmanagement in diesen Projekt-Container mit reinpackt.