Über den richtigen Weg in Projekten lässt sich bekanntlich gut streiten. Wer ein Team lähmen will, stellt einfach Inhalte und Vorgehensweise ständig in Frage. "Methode X ist besser.", "Noch nie hat jemand Feature Y Geld verdient." Gibt es eine Möglichkeit für Teams, solche Diskussionen zu umgehen? Ich denke, ja.
Wie oft haben wir in unseren Teams schon die Erfahrungen gemacht, dass Diskussionen endlos und ergebnislos waren. Irgendwann resigniert sogar das ruhigste Teammitglied. Die "jungen Wilden" geben auf und suchen ihr Glück in einem anderen Team. Ein Chef oder eine Chefin glaubt, dass die schlechten Leute immer in sein oder ihr Team versetzt werden. Kurz: eine Abwärtsspirale wird in Gang gesetzt und entzieht dem Team die Energie.
Solche Situationen deuten für mich darauf hin, dass das Team keinen Weg gefunden hat, die unterschiedlichen Sichtweisen zu integrieren. Es ist für mich völlig in Ordnung, dass jedes Teammitglied die Dinge anders sieht. Wolf spricht davon, dass jeder seine eigene innere Landschaft hat. Ich sehe das auch so. Jeder ist durch seine Erfahrungen geprägt. Deswegen gibt es die Diskussionen. Dies (allein) ist kein Zeichen schlechter Teamkultur oder falscher Führung.
Das Team delegiert damit die Entscheidung an die Stelle, die besser entscheidet. Es ist sicher gut, wenn das Team für sich folgende Haltung entwickelt: "Wir brauchen unterschiedliche Erfahrungen, Ideen und Meinungen, um unsere Aufgaben zu lösen. Statt über die besten Ideen zu streiten, machen wir Experimente, um mehr zu lernen."
Teams, die sich selbst zu solcher einer Herangehensweise verpflichten, lernen mehr und schätzen sich untereinander mehr. Das wäre doch einen Versuch wert, oder?
Wie oft haben wir in unseren Teams schon die Erfahrungen gemacht, dass Diskussionen endlos und ergebnislos waren. Irgendwann resigniert sogar das ruhigste Teammitglied. Die "jungen Wilden" geben auf und suchen ihr Glück in einem anderen Team. Ein Chef oder eine Chefin glaubt, dass die schlechten Leute immer in sein oder ihr Team versetzt werden. Kurz: eine Abwärtsspirale wird in Gang gesetzt und entzieht dem Team die Energie.
Solche Situationen deuten für mich darauf hin, dass das Team keinen Weg gefunden hat, die unterschiedlichen Sichtweisen zu integrieren. Es ist für mich völlig in Ordnung, dass jedes Teammitglied die Dinge anders sieht. Wolf spricht davon, dass jeder seine eigene innere Landschaft hat. Ich sehe das auch so. Jeder ist durch seine Erfahrungen geprägt. Deswegen gibt es die Diskussionen. Dies (allein) ist kein Zeichen schlechter Teamkultur oder falscher Führung.
Wie umgehen wir das Problem?
In den wenigsten Fällen gibt es objektive Wahrheiten oder einen Richter, der entscheidet. Das Team muss selbst entscheiden, wie es entscheidet. Ich finde dazu Experimente hilfreich. Teams sollten mehr experimentieren. Im Falle von Projekten bedeutet dies folgendes:- Bevor wir ein Projekt starten, beschreiben wir das eigentliche aktuell bekannte Ziel.
- Wir überlegen uns vorher, woran wir erkennen können, ob wir das Ziel erreicht haben.
- Wir stellen Annahmen über den Weg, die Kunden usw. auf.
- Wir überlegen, wie wir die Annahmen experimentell bestätigen oder widerlegen können.
- Das Ziel und die Annahmen selbst werden auch regelmäßig überprüft.
Was bedeutet das für Projekte?
Scrum und PRINCE2 starten Projekte mit sehr kurzen Dokumenten. Bei Scrum ist es die so genannte Vision. Sie beantwortet in etwas folgende Fragen (/2, Pos. 1970/:- Wie erzeugen wir Werte für unsere Kunden?
- Welches Problem lösen wir?
- Für wen?
- Hauptnutzen, Hauptfeatures?
- Wichtigste nicht-funktionalen Anforderungen?
- Welche "Plattform", welche "Technik" unterstützen wir?
- Hintergrund
- Zielsetzungen des Projekts
- Angestrebte Ergebnisse
- Projektumfang und Ausschlüsse
- Einschränkungen und Annahmen
- Projekttoleranzen
- Benutzer und sonstige bekannte Interessengruppen (engl. Stakeholder)
- Schnittstellen
Das Team delegiert damit die Entscheidung an die Stelle, die besser entscheidet. Es ist sicher gut, wenn das Team für sich folgende Haltung entwickelt: "Wir brauchen unterschiedliche Erfahrungen, Ideen und Meinungen, um unsere Aufgaben zu lösen. Statt über die besten Ideen zu streiten, machen wir Experimente, um mehr zu lernen."
Teams, die sich selbst zu solcher einer Herangehensweise verpflichten, lernen mehr und schätzen sich untereinander mehr. Das wäre doch einen Versuch wert, oder?
Anmerkungen
- /1/ Dies ist eins von fünf Prinzipien der Lean-Startup-Methode, siehe Ries, Eric: The Lean Startup : How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Random House Digital, Inc., 2011.
- /2/ Leffingwell2010: Leffingwell, Dean: Agile Software Requirements : Lean Requirements Practices for Teams, Programs, and the Enterprise. 1. Aufl.. Boston: Addison-Wesley Professional, 2010.
- /3/ Commerce, Office of Government: Erfolgreiche Projekte managen mit PRINCE2. London: The Stationery Office, 2009.
Scrum beschreibt NICHT, wie diese "Vision" aussieht. Im Scrum Guide ist zur "Vision" nur das zu lesen: "Der Scrum Master dient dem Product Owner unter anderem indem er ... Vision, Ziele und Einträge des Product Backlogs gegenüber dem Entwicklungs-Team klar kommuniziert". Das ist der EINZIGE Ort, an dem im Scrum Guide "Vision" erscheint. Das ist auch verständlich, da sich Scrum ja nicht mit Projekten beschäftigt sondern ein Rahmenwerk darstellt, "mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern."
AntwortenLöschenDie oben dem Scrum zugeschriebene Beschreibung der vision hat mit Scrum nichts zu tun sondern ist (siehe auch die Referenz) dem Scaled Agile Framework entnommen - bezieht sich aber auf die Vision eines Produkts bezogen auf seine gesamte Lebensdauer, nicht auf ein Projekt, da SAFe sich bewusst nicht mit Projekten beschäftigt.
Für agile Projekte gibt es als Methode vor allem PRINCE2 und auch DSDM, niocht aber Scrum oder SAFe.
Ja, das stimmt. Im Scrum Guide gibt es keine Vorgaben für eine Vision.
AntwortenLöschenIch fand die Ideen von Leffingwell für Softwareprojekte ganz hilfreich. Bei anderen Arten von Projekten gehören andere Punkte in die Vision.
Jeff Sutherland und Ken Schwaber haben sicherlich mit Absicht kein festes Format vorgegeben. Wichtig ist nicht das konkrete Format, sondern dass die Vision dem Team hilft, Ziele abzustimmen.
LG, Jan
Vielleicht sollten wir uns mal darüber verständigen, was wir unter 'Projekt' verstehen. Ich habe nämlich die Hypothese, dass hinter fest gefügten Sätzen wie 'Methode X hat nichts mit Projekten zu tun' bestimmte Definitionen von 'Projekt' stehen.
AntwortenLöschenIch schlage vor, einen der nächsten Blogartikel dem Thema zu widmen aus TWB-Sicht, und bestimmt können dann Unknown und andere diese Sicht gut ergänzen oder andere Sichten daneben stelle .
LG, Wolf
Ein Kommentar von Hans Peter Korn:
LöschenDas ist sicher eine gute Idee - wobei ich mir wünschen würde, nicht nach "der" Wahrheit zu suchen (die es m.E. nicht gibt) sondern verschiedene Sichtweisen darzustellen.
Eine davon findet sich in http://www.symposion.de/kapitel40600101_WERK0003442.html im Abschnitt:
o Produkt- bzw. Service- statt Projektfokus
ƒoo Kontinuierliche statt projektspezifisch fragmentierte Lieferungen von Produkt- und Serviceinkrementen
Dort ist die Sicht des Scrum Guide dargestellt und dann die Sichten von Martin Kütz, Prof. Ayelt Komus und Dean Leffingwell.
Lieber Wolf,
Löschendas ist ein wichtiger Punkt und schon lange meine These: Wir haben keine klare Vorstellung davon, was ein Projekt ist. Uns fehlt eine innere Projektgestalt. Wir haben einen bekannten Begriff aber nur eine vage Vorstellung.
Es gibt verschiedene Gestalten (z. B. Party oder das Rautenmodell). Je nach Kontext ist eine andere hilfreich. Manchmal ist eine Situation auch nicht eindeutig. Dann müssen wir versuchen, wie HP schon anmerkte, verschiedene Sichten zu integrieren.
Erst wenn wir uns bei der zu betrachtenden Situation über die Gestalt im Klaren sind, dann können wir den nächsten Schritte machen.
LG, Jan
Anmerkungen:
* Projekt als Party: https://www.projektmagazin.de/artikel/was-projektmanager-von-partys-lernen-koennen_1072930
* Projekt als "Ich bin mir nicht sicher Aufgabe": http://www.scrum-day.de/vortraege/mitprojektprofilenscrumbesserverkaufen.html