Die kurze Antwort: aber klar!
Natürlich bekommt man in einer gemixten Projektumgebung (klassisch, agil; also einem ScrumBut) nicht die Effizienzsteigerungen, wie man sie in einer reinen Scrum-Umgebung bekommt. Aber eine Effizienzsteigerung ist immer drin. Wie hoch diese ausfällt hängt stark vom Commitment des Managements ab.
Das Mindset wird komplett gedreht. Die größte Herausforderung: dem Team die Entscheidungen überlassen im Vertrauen, dass die anfängliche Verschlechterung in der Performance (der Prozess muß erst gelernt werden) später in eine Effizienzsteigerung gegenüber der Ausgangssituation umschlägt. Das ist natürlich nicht einfach, wenn das Projekt schon Probleme hat bei Termineinhaltung und/oder Qualität. 3 Sprints muss man einkalkulieren, bis sich das Team eingeschwungen hat. 9 Sprints braucht es, bevor das Optimum erreicht ist. Je besser das agile Umfeld, desto besser das Ergebnis.
Eine weitere Herausforderung ist der Rollenwechsel, z.B. bei Teamleitern. Diese geben nicht mehr vor, sondern müssen zuschauen, wie die Teams erst mal in die falsche Richtung laufen, und dies ertragen, bis die Teams ihren Irrtum erkannt haben. Nur aus eigenen Fehlern lässt sich wirklich gut lernen. Für Scrum Master besteht die Herausforderung darin, immer wieder daran zu erinnern, dass der Manager zum Coach mutieren muss. Es wird nichts mehr angeordnet, sondern durch geschicktes Nachfragen in die richtige Richtung gelenkt.
Was bleibt über von der klassischen Projektleitung? Im Wesentlichen die Präsentation des Projekts nach Außen und das vom Kunden und Management geforderte Berichtswesen. Allerdings ändert sich hierbei die Ausgangsbasis. Das Scrum Team gibt hier die Schätzungen vor. Man kann davon ausgehen, dass diese Zahlen realistischer sind.
Scrum deckt übrigens gnadenlos alle Probleme auf. Wer das zu nutzen weiß, indem er ebenso gnadenlos an der Beseitigung von Impediments arbeitet, holt am Ende sogar mehr raus ;-).
Comments:
|
Die Frage ist an sich nicht, ob SCRUM im klassischen (was immer das auch sein mag) Projektumfeld geht! Vielmehr ist die Fragestellung: Geht Projekt Management auch agil? Hier ist die Antwort eindeutig: Ja! Denn die Vorgehensmodelle sind von den Management Methoden getrennt zu sehen. Auch ist SCRUM kein "Führungsmodel". Die Führung hängt an dem Vorgesetzten, und nicht an der Methodik. Dieses Führungsmodel hängt primär damit zusammen, wie das Team tickt, welche Mentalität vorhanden ist. Wenn ich Mitarbeiter habe, die unerfahren sind oder die es gewohnt sind, dass sie klare Arbeitspakete bekommen und umsetzen, kann ich eine selbstverantwortlichen Führungsstil nicht verwenden. Deswegen kann ich nur für jeden Mitarbeiter entscheiden, welche Stil der Führung ich wähle, dann für jedes Team auch im jeweils individuellen Entscheidung. Ich finde es sehr interessant, dass "klassisches Projektmanagement" erst als reines Wasserfall-System verschrieen wurde, nur als autokratischer Führungsstil. Beides ist nicht wahr. Projekt Management hat gegenüber SCRUM einen riesigen Vorteil: Ich kann sowohl das Vorgehensmodel als auch den Führungsstil anpassen, wie es die Mitarbeiter und die Aufgabe erfordert! CU Jens 
Posted by jgersdorff at 19. Mär 2012 09:11
|
|
Hier vermischen sich eine Menge von Konzepten, so das die Gefahr besteht, dass am Ende nur noch Brei herauskommt. Projekt Management ist in der Regel weder ein Führungsmodel, noch setzt es ein Wasserfall-artiges Vorgehen voraus. Es ist eine Disziplin zur Definition und Steuerung auf Zeit begründeter neuartiger Vorhaben. Hierzu haben sich im Laufe der Zeit einige Methoden, Prozesse, Skills als sinnvoll erwiesen und andere sind wieder in der Versenkung verschwunden. SCRUM ist zunächst eine Ausprägung eines agilen Managementansatzes. Dieser besteht aus definierten Werten, Prinzipien, Skills, Methoden und Ritualen (kann man auch gerne als Vorgehen/Prozess bezeichnen. Bei Anfängern liegt der Fokus auf den Ritualen (Daily Stand-Ups, Sprints, Sprint Planning, Retrospektiven), denn diese sind das Offensichtliche. Will man mit seinem Team tatsächlich wirksamer, effizienter und agiler arbeiten, dann werden Werte, Prinzipien und Skills (des Teams und des Individuums im Team) wesentlich wichtiger. Unverzichtbar ist hierbei das Prinzip des sich selbst-organisierenden Teams. Die Umsetzung aber auch Planung und Steuerung sind die Verantwortung des gesamten Teams. Dieses Modell verabschiedet sich ganz deutlich von einem Führungsverständnis, welches davon ausgeht, dass Mitarbeiter angeordnet bekommen müssten, was sie zu tun haben, aber auch von einer pädagogischen Betreuung durch eine sog. Führungskraft, die Kraft Erfahrung, Ausbildung oder Position besser wissen soll, was gut für den Mitarbeiter ist. Wer dieses Prinzip missachtet, wird am Ende nur Rituale ausgetauscht haben, hat aber dabei keine Erfolgsvoraussetzung für mehr Agilität und Effektivität geschaffen.
Posted by jhoffmann at 19. Mär 2012 12:52
|
|
Moin Jens, eben!! Das ist zu trennen. Denn wie SCRUM bei Ritualen bleibt, so bleibt das Management bei Prozessen und wird keinen Erfolg haben. Aber es ist auch wichtig, dass die Verfechter (also die nichts anderes gelten lassen) des Agilen verstehen, dass man nicht alles agil umsetzen kann oder sollte und das PM im bewährten Sinne seine Berechtigung hat. Mein Gefühl ist, dass gerade in der IT PM als veraltet gilt obwohl es selten umgesetzt wird. Und wie gesagt: Nicht jeder Mitarbeiter ist bereit oder in der Lage in selbstorganisierten Teams zu arbeiten.
Posted by jgersdorff at 19. Mär 2012 14:25
|
|
Danke für Eure Kommentare Jungs. Leider zeigt sich auch in dieser Diskussion wieder, daß klassische Projektmanager, die jetzt mit den agilen Vorgehensweisen konfrontiert werden, alten Wein in neuen Schläuchen vermuten. Die Ähnlichkeiten sind tatsächlich gegeben, aber das Mindset ist ein anderes. Wie im zweiten Kommentar erwähnt, liegt die Verantwortung für das Ergebnis beim Team und nicht bei der Führungskraft (mal als Personalverantwortlichen angenommen) oder einem Projektmanager (mal als fachlichen Vorgesetzten angenommen). Um ein vernünftiges Ergebnis zu erhalten, setzt man auf Vertrauen in die Fähigkeiten des Teams, Selbstorganisation und Eigenverantwortung, Qualitätsbewußtsein, kurz um, auf die Spezialisten vor Ort, die wirklich wissen worum es geht. Die Aussage "nicht jeder Mitarbeiter ist in der Lage..." zeigt, daß es an Vertrauen mangelt, daß nicht aus eigenen Fehlern gelernt werden darf (die einzig sinnvolle Form Erfahrungen zu sammeln) und daß jemand, der gar nicht in der Materie steckt, weil ihm die Zeit fehlt wenn er seinen Job wirklich gut macht, nämlich der Projektmanager, alles besser weiß. Dieses Weltbild bezeichne ich ganz bewußt als "klassisch". Es wurde bereits in Studien dargelegt, wie schlecht die Erfolgsquote dieses Ansatzes ist. Genauso wurde dargelegt, daß agile Ansätze, schon deshalb weil sie von einem positiven Menschenbild ausgehen, bessere Ergebnisse liefern. Sicher wird es irgendwann neue Ansätze geben, die dann agile Vorgehensweisen als klassisch titulieren werden. Aber bis es soweit ist sollten die Zweifler unter den Projektmanagern agile Methoden wirklich mal ausprobiert haben. Allerdings erst nach dem sie das Mindset der agilen Vorgehensweisen verstanden haben. Sonst ist das zu erwartende Ergebnis tatsächlich schlimmer als die klassischen Ansätze. Leider passiert dieses schlampige Vorgehen viel zu oft und muß dann auch noch als Beweis herhalten, daß die agilen Vorgehensweisen nichts taugen. Ein interessantes Indiz in diesem Zusammenhang ist die Verwendung des Begriffs "agil". Jene, die das Prinzip nicht verstanden haben, erwarten "mehr Geschwindigkeit" bei der Umsetzung. Die anderen einfach nur effizientes Arbeiten, in dem alles weggelassen wird, was unnötig Zeit verschwendet, wie Vorausplanung über längere Zeiträume, Erstellen von endlosen Spezifikationsdokumenten, wöchentliche Statusberichte, usw. - eben all das, was klassische Projektmanager so lieben, pardon, für sinnvoll erachten
Posted by rainwebs at 19. Mär 2012 23:39
|
|
Moin Rainer, Wenn ich von den Beleidigungen mal absehe, verstehe ich aber vor allem, dass Du in Deinem Post eben genau mich bestätigst, nämlich den Vorurteilen gegenüber Projektmanagement, ohne wahrscheinlich je ein funktionierendes erlebt zu haben. Ich habe Projekte erlebt, in denen ich zum Team kam und gemerkt hatte: Hier macht das Team alles alleine, ich muss ihnen nur den Rücken freihalten!" . Das andere Teilprojekt war aber gänzlich anders. Das verlangte klare Vorgaben. Ich kann zum Teil die Vorurteile verstehen: Viele sogenannte Projekt Manager haben keine Ahnung von Projekt Management und deswegen scheitern auch in der IT soviele, die sich so nennen ohne es an sich zu sein. DAS ist ein großer Teil des eigentlichen Problems. Diese Flexibilität gilt es zu erhalten. Dogmen oder orthodoxes Verteidigen von bestimmten Methoden oder Vorgehensmodellen führen in Fallen... oder oft auch in Sackgassen. Ergo: Genau dahin, was die Verteidiger der agilen Methoden dem "klassischen Projektmanagement" eigentlich vorwerfen. Ich pre-judiziere kein Vorgehen. Ich schaue mir die Rahmenbedingungen an und entscheide mit Team und Auftraggeber dann das Vorgehensmodel. Btw: Statusberichte und Controlling gehen bei mir in 30 Minuten/Woche. CU Jens
Posted by jgersdorff at 20. Mär 2012 08:24
|
|
Hallo Rainer, ich hab mich ja schon als Integrationist geoutet (s. Projektmanagement 3.0) - ich bin ganz klar für eine Kombination aus Scrum/Critical-Chain/Kanban. Das Einzige was zu dem Thread IMHO hinzuzufügen ist - ist ein kleine Korrektur "Natürlich bekommt man in einer gemixten Projektumgebung (klassisch, agil) nicht die Effizienzsteigerungen". Das würde ich so nicht unterschreiben. Zum einen fallen wir alle in die Testimonial-Fall. Wir veröffentlichen ja nur die positiven Beispiele, die negativen verschweigen wir dann doch ;-) Und zum anderen gibt es zu Critical Chain und Theory-of-Constraints Testimonials, die Scrum bei weitem in den Schatten stellen. Gerade in gemischten Umgebungen!
Mein Favorit ist aber immer noch Critical Chain in der Baubranche in Japan Ich kenne David Updegrove persönlich - er war auch bei uns bei der 1&1 und hat hier die Entwicklung in Gang gesetzt. Interessanterweise hat diese dann erst ermöglich auch Scrum/Agil im großen Stil zu implementieren - Mix-Model
Posted by wmueller at 08. Apr 2012 23:18
|
|
Moin Wolfram, genau das bin ich auch: Du nennst es Integrationist, Ich nenne es Hybrid. Mit PM 3.0 komme ich auch sehr gut klar Ich denke, eine "Festlegung ist wenig hilfreich, und weder der Aufgabe, dem Sponsor und seiner Organisation noch dem Team gegenüber angemessen. Was Du über Großprojekte schreibst liegt Dich an der Realität. Jedes Teilprojekt, jede Phase kann anders ticken. Sich darauf einzustellen ist die Aufgabe eines PM und ist mit fertigen Rezepten nicht zu gewährleisten. Auch ist eine Initiale Planung und Kozeption oft von Näten, da der Auftraggeber die Kosten vorher wissen will, da er Mittel bereitstellen muss. Umsetzungsmethoden sind Sach- & zusatndbezogen dann zu wählen und anzupassen. Ein mitdenkendes Team ist hier eine tolle Hilfe, aber nicht immer vorhanden. Jens
Posted by jgersdorff at 09. Apr 2012 12:55
|
|
Zitat: "Wie im zweiten Kommentar erwähnt, liegt die Verantwortung für das Ergebnis beim Team und nicht bei der Führungskraft (mal als Personalverantwortlichen angenommen) oder einem Projektmanager (mal als fachlichen Vorgesetzten angenommen)." Gibt es echt Projektmanager (oder Manager) die die Verantwortung für das (Projekt-)Ergebnis beim PL sehen ? Soweit mir das in der Vergangenheit passiert ist, habe ich hier gleich einen Riegel vorgeschoben, bzw. klare Verantwortung (accountable) definiert. Dabei gehe ich auch in die Diskussion bei fest definierten Vorgehensmodellen beim Kunden. Grds. geht gar nicht: Verantwortung ohne Kompetenzen (das nenne ich mal "Klassiker", begegnet mir immer wieder....). Zitat "Sicher wird es irgendwann neue Ansätze geben, die dann agile Vorgehensweisen als klassisch titulieren werden." Was heisst schon klassich ? Welches Vorgehen muss wie alt sein um ein Klassiker zu sein ? Wenn ich an mein ersten Projekt zurück denke, dann war der Projektplan 80 Zeilen lang, das größte Arbeitspaket bestand aus 80 PT, 4 Gruppen a 4 Mitarbeiter und ich habe mich nie in die Lösungserarbeitung eingemischt (hatte auch nicht die Zeit dazu), denn mit dem "PM-Kram" (inkl. Politik) hatte ich genug zu tun und ja, davon habe ich das Team verschont. Das war 1999....
Posted by rsagb at 13. Sep 2012 21:10
|
|
In Softwareprojekten habe ich gute Erfahrungen mit PRINCE2 als Managementmethode und SCRUM für die Erstellung der Spezialistenprodukte gemacht.
Posted by rsagb at 13. Sep 2012 21:12
|
|
Hallo zusammen, eine spannende Diskussion, die bei mir so einige Fragen aufwirft: Ist die Verbindung eines flexiblen Mindsets mit Scrum zwingend? Oder kann ich auch mit vermeintlich klassischen Projektmanagement-Methoden (etwa dem Gantt-Diagramm) ein flexibles Mindset haben? Schon seit Jahren tue ich mich an dieser Stelle schwer mit unserem allgemeinen Verständnis von Planung. Ein Plan ist nichts anderes, als dass ich meine Gedanken, die ich mir eh mache, auf eine bewährte Art und Weise zu Papier bringe (siehe u.a. auch "Projektplanung ist Denken"). Das hilft mir im Verständnis und dem Team in der Kommunikation. Noch besser wird dieses Nachdenken, wenn ich mein Team hinzuziehe und wir gemeinsam denken. Wir überlegen, wie es uns mit gegebenen Rahmenbedingungen gelingen KÖNNTE die vereinbarten Projektziele zu erreichen. Der Zweck eines Plans ist nicht die Einhaltung des Plans. Ein Plan ist ein Hilfsmittel, um Ziele zu erreichen. Das ganze System zur Umsetzung des muss dabei darauf ausgelegt sein, dass es mit Änderungen klarkommen wird. Diese wird es zwangsweise ergeben. Was liegt dabei näher, als bei anstehenden Änderungen, Erkenntnissen, Abweichungen das Team zu fragen, wie man damit umgehen will? Das Team vereinbart dann die weitere Vorgehensweise. Der Projektleiter bringt die dazu nötigen Menschen an einen Tisch, moderiert, liefert die Daten. In einem echten Projekt kann er gar nicht von allen Fachgebieten Ahnung haben, die zur Problemlösung nötig sind. Auf all diese Themen liefern sowohl "klassisches PM", Critical-Chain wie auch SCRUM Antworten. Verschiedene Antworten. Aber ein "flexibles Mindset", eine anpassungsfähige Grundhaltung, kann ich mit allen Instrumenten umsetzen. Diese ist für mich nicht zwingend mit SCRUM verknüpft. Dasselbe gilt für das Einbinden des Teams. Ohne Team bin ich als Projektleiter gar nichts. Und ein Team tut sich ohne mich als Projektleiter schwer, da ich dafür sorge, dass die Zusammenarbeit gut gelingt. Mit den besten Grüßen Holger
Posted by hzimmermann at 24. Jan 2014 11:48
|
|
Sehr schöne Zusammenfassung auch der Hinweis/Link - Projektplanung ist Denke gefällt mir sehr gut ... egal welche Art von Planung - das Denken ist das, das Spass macht Die letzen Posting sind ja schon eine Weile her ... bzgl. Integration von agilen Methoden und Projekten ist viel passiert. Das interessanteste war für mich (und für viele andere) - die Idee, dass es sich um 3 Ebenen handelt mit denen wir zu tun haben. Ich hab das das erste mal auf der TOCICO Weltkonferenz zeigen können: Die textuelle und ausführliche Beschreibung findet sich in "Tame the Flow", das zusammen mit Steve Tendon (ehem. Entwicklungsleiter bei Borland) entstanden ist. Da steckt noch viel viel mehr drin https://leanpub.com/u/wolfram-mueller Cu Wolfram
Posted by wmueller at 25. Jan 2014 13:45
|
|
Hallo Holger, die Frage ist nicht das Tool, sondern die Dnek die dahinter steckt. Ergo: Wenn due ein Gantt haben möchtest, was willst du damit machen und kommunizieren? Die Antwort darauf ist entscheidender als das Werkzeug. Das Problem bisherigen Planverständnisses, gerade in der IT, ist das skalvische Festhalten am Plan. Wir sind bei software ja nicht im Fregattenbau, wo 60 bis 150 Moante geplant wird (so der Vortrag beim PM-Forum 2013). Manches macht Sinn, manches nicht. ...kommt darauf an. Viele Grüße Reiner “Adapt what is useful, reject what is useless, and add what is specifically your own.” - Bruce Lee
Posted by rsagb at 26. Jan 2014 16:16
|
|
Der agile Projekt Manager geht nicht davon aus, dass ohne ihn nichts geht. Er sieht sich als Servant Leader, der sich um einen stabilen Projektrahmen kümmert, damit das Umsetzungsteam ungestört selbstorganisiert arbeiten kann. Vom Mindset ist er genauso aufgestellt wie der Scrum Master und der Product Owner. Er focussiert sich lediglich auf die Aufgaben im Projekt, die die anderen beiden nicht abdecken, wie Projekt aufsetzen und abschliessen, Budget und das damit für das Management verbunden notwendige Controlling, Staffing, etc. Du kannst ja mal in mein Blue Scrum schauen, da ist das noch etwas ausführlicher beschrieben. Insbesondere die agilen Werte sind hierbei interessant.
Posted by rainwebs at 27. Jan 2014 08:10
|
|
Hallo Reiner, in der Tat ist es die Denke und nicht das Tool, das den Unterschied macht. Und die Haltung, möchte ich anfügen. Ein Gantt-Diagramm ist für mich lediglich eine bewährte Möglichkeit, Gedanken zur Vorgehensweise zu Papier zu bringen. Damit fallen Diskussionen und Abstimmungen leichter, wie auch das Nachvollziehen der Erkenntnisse in einem zeitlichen Abstand zur Planerstellung. In diesem Sinne habe ich noch nie verstanden, woher die Annahme stammt, dass der Sinn und Zweck eines Plans sein soll, diesen Plan exakt umzusetzen. Ein Plan ist für mich ein Hilfsmittel, um die Projektziele zu erreichen. Der Projektleiter ist derjenige, der dafür sorgt, dass sich ein Team die Gedanken macht, dass die Gedanken visualisiert werden, dass die Abstimmung erfolgt und er sorgt dafür, dass bei Abweichungen der Realität gegenüber dem Plan sinnvolle Reaktionen eingeleitet werden. Entsprechend habe ich ebenfalls nicht verstanden, woher die weitere Annahme kommt, dass der Projektleiter alles wissen muss und Kommandos verteilt (siehe auch Zum Hausbau mit Software: Scrum und Klassik integriert). Ein dickes "Danke" an die Runde für die immer wieder spannenden Argumente auf openPM! Beste Grüße
Posted by hzimmermann at 29. Apr 2014 09:54
|
Deswegen "wehre" ich mich immer so, wenn es heißt, dass Project Management sei nur Wasserfall oder eine bestimmte Art von Führungsstil.
.