24
Oct 2014
Meilenstein – Der Projektmanagement-Blog

Einmal Moderne und zurück

Japan, die unbekannte Welt: Zu Beginn meiner beruflichen Laufbahn hatte ich Gelegenheit, Augenzeuge einer der ersten großen west-östlichen Kooperationen zu sein. Mein deutscher Arbeitgeber kaufte von einem japanischen Wettbewerber eine komplette Technologie, ohne zu Beginn zu wissen, worauf man sich einließ, denn die japanische Kultur und Arbeitswelt war damals im Westen weitgehend unbekannt. Daher gewann man in den ersten Wochen der Zusammenarbeit überraschende und erstaunliche Erkenntnisse.

Anzeige

Beispiel: Einkauf von Maschinen. Unter den Managern der westlichen Hemisphäre gab es zwei Extrempositionen (und natürlich das ganze Kontinuum dazwischen):

I. "Wir kaufen immer die modernsten Maschinen" (Paradigma des Fortschritts: das Neueste ist immer das Beste)

II. "Wir kaufen dieselbe Maschine noch einmal" (Konservatives Paradigma: "better the devil we know")

In einem selbstbewussten und zukunftsorientierten High-Tech-Unternehmen genießen natürlich die Vertreter der Fraktion I das größere soziale Ansehen, auch wenn vielleicht die Fraktion II das Geld verdient, das man zur Finanzierung des Fortschritts benötigt.

Der dritte Weg

Und nun lernte man in Japan einen dritten Weg kennen, den fortschrittsorientierten Konservativismus:

III. "Wir kaufen, was wir kennen, und verbessern es so, dass es modernsten Anforderungen genügt" (Paradigma: "better the devil we know, but let's remove the diabolics")

Das hat gut funktioniert, und in den folgenden Jahren haben beide Seiten viel voneinander gelernt; auf dem Gebiet des Managements jedoch hat Fraktion I immer dominiert. Zwar haben nicht alle Firmen entsprechend gehandelt, aber die Fortschrittsprediger hatten wenigstens immer das Narrativ. Und wenn alle zehn Jahre "eine neue Sau durch's Dorf getrieben" wurde, sind viele mehr oder weniger blindlings auf den Zug, der manchmal auch aus Japan kam, aufgesprungen. Und natürlich, da der Sinn des jeweils neuen Hypes nicht immer hinreichend durchdacht wurde, mit den entsprechenden negativen Konsequenzen:

  • Lean Management war nicht mehr Vermeidung von Verschwendung, sondern eine Rechtfertigung von Personalabbau.
  • Business Process Reengineering ist schöpferische Zerstörung und Neuaufbau unter der Maxime völliger Kundenorientierung; vergaß man letztere, blieb es bei der Zerstörung.

Ob Six Sigma, Wow-Management oder wie sie alle heißen: stets hat es einige gute Umsetzungen gegeben, aber auch etliche Anläufe, die in der Methodik steckengeblieben sind, ohne wirklich Verbesserungen zu erzielen, weil die Ansätze nicht hinreichend durchdacht wurden.

Den Sinn von Methoden verstehen

Denn neue Methoden sind zwar immer neu, aber nicht unbedingt besser. Und bevor man sie einführt, sollte man sich sorgfältig überlegen, wo ihre Vorteile liegen, aber auch, welche unerwünschten Nebenwirkungen sie mitbringen. Denn meist verbessert man einen bestimmten Aspekt der Arbeit, zahlt aber einen Preis dafür, indem man andere Aspekte beeinträchtigt.

Deshalb sollte ein Gedanke auch immer sein, ob man nicht die gewünschten Verbesserungen durch Optimierung der bisherigen Methoden erzielen kann. Dazu muss man allerdings auch deren Sinn verstehen.

Beispiel "Critical Chain"

Nehmen wir zum Beispiel Critical Chain: Einer der Grundgedanken ist, dass jeder Beteiligte in den Startlöchern seines Arbeitspakets steht und loslegt, sobald es geht. Damit kann man bei Leuchtturmprojekten schöne Durchlaufzeiten erreichen; das Preis dafür ist aber derselbe wie beim 4x100m-Staffellauf: großartige Durchlaufzeit, aber es arbeitet immer nur einer, während drei unproduktiv herumstehen.

