Agiles Projektmanagement Schneller geht's nicht – Ultimate Scrum

Was ist die maximale Geschwindigkeit bei der Software-Entwicklung? Agile Steuerungsmethoden wie Scrum oder Kanban haben die Software-Entwicklung bereits deutlich beschleunigt. Aber es geht noch viel schneller, behauptet Wolfram Müller. Er vergleicht die agilen Vorgehensweisen mit traditionellen Produktionssteuerungen und folgert daraus, dass eine Kombination aus Agilem Projektmanagement mit der Drum-Buffer-Rope-Steuerung der Theory of Constraints dem theoretischen Optimum bereits sehr nahe kommt. Er stellt seine empirisch gefundene Vorgehensweise, die er "Ultimate Scrum" nennt, detailliert vor und schildert seine ersten Erfahrungen mit dieser Arbeitsweise.

 

Agiles Projektmanagement Schneller geht's nicht – Ultimate Scrum

Was ist die maximale Geschwindigkeit bei der Software-Entwicklung? Agile Steuerungsmethoden wie Scrum oder Kanban haben die Software-Entwicklung bereits deutlich beschleunigt. Aber es geht noch viel schneller, behauptet Wolfram Müller. Er vergleicht die agilen Vorgehensweisen mit traditionellen Produktionssteuerungen und folgert daraus, dass eine Kombination aus Agilem Projektmanagement mit der Drum-Buffer-Rope-Steuerung der Theory of Constraints dem theoretischen Optimum bereits sehr nahe kommt. Er stellt seine empirisch gefundene Vorgehensweise, die er "Ultimate Scrum" nennt, detailliert vor und schildert seine ersten Erfahrungen mit dieser Arbeitsweise.

 

Agile Methoden haben in den letzten Jahren einen Siegeszug bei der Software-Entwicklung angetreten und finden auch bei anderen Projektarten immer größere Verbreitung. Mit den bekanntesten Methoden Scrum und (Software-)Kanban ziehen auf diese Weise Ideen, die eigentlich aus der Produktionssteuerung kommen (s.u.), auch in die Projektwelt ein.

Aber auch diese Ansätze haben noch Schwächen. Zwar begrenzen sie den Work-In-Progress (aktuell in Bearbeitung befindliche Aufgaben), allerdings tun sie dies nur lokal und nicht über die gesamte Laufzeit und den gesamten Umfang eines Projekts hinweg. Darüber hinaus können weder nach Scrum noch nach Kanban arbeitende Teams verbindliche Zusagen für einen definierten Leistungsumfang zu einem bestimmten Zeitpunkt geben. Dies wird erst durch den von mir beschriebenen Ansatz "Reliable Scrum" (Müller, Projekt Magazin 18/2012) erreicht, auf den dieser Artikel aufbaut.

Reliable Scrum sorgt zwar für eine höhere Planungssicherheit, kann aber nicht verhindern, dass es bei Scrum und Kanban einen verhältnismäßig großen Bestand an offenen Aufgaben gibt. Die Folge davon ist, dass die Durchlaufzeiten länger als notwendig sind. Wie ich im Folgenden zeige, ist es für eine Steigerung der Produktivität aber wichtig, die Anzahl der offenen Aufgaben zu minimieren und die Durchlaufzeiten bis zum Optimum zu verkürzen. Durch die starke Fokussierung auf Reduktion des Bestands und die Verkürzung der Durchlaufzeit werden alle störenden Hindernisse ausgeräumt. Die Produktivität und damit der Durchsatz steigen nachhaltig. In Folge entsteht der größte Nutzen für den Kunden, das Unternehmen und genauso für die Mitarbeiter.

Alle agilen Ansätze setzen sehr stark auf Selbstorganisation. Das ist zwar für das Funktionieren der agilen Methoden sehr gut und wichtig, aber die Selbstorganisation gewährleistet weder, dass schnell ein Leistungsoptimum erreicht wird, noch dass es überhaupt erreicht wird.

Im Folgenden zeige ich, wo das Optimum der Leistungsfähigkeit eines agilen Teams liegt, woran man erkennt, wie weit man noch davon entfernt ist, und wie man es durch ein kombiniertes Steuerungsverfahren erreichen kann. Diesem Steuerungsverfahren habe ich, da es Scrum als Basis hat, den Namen "Ultimate Scrum" gegeben.

Optimale Geschwindigkeit – der "Heilige Gral des Projektmanagements"

Die Suche nach der optimalen Geschwindigkeit eines Projektteams hört sich so an wie die "Suche nach dem Heiligen Gral". Tatsächlich haben sich schon Generationen von Projektmanagern mit dieser Herausforderung befasst. Z.B. wurde die traditionelle Netzplantechnik in erster Linie dazu erfunden, um Projekte schneller durchführen zu können. Auch heute geht es in Projekten immer noch darum, Ergebnisse möglichst schnell zu liefern: Wir befinden uns in einer leistungsorientierten Gesellschaft, in der genau derjenige einen Wettbewerbsvorteil hat, der ein Stückchen näher am Optimum arbeitet als die anderen.

Gleich vorweg: Es geht dabei nicht um die Optimierung der Leistung zu Gunsten einzelner Nutznießer (z.B. der Shareholder des Unternehmens) und auf Kosten vieler Leistungserbringer (der Teammitglieder). Bei meinen Überlegungen steht der Mensch im Mittelpunkt. Für mich bedeutet "Optimum" stets, dass der angestrebte Zustand auch aus Sicht der Mitarbeiter optimal ist. Denn was gibt es Schöneres und Motivierenderes als jeden Abend sagen zu können: "Ich habe heute das Bestmögliche erreicht!"

