Folge 6 von Projekte – Spielend erfolgreich. Diesmal geht es um eine Scrum Simulation und Agile Games oder genauer um:

• Scrum und den Scrum Prozess
• Eine Scrum Simulation
• Agile Spielekultur
• Spielesammlungen
• Planning Poker

Hier noch die Links zu den vorangehenden Folgen (1), (2), (3), (4) und (5).

Seit langem mal wieder ein reinrassiger Projektmanagement Beitrag. Jüngst bin ich über einen Artikel von Ron Quartel auf medium gestolpert: „Why Story Pointing Needs to Die„

Wortwörtlich ins Auge gefallen sind mir vor allem die beiden Zitate in der Illustration:

„I may have invented points. If I did, I´m sorry now.“ – Ron Jeffries

„Velocity is killing agility!“ – Jom Highsmith

Vor allem das zweite spricht mir aus der Seele. Das Konzept der Velocity wollte mir nie so recht eingehen.

Also nicht, dass ich nicht verstanden hätte, worum es dabei geht und wie es funktioniert, aber Velocity-Betrachtungen laufen meinem Verständnis von Projekten fundamental entgegen.

Projekte sind einzigartige, komplexe Herausforderungen und Velocity zielt auf die Optimierung einer gleichmäßigen und prognostizierbaren Teamauslastung. Finde den Fehler!

Klar, wenn sich ein Projekt an das andere reiht, dann können wir nicht immer auf 120% fahren. Das macht uns kaputt. Aber die Vorstellung Projektfortschritt sei ein kontinuierlicher Prozess ist schon schizophren, denn sind nicht Disruption und sprunghafte Entwicklungen gerade in komplexen Projekten zu beobachten?

Nichts gegen eine Auslastungsoptimierung. Sie sichert Effizienz. In Projekten steht aber vor der Effizienz vor allem die Effektivität. Erreichen wir überhaupt, was wir erreichen wollen?

Effizient Scheitern ist keine Option!

Ich will das Konzept Velocity gar nicht in Frage stellen. Dafür gibt es sicher Anwendungsfälle, aber eher weniger in Projekten.

Bevor ich nun wieder in die Schublade des traditionellen Projektmanagements gesteckt werde, will ich dem schon vorab widersprechen. „Gutes“ Projektmanagement hatte immer schon agile Züge, denn nur mit einer solchen Einstellung kann man komplexen Anforderungen gerecht werden. Das hat aber nur bedingt mit der Umsetzung agiler Projektmanagement-Ansätze zu tun. Die großen Stärken von beispielsweise Scrum sind für mich, die Stärkung des Teams, Facilitation (in der Rolle des Scrum Masters), die intensive Einbindung der Anforderungsseite (Product Owner) sowie die Etablierung von Lernprozessen und Kommunikation. Diese Dinge helfen aber in jeder Form des Projektmanagements weiter und erhöhen unsere Erfolgswahrscheinlichkeit. Lediglich formale Implementierungen von Scrum sind wie alle halbherzigen Projektmanagementimplementierungen zum Scheitern verurteilt.

Überbewertete Konzepte gibt es aber auch im traditionellen Projektmanagement. Mein „Lieblingsbeispiel“ hier ist der Earned Value, also die laufende Quantifizierung des Projektfortschritts. Der bereits geschaffene Wert im Projekt wird kontinuierlich ermittelt. Ich halte diesen Ansatz für gefährlich. Er suggeriert, dass tatsächlich bereits ein Wert geschaffen wurde. Der Wert eines Projektgegenstandes ist mitunter aber digital zu sehen: Das fertige Produkt funktioniert oder funktioniert nicht. Zugegeben, die Argumentation ist stark vereinfacht. Vielleicht haben wir tatsächlich etwas gelernt oder es sind brauchbare Zwischenprodukte entstanden, gemessen an unserm Projektauftrag sind wir aber gescheitert. Als Gegenpol dazu gefällt mir hingegen die Idee des „Minimum Viable Product“, die zu einer Rückbesinnung und Ergebnisorientierung führt. Mit dem MVP ist ein Projekt zwar in der Regel noch nicht am Ziel, aber das Risiko des Scheiterns wird minimiert.