Ein anderer Grundgedanke: Einzelpuffer werden gesammelt und vom Projektmanager als gemeinsame Reserve ans Ende eines Pfads gesetzt. Eine richtige Idee – aber ist nicht im "klassischen" Projektmanagement genauso die Notwendigkeit gegeben, den Arbeitspaketbesitzern das Einplanen persönlicher, stiller Reserven auszureden, weil damit jede Projektschätzung grundsätzlich zu pessimistische Werte liefert? Die erzieherische Aufgabe ist in beiden Fällen dieselbe, nur wird den Spezialisten bei "Critical Chain" suggeriert, der Verzehr eines Puffers würde kollektiviert und damit nicht mehr dem Einzelnen zur Last gelegt.

Beispiel "Scrum"

Die agilen Methoden wurden entwickelt, weil der Kunde nicht wusste, was er wollte, und unterwegs oft seine Meinung änderte (Arbeitsprinzip IKIWISI: "I will know it, when I see it"). Scrum basiert auf Selbstorganisation der Teams, regelmäßiger Kommunikation intern sowie mit einem Kundenvertreter und auf operativen Entscheidungen an der Basis. Das Modell ist also eher organisch-selbstregulierend als mechanistisch-hierarchisch.

Aber: Predigen wir das nicht auch schon lange im klassischen Projektmanagement? Dass Kommunikation das Wichtigste überhaupt ist? Dass autonomes Projektmanagement die Flexibilität fördert? Dass im Projekt unternehmerisches Denken gefragt ist? Dass man sich in Stage-Gate-Prozessen immer wieder die Rückmeldung holt, ob man noch auf dem richtigen Weg ist?

Beispiel "Kanban"

Die Methode beruht auf den psychologischen Erkenntnissen, dass der Mensch nicht wirklich multitasking-fähig ist aufgrund der Produktivitätsverluste bei ständiger Neu-Einarbeitung, und dass es motivierender ist, regelmäßig eine Aufgabe abzuschließen, als permanent viele offene Baustellen zu jonglieren.

Bei guter Umsetzung führen operative Entscheidungen an der Basis (s. Scrum) zur Konzentration auf das aktuell Wesentliche, und als Ergebnis geht kurze Durchlaufzeit vor Auslastung (s. Critical Chain) und Teamerfolg vor Einzelleistung. Aber gibt es die Erkenntnisse nicht schon seit den 1970ern? Und wurden nicht auch im klassischen Projektmanagement dieselben Ergebnisse beschworen (die Teamleistung zählt!)?

Beispiel "Planning Poker"

Die Einhaltung der Regeln führt zur Vermeidung des Anker-Effekts (die erste genannte Zahl bleibt haften) und zur Anerkennung von Schätzunsicherheiten (Fibonacci-Zahlen). Aber läßt sich das nicht auch mit klassischen Schätzmethoden erreichen? Man müßte halt dran arbeiten, indem man keine Erwartungen vorgibt, die Schätzer nicht unter Druck setzt und die Nichteinhaltung der Schätzwerte nicht sanktioniert!

Alter Wein in neuen Schläuchen

Um keine Missverständnisse aufkommen zu lassen: Ich bin ein Fan einiger dieser neuen Methoden! Sie gießen alte Erkenntnisse in neue Regeln, manche von ihnen machen Spaß, und sie haben einen großen Vorteil: Je ungewohnter die neuen Regeln scheinen, desto schwerer fällt es den Menschen, in die alten Verhaltensmuster zurückzufallen, die man damit bekämpfen will.

Bevor man aber neue Methoden einführt und damit auch ihre Nachteile in Kauf nimmt, sollte man sich sorgfältig überlegen, welcher Sinn zu ihrer Entwicklung geführt hat, und ob man diesen Sinn nicht durch geeignete Maßnahmen in der klassischen Vorgehensweise wiederbeleben kann; denn die Methodik "Projektmanagement" ist entstanden auf der Basis von Grundannahmen und Prinzipien, die ihre Bedeutung nicht verloren haben, sondern nur durch Tages-Stress und Projektroutine verschüttet worden sind.

Einmal Moderne und zurück, hin zweiter Klasse, zurück erster; das wär's doch.