Um das Optimum zu erreichen, muss man jedoch viele Aspekte berücksichtigen: Man muss die richtigen Produkte und Projekte auswählen und man braucht sehr gute Führungskräfte wie auch Mitarbeiter. Weiterhin gilt es, Wissen aufzubauen und dieses in Können umzusetzen. Last-but-not-least muss die Arbeitsorganisation alles perfekt unterstützen.

Für die absolute, optimale Leistungsfähigkeit müssten auch alle diese Aspekte optimal sein – dies ist ein hehres Ziel. Jedoch steht dem Erreichen dieses Ziels leider entgegen, dass Ressourcen und Zeit begrenzt sind. Man muss sich daher fokussieren. Doch welchen der genannten Aspekte adressiert man zuerst? Die Arbeitsorganisation hat hier eine interessante Sonderstellung: alle Verbesserungen dieses Aspekts sind – wie der Name schon sagt – organisatorischer Natur. D.h. Arbeitsorganisation besteht "lediglich" aus Regeln und Mustern in unseren Köpfen. Diese lassen sich, wenn man es richtig macht, unverzüglich und kostenlos ändern. Als Dank erhält man mehr Kapazität, die für Verbesserungen der anderen Aspekte genutzt werden kann (Goldratt, 1984 und 1997; Techt, 2006).

Mein Lösungsweg, um zur optimalen Geschwindigkeit von agilen Projekten zu gelangen, besteht daher darin, als erstes die Arbeitsorganisation zu optimieren. In meiner Praxis als Leiter bzw. Coach von agilen Teams konnte ich die im Folgenden dargestellten Steuerungsverfahren empirisch Schritt für Schritt entwickeln und ihren Erfolg verifizieren.

Durchlaufzeit minimieren, Performance steigern, Stress beseitigen

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 3
Kommentare 2

Alle Kommentare (2)

Karen
Dittmann
Dr.
Die Vorgehensweise ist wirklich sehr interessant. Da steckt viel mehr dahinter, als einfach nur ein paar neue Tools oder Methoden. Ich freue mich auf den Workshop dazu am 24.4. in Ettlingen und bin gespannt, ob das auch Projektleiter vieler schneller paralleler Projekte helfen könnte, den MEHRPROJEKT|Managern. Denn für die gibt es bisher noch wenig...

 

Steffen
Thols
Immer wieder gut finde ich, wenn es im Bereich der Vorgehensweisen zu Projekten neue Ansätze gibt, die zum Nachdenken und im besten Falle zur Verbesserung der Arbeitsweise führen. Daher von mir als überzeugten Agilisten auch noch meine Gedanken und m.E. notwendige Hintergrundinfo zu diesem durchaus interessanten Artikel.

Wenn ich mich in Firmen aufhalte, die agile Vorgehensweisen einführen möchten, lege ich u.a. allergrößten Wert darauf, dass auch eine Änderung der Denkweise bei allen Beteiligten einsetzen muss. Denn ansonsten hat man m.E. keine tragfähige Basis für eine langfristige erfolgreiche Zusammenarbeit. Aus diesem Grunde möchte ich auch niemals mehr irgendwo lesen oder hören müssen, dass ein Mensch als Ressource beschrieben wird! Wie wir alle wissen prägt die Sprache das Handeln und zumindest mir geht es so, dass ich nicht mit einem Stuhl oder Server auf eine Stufe gestellt werden möchte.

Der Scrum Master darf nie, wirklich niemals die Menge an Stories, die in einen Sprint passt, festlegen! Dies wäre genau die alte Command&Control-Denkweise die mit Scrum abgeschafft werden soll. Die Menge an Stories, die in einen Sprint hinein passen, ergibt sich aus der Erfahrung der bereits abgelaufenen Sprints (Prinzip des Yesterdays Weather).

Immer wieder gefährlich wird es m.E., wenn mit einem Begriff unterschiedlich Inhalte transportiert werden. Vom englischen Ursprung von „to slice“ bzw. „slicing of user stories“ ist ursprünglich gemeint, dass eine User Story vertikal durch das System beschrieben sein soll. Also inklusive UI, Zugriffsschicht, DB, etc. In der Verwendung der deutschen Übersetzung hat sich der Begriff des Schneidens von User Stories dahingehend etabliert, dass damit das Schneiden von zu großen Stories in kleinere Stories gemeint ist. In diesem Artikel ist aber das Aufteilen der Story in einzelne Tasks gemeint; dies ist nicht dasselbe. Abgesehen davon ist die Aufteilung von Stories von Tasks immer Teamarbeit! Ohne ins Detail gehen zu wollen nenne ich hier die Stichwörter: Wissensverbreiterung vs. Wissensmonopole.

Das Ziel von agilen Teams und Unternehmen sollte immer die Vermeidung von Verschwendung sein. Eingespielte Teams, die sich sowohl in der technischen als auch fachlichen Domäne gut auskennen, werden sich irgendwann einmal die Frage stellen, ob das Beschreiben von Tasks einen Mehrwert bietet oder Ballast darstellt.

Für die Reviews müssen die Entwickler nicht der begrenzende Faktor sein, wenn das Team tatsächlich Cross-Funktional zusammengestellt ist. Eine Abnahme von fertigen User Stories kann und soll bereits im laufenden Sprint erfolgen. Das Review dient nicht zur Abnahme von Stories sondern als Workshop um gemeinsam (inkl. Stakeholder oder deren Vertreter) zu reflektieren, ob der bislang eingeschlagene Weg und die Entwicklungsergebnisse zusammen (noch) passen.