Alle Earned Value-Implementierungen, die ich in der Praxis gesehen habe, dienten – böse gesagt – auch eher der Befriedigung des Management Reportings, als dem Projekterfolg.

Auch wenn man mich vielleicht primär dem klassischen Projektmanagement zurechnen würde, so bin ich agilem Denken und agilen Methoden mehr als aufgeschlossen. Wer ein humanistisches Weltbild hat, hat auch mit den Idealen des Agilen Manifests kein Problem. Iterative Vorgehensweisen waren da, wo sie einsetzbar sind schon immer eine hervorragende Strategie um Risiken zu minimieren und Quick-Wins zu realisieren. An meine Grenzen stoße ich bei den verschiedenen agilen Frameworks aber an zwei Stellen:

1. Ihrer Ideologisierung
2. Der Formalisierung

Im ersten Punkt kommt es häufig zu dem Missverständnis, dass wer nicht „agil“ auf seinen Fahnen stehen hat, wohl auch agile Werte nicht teilt und unterstützt.

Im zweiten Punkt missfällt mir die idealtypische Formalisierung der Vorgehensweisen und Rollen in den agilen Frameworks. Wenn mein Kunde sich ebenfalls im Projektteam adäquat einbringt und idealerweise die Rolle des Product Owners einnimmt und ich eine offene und konstruktive Projektkultur habe, dann ist das ein Idealzustand, der in klassischen Szenarien ebenfalls hervorragend funktioniert, wenn dort die Rolle entsprechend beispielsweise im Anforderungsmanagement und in meinen Gremien besetzt ist und wahrgenommen wird. Erfolgsfaktor ist dann aber nicht das Framework, sondern die wahrgenommene Verantwortung und die gelebte (Projekt-)Kultur.

Ein Aha-Erlebnis hatte ich in der Lego for Scrum-Session von Tilman Moser auf dem PMCampRM. Tilman ließ uns in drei Scrum-Teams in drei Sprints an einer Lego-Stadt bauen. Ziel war Scrum „erfahrbar“ zu machen. Dadurch, dass das Spiel in einen Session-Slot gezwängt wurde, unterlag der Aufbau von Anfang an vielen Restriktionen und Abkürzungen. Schätzungen Retrospektiven kamen zu kurz und Tilman genoss es auch sichtlich seine Rolle als Product Owner in vollen Zügen auszureizen. Dieser nicht-ideale Aufbau mag Fehlentwicklungen im Verlauf erklären, ich halte ihn aber trotzdem für realistisch, weil wir auch in Scrum-Projekten nicht nur mit Gutmenschen zu tun habe, auch diese unter Stress und wandelnden Anforderungen, etc. stehen.

Bemerkenswert war, dass schon in diesem kleinen Aufbau die Gruppendynamik voll zuschlug und das leider nicht in dem Sinne, wie es Scrum vorsieht, sondern im schlimmsten tayloristischen Sinn. Dabei hatten wir zufällig sogar einen ausgebildeten Scrum Master an Board, aber die Denk- und Verhaltensweisen in unserem kleinen Team erinnerten mich eher an die aus den Modellen der Akkord-Arbeit bekannte Phänomene, als an agile Ideale. Nicht wissend, was wir zu erwarten hatten, waren wir in der ersten Sprint-Planung sehr zurückhaltend. Als wir dann noch die ersten Missverständnisse mit unserem Product Owner hatten und auch unsere Möglichkeiten zur Kommunikation mit ihm innerhalb der Sprints gar nicht genutzt haben (Es waren ja nur 5 Minuten je Sprint, aber trotzdem: Wir haben es nicht getan!). Als er uns dann – mit Genuss (Schweinebacke!) am Ende des ersten Sprints auflaufen ließ, schalteten wir sofort auf Abwehrverhalten um: Bloß keine Blöße geben, Preise nicht verderben,… Ganz 1.0 halt.