Bisher gibt es 7 Kommentare
"Bevor man aber neue Methoden einführt und damit auch ihre Nachteile in Kauf nimmt,"
Welche wären es denn beim Thema Scrum?
vor 29 Wochen 4 Tagen Jürgen M.
alt_text
Mit der Einführung einer neuen Methode handelt man sich neue Risiken ein, die mit schlechter Durchführung und mangelndem Verständnis verbunden sind. S. dazu den Artikel im Projektmagazin Ausgabe 24/2015.
Bei korrekter Durchführung von Scrum sind aber die Vorteile, die z.B. das Team sieht, u.U. Nachteile für die Gegenseite, nämlich den Kunden. Und die sollte der Kunde bewusst akzeptieren. Beispiele:
1) Die Entscheidungsgewalt wird nach unten verschoben. Das Team entscheidet über die Arbeitsreihenfolge mit. Und vor jedem Sprint muss ein Kundenvertreter festlegen, welches Requirement als nächstes bearbeitet wird. Diese Art Basisdemokratie ist nicht jedem Kundenmanager klar.
2) "Irrtümer" bei der Festlegung der nächsten Anforderungen durch den Kundenvertreter müssen bei späteren Sprints korrigiert werden und gehen zu Lasten des Gesamtbudgets. Passiert das zu oft, hat das Endprodukt nicht den anfänglich erwarteten Umfang, bei geringerer Produktivität des Systems Kunde-Team.
3) Die klassische Vorgehensweise (Lastenheft -> Pflichtenheft -> Planung) verspricht, dass der Zusammenhang der Produktfeatures hinreichend durchdacht ist, bevor die Arbeit losgeht. Das ist gut gegen die o.g. "Irrtümer". Manche Kunden wollen eigentlich nicht darauf verzichten. Besonders wichtig, wenn es nicht nur um Software geht.
4) Beim endgültig realisierten Lastenheft konnte jeder Entscheider beim Kunden mitreden. Das entfällt u.U. bei Scrum.
5) Je nach velocity werden die Produkte mehr oder weniger vollständig.
6) nicht "vollständige" Produkte gehen klassisch zu Lasten des Lieferanten (Nacharbeit bei Festpreisverträgen), bei Scrum zu Lasten des Kunden.
Usf.
vor 28 Wochen 6 Tagen Walter Plagge
Vielen Dank für die Antworten
zu 1) Falsch, das Team entscheidet nur im Sprint mit, die Reihenfolge entscheidet der Product Owner als Sprachrohr des Kunden
zu 2) Was ist den die Alternative? Weitermachen und den Irrtum ausblenden bis zum Ende und dann feststellen, dass das gesamte Produkt schlecht ist?
zu 3) Wer sagt denn das bei SCRUM nicht vorher vom Kunden ein Konzept erstellt werden darf? Sich Gedanken machen wie ein Produkt wird hat noch niemanden geschadet und ist sogar absolut notwendig ;-)
zu 4) Auch falsch, der Product Owner ist nicht der alleinige Entscheider, aber der der die Entscheidungen präsentiert und vertritt.
zu 5) Das gleiche ist dich bei der klassischen PL auch, nur eben nicht transparent
zu 6) Besser und fairer oder? Alternative ist, dass an der Qualität gespart wird und das Produkt mangelhaft.
vor 28 Wochen 5 Tagen J. Melzer
Soweit die theoretische Rezension. In der Praxis sehe ich den Autor in sooooo vielen agilen Projekten bestätigt, wo man agil sein wollte, es aber nicht ist. Die Nebeneffekte: Unsortierte Backlogs (= ungeklärter Scope), Patchwork-Arbeit (= jeder nimmt sich halt mal ein PBI, aber es wird nie etwas fertig, was einem "potentially shippable product" ähnlich wäre), nicht absehbare Sprintanzahl und Kosten (= der Projektplan darf "atmen") und/oder Projekt-Streams (z.B. Entwicklung und Schulungen), die nicht zusammen geführt werden können, weil mangels Planbarkeit keiner weiß, wann.
So hatte man sich das natürlich nicht vorgestellt. Aber dass man für z.B. Scrum auch die Voraussetzungen schaffen muss und noch viel disziplinierter arbeitet als in klassischer Planung, das wurde halt im Hype-Hinterherlaufen verdrängt. Scrum funktioniert toll, wenn man ein eingespieltes Team hat, mit den richtigen Skills und Erfahrungen, und wenn man sich strikt an die Methodik hält. Im Projektalltag haben wir aber meist je Projekt neu zusammen gewürfelte Leute, die gerade frei waren bzw. die die Fachabteilungen abgeben wollten, und ja: wir haben jeden Tag ein Standup gemacht. Von anderen Quernissen pseudo-agiler Vorgehensweise will ich gar nicht reden.
Ganz oder gar nicht? Nicht unbedingt, denn hybride Ausführungen können, ganz verstanden, intelligent verknüpft und die Nebenwirkungen mitigiert, auch beste Ergebnisse bringen und obendrein das "konservative" Management mit den gewünschten Eckdaten befriedigen. Das ist es wohl auch, was der Autor mit "Weiterentwickeln" von Bestehendem meint. Aber man muss natürlich verstehen, was man da macht, und Dogmatismus hilft nicht weiter!
vor 28 Wochen 2 Tagen Henning Zeumer, der Projekt-Sanierer
Oh das tut mir leid für Sie.
Ich mache SCRUM seit der ersten Stunde und habe bereits vorher XP gemacht und kann Ihre Ausführungen nicht bestätigen, da die natürlich die Soft-Skills einerseits höher sein müssen andererseit der SCRUM Master genau dafür u.a. da ist diese mit aufzubauen und die Mitglieder zu unerstützen.
Klar läuft nicht immer alles reibungslos, trotzdem bin ich überzeugt, dass man, wenn man es denn möchte, die Teammitglieder und die Kunden "mitnehmen" kann.
Wird allerdings der Ansatz vom Management nicht mitgetragen ist es eine Todgeburt.
Und selbstverständlich kann man SCRUM an die Gegebenheitheit teilweise anpassen nur sollte man die usprüngliche Idee nicht aufgeben.
vor 28 Wochen 2 Tagen J. Melzer
@J. Melzer:
Um keinen falschen Eindruck entstehen zu lassen: ich bin ein Fan der agilen Methoden. Sie fragten nach den Nachteilen von Scrum; was ich aufführte, sind nicht Nachteile in meinen Augen, sondern in denen mancher Manager oder Kunden. Ich denke, in der Sache sind wir nicht auseinander; Ihren Einwänden auf meine Antwort stimme ich absolut zu.
Mein Punkt war ein anderer: Die "Nachteile" neuer Methoden basieren häufig auf einem mangelnden Verständnis. Dieses mangelnde Verständnis können wir aber bei derselben Klientel auch hinsichtlich klassischer PM-Methoden beobachten. Und dann kommt man mit einem Methodenwechsel vom Regen in die Traufe.
Viele Probleme ließen sich bei gutem Verständnis und sauberer Anwendung "alter" Methoden vermeiden. Und wenn man dann zu "neuen" Methoden wechselt und bei allen Stakeholdern auf dasselbe gute Verständnis und saubere Anwendung hinarbeitet, dann kann man den Nutzen erzielen, für den die "Neuen" entwickelt wurden.
@Henning Zeumer:
danke für Ihren klärenden Kommentar! Ihre Beispiele erklären bildhaft, was ich meinte und mit meinem Beitrag ausdrücken wollte.
vor 24 Wochen 2 Tagen W. Plagge
Natürlich gibt es schwierige Kunden und die werden in der Regel auch schwierig bleiben. Meine Erfahrung ist aber dass durch die hohe Transparenz viele Blockaden abgebaut werden.
Bei Managern, die es nicht wollen, sieht es da ganz anders aus. Die haben häufig Verlustängste und torpedieren daher manche Projekte. Dabei ist das Riskio für ein scheiterndes Projekt größer.
Vielleicht hatte ich ja nur Glück (oder ich habe die richtigen Tatktiken gewählt, um die schwierigen Leute mit ins Boot zu holen). Bei mir waren die agilen Projekte, die ich bereits seit 18 Jahren mache, alle ein Erfolg.
vor 24 Wochen 2 Tagen J. Melzer
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link