Warum man nicht mit Scrum anfangen sollte.
Scrum ist ein Rahmenwerk, so steht es im offizellen Scrum-Guide und so wird es auch fleißig von allen Scrumlern wiederholt. Aus diesen Grund hat es auch auf viele Fragen gar keine Antworten, bzw. die Antwort lautet: „Frag das Team“. Das ist cool und wenn wir alle Zeit der Welt hätten, würden wir so gemeinsam in aller Ruhe alles Wichtige über unsere Projekte und die Zusammenarbeit im Team lernen. Leider haben wir meistens nicht ganz so viel Zeit, aber es gibt ja den zertifizierten Scrum-Master. Der hat 2 Tage in einem Kurs gesessen und weiß das Wichtige, so dass er uns helfen kann Antworten zu finden. Irgendwie kann das nicht der Weg sein, oder?
Soll es auch nicht. Ken Schwaber selbst erklärt in diesem Interview noch mal warum (neben einer Reihe anderer interessanten Beobachtungen). Die wichtigste Aussage: Scrum beschreibt nicht erneut die bereits existierende Techniken des Projektmanagements, sondern setzt voraus, dass diese eingesetzt werden. Das macht ja auch Sinn und deswegen steht auch im Scrum-Guide, dass Scrum ein Rahmenwerk sei. Leider steht kein Wort darüber drin, was in dieses Rahmenwerk alles hinein sollte.
Darum: Fangen Sie nicht mit Scrum an. Fangen Sie mit ganz altbackenem, traditionellem, langweiligem, seriösem, standardisiertem Projektmanagement an. Von mir aus gerne in einer „agilen Kombi“, wie in unserem APM-Seminar. Und vielleicht beschäftigen Sie sich als Organisation oder als Team auch noch mal intensiver mit Themen wie Kommunikation, Teambuilding oder Konfliktmanagement. Das funktioniert ganz ohne Scrum und ist eine wichtige Voraussetzung um dann mit Scrum wirklich zum Erfolg zu kommen.
Übrigens der Name Scrum kommt aus dem Rugby und beschreibt dort genau einen Spielzug. Ich vermute ein Team, das nur diesen einen Spielzug beherrscht wird im gesamten Spiel nicht sehr erfolgreich sein (auch wenn es schrittweise lernen könnte, worauf es bei diesem Spiel eigentlich ankommt und warum man sich die Ohren abkleben sollte).
Warum man mit Scrum nicht aufhören sollte.
Scrums Stärke liegt in zwei Bereichen:
- Der kontinuierlicher Verbesserung des Entwicklungsprozesses im laufendem Projekt
- Der Aufteilung von Verantwortung, der viele wichtige Konflikte in der Organisation zu Tage bringt
Wer sich um diese Bereiche nicht kümmern mag, dem nützen auf Dauer auch die Projektmanagmentwerkzeuge und die Kommunikationstrainings nicht viel. Aber in diesen Bereichen steckt das Potential um wirklich eine effektive Entwicklungsorgansiation aufzubauen. Das geht auch nicht über Nacht, aber Scrum als Prozessrahmen bietet spannende Möglichkeiten um „Ihre Themen“ zu identifizieren, sowohl im Projekt wie auch als Organisation. Die fehlenden Antworten hat Scrum leider auch nicht, aber Scrum macht es Ihnen schwer zu ignorieren, dass Sie die Antworten brauchen.
Darum: hören Sie nicht auf mit Scrum. Nutzen Sie Scrum um an „Ihren Themen“ zu arbeiten. Um mehr zu lernen, über Ihr Projekt, Ihre Organisation, Ihre Stärken, Ihre Schwächen, das Potential Ihres Teams und wie Sie gemeinsam Ideen entwicklen können, um mit diesen Themen zu arbeiten. Und dann machen Sie weiter, machen Sie sich schlau über Kanban, Causal-Loop- Diagrams, Systemisches Denken, Kreativität, Prozesskontroll-Statistiken …
Wer mit Scrum aufhört und anfängt, der verpasst eine Menge.
Fangen Sie gerade mit Scrum an? Würden Sie am liebsten schon wieder aufhören? Haben Sie noch eine ganz andere Idee? Kommentare sind erwünscht!
[…] Warum man weder mit Scrum anfangen, noch aufhören sollte … « Team Blog Tags: scrum This entry was posted on Monday, November 8th, 2010 at 7:31 pm and is filed under DocShare. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. […]
Genau! Statt diesem altmodischen agilen Zeug lieber gleich mit etwas vernünftigem anfangen. Nach agile kommt fragile. Und wenn man’s erst mal erlebt hat, will man nie wieder zurück.
(Und ansonsten stimmt’s natürlich auch ganz grundsätzlich: bloß nie zu weit über den eigenen Tellerrand schauen! Da könnte schließlich das eigene Essen kalt und uninteressant werden. Wozu hat man denn auch sein tolles Zertifikat, welches die Genialität des eigenen Festbratens glasklar bescheinigt? Eben.)
[…] Jan Gentsch schreibt auf dem oose.team Blog einen Beitrag darüber, warum man mit Scrum nicht anfangen, aber auch nicht aufhören sollte. […]
Interessante Gedanken, Herr Gentsch, aber auch mehrdeutig, wie ich gerade in einer Diskussion abseits dieses Forums feststellen musste.
Bevor ich also meine Gegenthese aufstelle, die mir sporadisch beim Lesen Ihres Artikels, einfiel, stelle ich besser einige Verständnisfragen: Was genau meinen Sie mit „Fangen Sie nicht mit Scrum an. Fangen Sie mit ganz altbackenem, traditionellem, langweiligem, seriösem, standardisiertem Projektmanagement an.“?
Meinen Sie damit, dass man die Methoden des klassischen PM kennen sollte, bevor man Scrum einführt?
Oder meinen Sie damit, dass man tatsächlich klassisches PM komplett einführen sollte, bevor man Scrum einführt?
Oder meinten Sie gar, dass man klassisches PM beherrschen sollte, bevor man Scrum einführt? Und was hieße dann „beherrschen“?
Und beziehen Sie sich eigentlich auf spezielle Projektarten/-größen oder auf alle Projekte? Und auf Organisationen mit welchem Ist-Projektmangement (z.B. von chaotisch bis strikter Durchplanung am Projektanfang – was wohl beides allenfalls zufällig funktionieren wird)?
Den Teil mit APM verwirrt mich auch außerdem etwas. Weil meinem Verständnis nach APM etwas sehr Scrum-Ähnliches als Teilprozess enthält.
Alles Gute wünscht
… Michael Hönnig
Hallo Herr Hönnig,
die Mehrdeutigkeit war vielleicht nicht ganz unbeabsichtigt. ;-)
Im Scrum-Guide findet sich der treffende Satz: „Die Rolle von Scrum ist die Wirksamkeit/Funktionsweise der eigenen Entwicklungsprozesse sichtbar zu machen, so dass diese verbessert werden können, wobei es gleichzeitig einen Rahmen aufspannt in dem komplexe Produkte entwickelt werden können.“
Scrum ist keine Projektmanagementmethode oder ein Vorgehensmodell. Das ist auch in Ordnung so, denn Scrum verfolgt ein anderes Ziel. Dazu findet sich im Scrum-Guide der treffende Satz: „Die Rolle von Scrum ist, die Wirksamkeit/Funktionsweise der eigenen Entwicklungsprozesse sichtbar zu machen, so dass diese verbessert werden können, wobei es gleichzeitig einen Rahmen aufspannt in dem komplexe Produkte entwickelt werden können.“
Aus meiner Sicht ist es daher auch essenziell sich mit den klassischen Projektmanagementmethoden auseinanderzusetzen. Eines der häufigste Probleme an denen die Einführung agiler Vorgehensweisen hängen bleibt ist aus meiner Erfahrung, dass es schlicht schon an den Basis fehlt: Ein unklarer Projekteauftrag, fehlendes Risikomanagement, ungeregeltes Stakeholdermanagement sowie ein unkontrollierter Umgang mit Änderungen. Das sind klassische Themen und auch essenziell für agiles Vorgehen.
Insofern, glaube ich dass eine Organisation, bzw. die Projektbeteiligten auch klassisches Projektmanagement kennen sollten, wenn Sie sich mit agiler Vorgehensweise auseinandersetzen. Beides gehört zusammen (weshalb, wir bei oose das auch schon seit bald 10 Jahren zusammen trainieren). Und Scrum als Teil des Projektmanagements funktioniert ganz sicher nicht ohne diese Elemente.
Ich bin mir immer nicht sicher, was eine wirklich komplette Einführung ist. Das unterstellt ja, es gäbe so was wie die richtige, fertige Form. Insofern kann ich nur sagen, dass ich auch in Projektmanagementgrundlagen-Trainings agile Projektstrategien reinmogele. Das funktioniert klasse und wir müssen es ja keinem weitersagen. :-)
Für mich ist dieses Thema in der Tat auch unabhängig von der Projektart oder -größe. Ich würde es zum Schluss nochmal mit einem Bild versuchen: Ich habe früher auch ein Leistungsschwimmteam trainiert. Wichtig ist dabei, dass Sie ihren Schwimmer sowohl die Technik beibringen, wie auch die Fähigkeit selbst zu erkennen, wann eine Bewegung richtig ist (sich richtig anfühlt). Das Zweite kriegen Sie aber nicht hin, wenn Ihnen Ihre Leute ständig absaufen.
In diesem Sinne …
Großartig! Ihre Ausführungen sprechen mir ganz aus der Seele, darum habe ich mit meinen zarten Blog-Start gleich auf Ihr Thema referenziert. Das ist ja noch beliebig ausbaufähig.
Vielen Dank für Ihre gedanklichen Anregungen!
Herzliche Grüße –
… darum finde ich Blogs von Leuten, die täglich Scrum praktizieren besser, als von Leuten, die Beratung verkaufen. Praktischerweise verweisen sie auch gleich auf einen eigenen Kurs :)
Denn wer von Beratung lebt, wird nie etwas verkaufen, das ihn überflüssig macht. Tut mir leid. Aber man wird nicht Scrum-Master durch einen 2-3 tägigen Kurs. Man bekommt da ein Zertifikat, weil unsere zertifikatsverliebten HR-Abteilungen nicht ohne können. Daher macht man es sich recht einfach, wenn man die Qualität von Scrum in Frage stellt und als Argument hierfür den Scrum-Master nimmt.
Hallo Thomas,
die Aussage vom Jan Gentsch „Der hat 2 Tage in einem Kurs gesessen und weiß das Wichtige“ habe ich eher mit Augenzwinkern als einen Seitenhieb auf die Machenschaften der Scrum Alliance gelesen.
So wie ich oose kennen gelernt habe, legen die sehr großen Wert auf vernünftige Qualifzierung mit Hand und Fuß und bieten wahrscheinlich genau deshalb zum CSM-Kurs auch immer gleich eine Ergänzung „Führen als Scrum-Master“ an.
Aber ich mutmaße jetzt natürlich auch nur, was Herr Gentsch wirklich gemeint hat.
Hallo Joachim, hallo Thomas,
danke für Eure Kommentare! :-)
Hinter meiner eigene Bemerkung zu Scrum-Master-In-2-Tagen steckt vor allem ein Augenzwinkern und den Seitenhieb will ich auch nicht verleugnen. :-)
Das Augenzwinkern bezieht sich vor allem auf die Erwartungshaltung von Managern, die Ihre Mitarbeitenden in solche Trainings schicken und erwarten, dass Sie ein Scrum-kompetenten Mitarbeitenden zurück bekommen, der jetzt alles richtet und weiß „wie es geht“. Der Seitenhieb geht schon in die Richtung der Scrum-Allianz, die dazu beiträgt, dass das Bild entsteht man könne in 2 Tagen zum Scrum-Master reifen.
Insofern stelle ich die Qualität von Scrum nicht in Frage. Aber wie Thomas richtig sagt, wird man nicht in 2-3 Tagen ein kompetenter Scrum-Master oder Produktowner. Das braucht auch eine Menge Wissen über Scrum hinaus und da braucht man nicht bei null anzufangen, es gibt schon Wissen im Bereich Projektmanagement, Requirementsengineering, Architekturentwicklung und -bewertung, testgetriebem Entwickeln. Das mag nicht alles toll agil klingen oder sein, aber es steckt trotzdem eine Menge Erfahrung darin, die ich mir mit kritischen Blick zunutze machen kann.
Ich persönlich bin ein echter Fan von Scrum und ich mache die Erfahrung, dass damit es noch werden können wir auch in die Ausbildung links und rechts investieren müssen.
Gute Nacht, Jan.
Hallo Herr Gentsch,
Ihre Antworten auf meine Fragen haben mich zwar nicht so recht weiter gebracht, Ihre Antwort „Hallo Joachim, hallo Thomas“ barg aber zumindest einen Hinweis, wo das Missverständnis liegen könnte, den ich schon vorher vermutet hatte.
Da es hier um die Abgrenzung traditionellen PMs zu agilem PM geht, kann für mich mit traditionellem PM nur gemeint sein: „Möglichst das ganze Projekt durchplanen, dann Planeinhaltung anstreben, Änderungen als Störungen behandeln (mit Knurren und Hürden integrieren), und am Ende das Produkt am Stück liefern.“
Nicht damit gemeint sein kann für mich ein professioneller Werkzeugkasten, der beherrscht wird, denn ein solcher gehört für mich selbstverständlich zum agilen PM genauso wie zum traditionellen PM. Interessant wäre die Frage, warum jemand glauben könnte, dass Scrum alleine ausreicht – aber das scheint mir ein ganz neues großes Thema zu werden.
Ist es nachvollziehbar, dass Ihr Artikel bei einem solchen Begriffsverständnis vielleicht etwas ganz anderes bedeutet, als Sie ausdrücken wollten? Vermutlich meinten Sie gar nicht den „Big Plan Up Front“, den ich unter „traditionellem PM“ verstehe, sondern nur das Handwerkszeug? Vielleicht wird sogar der etwas arg platte Beitrag von „Go Fragile“ (ganz oben) etwas verständlich?
Dabei ist mir durchaus bewusst, dass modernes PM mehr und mehr adaptiv wird, d.h. Änderungen mehr und mehr nicht nur zähneknirschend akzeptiert, sondern adaptiert und integriert. Doch würde ich solches dann nicht mehr als „altbackenes traditionelles … PM“ bezeichnen. Vor allem verwischt es meiner Meinung nach die Denkmuster und erschwert dadurch eine genaue Analyse der Unterschiede, und in Folge evtl. sogar, was am agilen PM eigentlich anders ist.
Sie schreiben: „Eines der häufigste Probleme an denen die Einführung agiler Vorgehensweisen hängen bleibt ist aus meiner Erfahrung, dass es schlicht schon an den Basis fehlt: Ein unklarer Projekteauftrag, fehlendes Risikomanagement, ungeregeltes Stakeholdermanagement sowie ein unkontrollierter Umgang mit Änderungen. Das sind klassische Themen und auch essenziell für agiles Vorgehen.“
Nach meinem Verständnis sind genau dies aber die Probleme, die Scrum lösen möchte:
– den Projektauftrag klären (Transparenz, schnelle Rückkopplung)
– durch geschickt priorisierte iterative Lieferungen das Risiko mindern
– Änderungen annehmen und systematisch integrieren
– die Stakeholder frühzeitig einbeziehen (wieder Transparenz+Rückkopplung)
Und ich kann mir daher auch viele Umgebungen vorstellen, in denen man ganz wunderbar mit Scrum anfangen könnte und dann mittels Scrum genau die Methoden und Werkzeuge in die Organisation integriert, die benötigt werden. Klar, diese muss man dafür kennen, sonst erkennt man viele Probleme schon gar nicht und selbst wenn, müsste man Lösungen dafür erst suchen oder gar neu entwickeln – wofür man i.d.R. keine Zeit haben dürfte. So vorgehend, würde man also nicht mit etwas anderem als Scrum enden, sondern Scrum immer weiter machen und dennoch weit darüber hinauswachsen.
Allerdings sehe ich weder die eine noch die andere Form des PM als Silver Bullet für alle Organisationen und Projekte, und auch nicht als schwarz und weiß.
Alles Gute wünscht
… Michael Hönnig
p.s. wie ich den Unterschied zwischen traditionellem und agilem PM sehe, werde ich im Laufe des Tages mal in meinem Blog beschreiben
Hallo Herr Hönnig,
mir geht es nicht um eine formale Abgrenzung zwischen klassischen PM und agilem PM. Den in der Praxis ist es vor allem ein Wahrnehmungsproblem mit dem wir zu tun haben.
Der „Big Plan Up Front“ war und ist nicht Bestandteil klassischen PMs. Im Gegenteil beim PMI gibt es das Konzept der „progressive elaboration“ und auch bei der GPM gibt es die „Erste Projektplanung“ mit den Inhalten: erster Projektstrukturplan (-> inital Product-Backlog), Meilensteinplan und Detailplanung der ersten Phase (-> ~Sprintplanung).
Genausowenig, wie es beim agilen Vorgehen durchaus eine initiale Planung und Anforderungsanalyse gibt. Diese Tätigkeiten verstecken sich nur meist dezent hinter solchen Begriffen, wie Iteration 0 oder „es braucht ein intial gefülltes“ Produktbacklog.
Vor diesem Hintergrund ist mein Appell, lieber sich zuerst mit dem als altbacken, etc. _wahrgenommen_ PM auseinanderzusetzen. Denn, ich muss nicht erst mit Scrum lernen, dass wir jetzt doch noch mal den Projektauftrag klären müssten. Das haben schon Generationen vor uns gemacht. Und was ich auch für ein gefährliches Missverständnis halte, ist dass iteratives Arbeiten z.B. eine saubere Auftragsklärung ersetzen sollte. Iteratives arbeiten dient dazu, frühzeitig festzustellen, ob die Auftragsklärung geklappt hat. Das ist ein wesentlicher Unterschied.
Um es letzlich kurz und agil zu machen: Wenn ich nur eine von beiden Sachen lernen könnte und mich fragen müsste, was entfaltet in meiner Organisation wohl innerhalb des nächsten Jahres den größeren Nutzen, lautet meine Antwort: Projektmanagementgrundlagen.
Viele Grüße
Jan Gentsch
Hallo Herr Gentsch,
ist vielleicht der Vergleich von Scrum (ich werde jetzt mit Absicht konkret) zu traditionellem Projektmanagement gar nicht zulässig, weil wir dann so etwas eine Farbe mit einer Form vergleichen? Vermische ich vielleicht Elemente des Wasserfall-Modells mit dem, was ich unter „traditionellem“ PM verstehe (weil das andere für mich „modernes“ OM wäre)? Und Sie sprechen dafür im Gegenzug dem agilen PM professionelle Beherrschung von PM-Handwerkszeug ab?
Für mich definiert sich also agiles Vorgehen als:
– Anerkennung der Aussagen des agilen Manifests
– Elaboratives Vorgehen nach Prioritäten (*)
– Kenntnis und Beherrschung professioneller Praktiken und Prinzipien (**)
(* In dem Sinne wie es bezogen auf die Anforderungen ganz hervorragend von Bernd Oeterreich in der aktuellen OBJEKTspektrum beschrieben ist, d.h. bis zum _vollständigen_ Verstehen der jeweils wichtigsten Anforderungen, sprich: Implementation und Demonstration/Deployment)
(** Wobei ich die Möglichkeit sehe, dass sich diese zumindest in Projekten bis zu einer bestimmten Größe über die Retrospektiven in den gelebten Prozess integrieren lassen.)
Und traditionelles Projektmanagement ist für mich:
– Nicht-Anerkennung der Aussagen des agilen Manifests
– grundsätzlich phasenweises Vorgehen
– Kenntnis und Beherrschung professioneller Praktiken und Prinzipien
Der letzte Punkt „Kenntnis und Beherrschung professioneller Praktiken und Prinzipien“ kann aber durchaus je nach Vorgehensweise bedeuten, dass die Prinzipien und Praktiken unterschiedlich gewichtet anzuwenden sind.
Ihre Position dahingegen verstehe ich wie folgt:
für agiles PM:
– (vermutlich) Anerkennung der Aussagen des agilen Manifests
– elaboratives Vorgehen
– Unkenntnis oder Ablehnen professioneller Praktiken und Prinzipien
und bezüglich traditionellem PM:
– Elaboratives Vorgehen (vielleicht wie *?)
– Kenntnis und Beherrschung professioneller Praktiken und Prinzipien
Bitte korrigieren Sie mich.
Alles Gute wünscht
… Michael Hönnig
Kleiner Nachtrag: Auch wenn es Ihnen nicht um eine formale Abgrenzung zwischen klassischen PM und agilem PM geht, befüchte ich, dass wir ohne die Klarstellung einer solchen, keine erfolgreiche Kommunikation zustande bringen.
Wow! Dieser Blogeintrag von meinem Kollegen hat ja einiges an Diskussionen ausgelöst, die ich mir gerade noch mal am Stück durchgelesen habe.
Nun habe ich noch das Bedürfnis die Diskussion für mich abzuschliessen, indem ich einfach auf die konkret gestellten Ja/Nein-Fragen von Hrn. Hönnig antworte. Vielleicht hilft das sogar… Also:
> Meinen Sie damit, dass man die Methoden des klassischen
> PM kennen sollte, bevor man Scrum einführt?
JA
> Oder meinen Sie damit, dass man tatsächlich klassisches
> PM komplett einführen sollte, bevor man Scrum einführt?
NEIN
> Oder meinten Sie gar, dass man klassisches PM
> beherrschen sollte, bevor man Scrum einführt? Und was
> hieße dann “beherrschen”?
siehe Antworten oben.
> Und beziehen Sie sich eigentlich auf spezielle
> Projektarten/-größen oder auf alle Projekte? Und auf
> Organisationen mit welchem Ist-Projektmangement (z.B.
> von chaotisch bis strikter Durchplanung am
> Projektanfang – was wohl beides allenfalls zufällig
> funktionieren wird)?
NEIN
Mein herzlicher Dank an Björn Schneider, das waren klare Antworten, mit denen ich etwas anfangen kann und die zudem meine folgende Vermutung stützen:
Die Missverständnisse könnten entstanden entstanden sein, weil sich meiner Interpretation nach sich die Aussagen (Nicht mit Scrum anfangen…) auf die Organisation bezogen. Falls aber der Projektleiter (i.w.S.) gemeint war, sieht die Sache ganz anders aus. Zwar wäre ich immer noch nicht der Meinung, dass dieser sich VOR Scrum mit klassischem PM (i.S.v. PMI/IPMA etc.) befassen muss, aber definitiv bevor er ein nicht-triviales Projekt leitet.
Alles Gute wünscht
… Michael
Ich hatte versprochen, das Thema aus meiner Sicht in einem Blog-Eintrag zu beleuchten. Das habe ich getan … doch diesen noch nicht veröffentlicht. Der Grund dafür ist, dass ich zu der Erkenntnis gekommen bin, dass das Thema von Missverständnispotentialen nur so strotzt. Je nachdem welchen Hintergrund jemand hat, können einzelne Aussagen völlig unterschiedlich aufgefasst werden. Vielleicht wäre es wert, dazu mal einen Diskussionsabend zu veranstalten.
Alles Gute wünscht
… Michael Hönnig