Jetzt war der ganze Aufbau „nur“ ein Spiel unter zugegeben ungünstigen Voraussetzungen, aber ich habe dabei mit Schrecken meine Vorurteile bestätigt gefunden. In einer nicht idealen Welt stoßen auch agile Frameworks an ihre Grenzen.

Ein paar aktuelle Beiträge für PM-Interessierte:

Marcus Raitner hat auf seinem Blog Führung-erfahren eine kleine Reihe zum Thema „Projektplanung 101“ gestartet. Bisher erschienen sind Arbeitspakete richtig schneiden, Verknüpfungen setzen, Ressourcen zuteilen und Meilensteine. Jetzt müssen wir Marcus nur noch motivieren, die Inhalte auch in openPM einzuarbeiten…

Kommunikation ist DER Erfolgsfaktor in Projekten, nur vergessen wir das immer wieder. Reinhold Wagner zitiert im GPM-Blog eine aktuelle Studie zur Projektkommunikation und philosophiert über unser Fehlverhalten wider besseres Wissens in der Kommunikation.

In der Computerwoche gibt es einen Aufruf zum Tabubruch: Mehr Mut zum Projektabbruch. Thomas Brustbauer fordert dort eine entsprechende „Fehler-Kultur“.

Über Geschmack lässt sich streiten, aber wem es gefällt: SCRUM-Poster im Anime-Stil.

In eigener Sache:
Nachdem es früher hier schon eine lose Reihe VisualPM gab, die sich mit Visualisierungstechniken im Projektmanagement beschäftigt und zuletzt der Beitrag zur openPM-Canvas auch wieder sehr gut in diese Reihe gepasst hätte, werde ich in nächster Zeit die VisualPM-Reihe mit weiteren Artikeln wieder aufleben lassen.

Unter diesem Titel setzt sich ein Beitrag auf den Webseiten der IG Metall mit dem Wandel in der ITK-Industrie auseinander und bemängelt, dass der Mensch dabei auf der Strecke bleibt. Die Rede ist von IT-basierten Lean-Konzepten für die Kopfarbeit und dabei wird alles in einen Topf geworfen: Agile Methoden, Mobiles Internet, Intelligente Netze, Cloud Computing, Social Media, Crowd Working. Beispiele werden u.a. von HP, Nokia Siemens Networks, IBM und SAP angeführt.

Aus gewerkschaftlicher Sicht wird bemängelt, dass die Global Player in diesem Umfeld verstärkt auf Offshoring, Outsourcing, transnationale Projekt- und Teamarbeit sowie Crowd Working-Strategien setzen.  In kleineren Betrieben würden sich die Arbeitsbedingungen u.a. aufgrund von Fachkräftemangel bei zunehmender Arbeitsbelastung verschlechtern. Als Risiken der Veränderungsprozesse werden attestiert:

Prekäre Beschäftigungsformen wie Leiharbeit und Scheinselbstständigkeit nehmen ebenfalls zu. Damit verbunden sind häufig wachsende gesundheitliche Belastungen, allgemeine Verunsicherung und psychischer Druck in einem „System permanenter Bewährung“ (Boes/Bultemeier).

Das so gezeichnete Bild entspricht so gar nicht den idealistischen Vorstellungen agiler Methoden. Liegt doch beispielsweise dem agilen Manifest ein ganz anderes Menschenbild zugrunde.  Jurgen Appelo würde das oben beschriebene Szenario als ein Management 2.0 bezeichnen, die Umsetzung von Methoden wie Leanmanagement, TQM & Co in hierarchischen Systemen. (Dabei liegt eigentlich auch dem Leanmanagement ein ähnliches Menschenbild zugrunde, das in der Verkürzung aber auf der Strecke bleibt und mittlerweile fast schon in Vergessenheit geraten ist.) Jurgen postuliert stattdessen ein Management 3.0 (Amazon Affiliate Link) mit der Einführung agiler Methoden  und der Abkehr von hierarchischen Systemen.

Bei agilen Methoden liegt die Betonung i.d.R. auf Selbstorgansiation und Selbstbestimmung und eine mögliche Überforderung á la Boes/Bultemeier wird nicht weiter diskutiert. Allerdings reagieren agile Vertreter auf die Verknüpfung agiler Methoden mit klassischem Optimierungsdenken, wie bei Wolfram Müllers High-Performance Projektmanagement auf openPM oder bei seinem Beitrag auf dem PM-Camp in Dornbirn durchaus dünnhäutig. Offenbar sieht sich die Zunft gerade nicht gerne als neues Produktionsmodell.

Persönlich missfallen mir die idealisierten Rahmenbedingungen agiler Ansätze, weil sie häufig utopisch sind. Wenn ich den idealen Product Owner, am besten gleich noch auf Kundenseite, von Anfang an engagiert und eingebunden in meinem Projekt habe, dann sind das Voraussetzungen, die auch jedem klassischen Projekt gut tun würden, die nur in der Realität nicht immer anzutreffen sind. Erfrischend hier wieder Jurgen Appelo, der jüngst in einem Blogbeitrag das imperfekte agile Vorgehen postuliert: Don´t let Scrum make you fragile. Er plädiert dafür Methoden wie Scrum nicht Buchstabe für Buchstabe umzusetzen, sondern auch Platz für Variabilität, Unsicherheiten und Überraschungen zu lassen. Ich fürchte nur, dass deutsche Gewerkschaften dies der arbeitenden Bevölkerung nicht zutrauen und deren permanente Überforderung anprangern werden…

Peter Addor nimmt sich der Kritik an den hahnebüchenen Kostenschätzungen von Großprojekten an und weist treffend darauf hin, dass es bei den veröffentlichten Kostenschätzungen sich weniger um knallharte Planungsgrundlagen geht, sondern vielmehr um das Verkaufen eines Projekts.

Eberhard Huber greift das Modell der Circles aus Google+ auf und überträgt die Metapher auf die Projektarbeit. Sein Fazit: „Die Bildung von passenden Kreisen ist für mich eine zentrale Aufgabe in der Projektarbeit. “

Im Projektcoaching geht es bei Marcus Raitner weiter mit den Beiträgen:
20 – Legehennen
21 – Rollenwechsel
22 – „Richtige Arbeit“
23 – Arbeit verteilen

In diversen Blogs (z.B. bei PROJEKT-LOG) machen gerade die Links zu den Videos von Jeff Summerland und Ken Schwaber über Scrum auf der ESE Conference 2011 die Runde.

A pro pos Scrum: Andreas Heilwagen vergleicht den aktuellen Scrum Guide von Schwaber/Summerland mit der vorangegangenen Version. Hier, hier und hier.

Last but not least die Liste der Top 21 Buchempfehlungen für Projektleiter bei Stefan Hagen. Auffallend dass klassische Lehrbücher fehlen und vor allem Tom DeMarco die Liste dominiert. Streng genommen sind es eigentlich auch nur 20 Buchempfehlungen, denn „Wien wartet auf dich“ (Nr. 6) von DeMarco/Lister ist lediglich die deutsche Ausgabe von „Peopleware“(Nr. 13).

Sandy Walsh ist ein Vertreter agiler SW-Entwicklung und setzt sich (trotzdem) kritisch mit agilen Methoden auseinander. Abgesehen davon, dass es ihn nervt, dass z.B. in SCRUM alles einen neuen Namen bekommt (requirements = stories; „friggin‘ Scum wants to rename everything“), kritisiert er das starre Timeboxing und plädiert stattdessen für die verstärkte Anwendung des Pull-Prinzips á la KANBAN. Auch die super-feine Planungsgranularität in den Sprints stellt er in Frage. Yep, kaum wo wird so viel und so granular geplant, wie bei den Agilen.

Und wieder einmal ein SAP-Monster-Projekt mit Schwierigkeiten. Diesmal bei der US Army. Naiv allerdings der Versuch der Computerwoche eine Stellungnahme der SAP hierzu zu erwarten. Man könnte ja auch Microsoft als Hersteller von Word über Schreibblockaden befragen.

Vielleicht sollten wir den VisualPM hier wieder aufleben lassen… Pawel Brodzinski plädiert für die Visualisierung, aber warnt uns davor zu sehr auf spezifische Tools zu setzen.

Die Auftragsklärung ist elementare Voraussetzung für den späteren Projekterfolg, Andreas Heilwagen hat hierzu das Projektauftrags-Template auf Unlocking-Potential aktualisiert. Zum Download dieses und weiterer Templates geht es hier lang.

• Matthias von bwl zwei null hat im Socialmedia-Blog aktuelle Zahlen zur Nutzung von Social Media in Deutschland ausgegraben.
• Statt sich mit Tools for Fools auseinanderzusetzen, beschäftigt sich Stefan Roock mit der existentiellen Frage: „To Tool or Not to Tool?“.  In diesem Zusammenhang ist es schon beinahe nebensächlich, dass er sich dabei mit dem Tooleinsatz bei Scrum beschäftigt. Die Frage sollte auch ansonsten viel öfter gestellt werden.
• Die Computerwoche über ByoD (Brind your own Device) in Unternehmen.
• Nutzlose Vorratsdatenspeicherung: Eine Studie (via Golem) belegt mal wieder, dass nicht alles was technisch möglich ist, auch wirklich erfolgreich ist. Manches ist auch nur teuer und die Missbrauchsdebatte über solche Datenpools wird allzu schnell übergangen.

Andreas Heilwagen meldet sich zurück mit den (englischen) SCRUM patterns. Die auf seiner Seite schon heute vorhandenen Beschreibungen zu Standards und Methoden werden künftig also um das Thema Scrum erweitert.

In Marcus Raitners Reihe Projektcoaching sind die Folgen: 11 – Änderungsmanagement, 12 – Besprechungen und 13 – Berichtswesen erschienen.

Und noch einmal Marcus, der via XING dazu auffordert an openPM, einer freien Plattform für Projektmanager mitzuarbeiten. Die Vision/erste Spek entsteht online und jeder kann mitschreiben.

Stefan Hagen philosophiert über PM-Systeme und stellt dabei treffend fest, dass in der Praxis Projektmanagement häufig isoliert und nicht im Gesamtkontext des Managementsystems gesehen wird.

Kennen Sie das leidige Thema Projektmanagement- und Koordinierungsaufwand in einem Projekt?

Aus eigenen Projekten kenne ich entsprechende, meist politisch geführte Diskussionen („Was? So viel Aufwand für unproduktive Tätigkeiten?“) mit den Stakeholdern, die dann meist darauf rauslaufen, dass für diese Tätigkeiten pauschal 10-15% des Gesamtaufwands im Planungsansatz akzeptiert werden – unabhängig vom tatsächlichen Aufwand (ggf. werden Aufwände in anderen Arbeitspakete verschleiert oder dienen als Puffer).

Sicherlich hängt der Aufwand ganz entscheidend ab von der Komplexität der Anforderung und dem Projektumfang (Ist die komplette Planungsphase eingeschlossen oder nicht, wie stabil und detailiert sind die Anforderungen,…?) . Über entsprechdende Erfahrungswerte findet sich z.B. ein schon etwas älterer Thread im Forum des Projektmagazins.

Wenn ich mich mit agilen Methoden á la Scrum auseinandersetze fällt mir auf, dass dort der entsprechende Aufwand noch weit höher liegt, aber nicht explizit thematisiert wird. Er ist zum Einen in den Rollen des Scrum Masters und des Product Owners zu verorten, aber auch im Team im Rahmen der institutionalisierten Meetings, der Teambeteiligung an Sprintplanung, Aufwandsschätzung und Retrospektive. Ich kenne kaum klassische Projekte in denen so detailliert und granular geplant, geschätzt und getrackt wird, wie in agilen Projekten.

Sind agile Projekte also verschwenderischer? Oder sind sie vielleicht gerade deswegen produktiver?

Geht es in diesen Aufgaben (sofern man ein Projekt nicht nur bürokratisch verwaltet) nicht gerade um Kommunikation und Transparenz?

Sind nicht Kommunikation und Transparenz ein wesentlicher Erfolgsfaktor in jedem Projekt – egal ob klassisch oder agil?

Investieren agile Projekte an dieser Stelle schlichtweg cleverer?

Comments welcome!