SCRUM: Mal eben ein Mindset Change? (Text)

Diese Episode steht unter folgendem Motto:

 „Wer PmBok Guide kann, kann ganz schnell agil. Wer nur agil kann, hat einen langen Weg vor sich, PmBok zu können!

Haben Sie auch schon mal darüber nachgedacht? Einfach mal das Mindset wechseln? So nach dem Motto: Ab heute bin ich kein Choleriker mehr, ab heute ruhe ich in mir selbst. Besitzen Sie überhaupt ein Mindset? Natürlich, jeder Mensch besitzt ein Mindset, manche sogar zwei. In dem Fall spricht man aber von einer Persönlichkeitsspaltung, auch als dissoziative Identitätsstörung bekannt. Ist aber nicht unser Thema!

 

Kann man überhaupt sein Mindset austauschen oder neu programmieren? Da Ihr Mindset ursprünglich im Rahmen Ihrer Sozialisation programmiert worden ist, lässt es sich durchaus umprogrammieren. Es handelt sich dabei um Ihre Einstellungen, Werte oder Weltanschauungen. Allerdings ist der Aufwand erheblich, aber manchmal sinnvoll. Aber, es lässt sich umprogrammieren, das ist sicher. Das bestätigt auch Bruce H. Lipton, ein amerikanischer Zellbiologe  in seinem Buch „Intelligente Zellen“.

Der Begriff „Mindset“ wird inzwischen schon genauso inflationär verwendet wie der Begriff „Nachhaltigkeit“, ursprünglich nur verwendet im Kontext „Umgang mit natürlichen Ressourcen“.

 

Fragt man bspw. einen Vertreter des agilen Projektmanagements, was der eigentliche Unterschied zwischen dem klassischen (prognostizierten) und dem agilen PM ist, antwortet er, „ja….das ist ein neues Mindset“. Soll sagen, wir arbeiten nicht mehr Plan getrieben sondern Wert getrieben. Ebenso weg von Command&Control hin zu selbstorganisierten Teams.

 

Schon bei dieser Unterstellung,  „Control“ als Kontrolle zu interpretieren, wird der manipulative Charakter agiler Argumentation deutlich. Das ärgert mich sehr. Zumindest die Methodenlehre des klassischen Projektmanagements kennt in der Führung von Teams schon seit mindestens 20 Jahren keine Kontrolle mehr. Projekte müssen überwacht und gesteuert werden, ob nun durch einen Projektleiter, der sein Team partizipativ führt, oder durch ein selbstorganisiertes Team. Das hat nichts mit der Kontrolle der Mitarbeiter zu tun.

Der Projektmanager, der sich in die Rolle des Primus inter pares fügt, ist ebenfalls ein alter Hut. Wenn es den Ansatz der Kontrolle gibt, dann nur in Unternehmen, die das tayloristische System nie überwunden haben. Das ist nicht die Maxime des klassischen PM.

 

Und zu implizieren, dass das Mindset des einzelnen Mitarbeiters mit der Einführung agilen PMs, mal eben einen Wechsel erfährt, grenzt schon an der Überzeugungskraft eines Heizdecken Verkäufers auf Kaffeefahrten für Rentner.

 

Auch die überspannte Ansicht über Planung und Zielbildung, entspricht nicht der Realität. Geplant werden muss auch in agilen Projekten. Die Planungsintervalle sind nur kürzer.

 

 Da fällt mir immer die Anekdote des Bahnkunden ein, der auf dem Bahnsteig auf einen verspäteten Zug wartet. Als ein Bahnschaffner vorbei kommt fragt er ihn leicht echauffiert

„warum macht ihr denn Pläne, wenn die Züge sowieso zu spät kommen“, antwortet der Schaffner, „damit wir wissen, ob und wie oft die Züge zu spät kommen“. Ein Plan hat also den Vorteil, dass er Abweichungen aufzeigen kann, Abweichungen, die nach dem „Warum“ fragen und die Grundlage einer Lernkurve bilden können.

Formeln des EVM

Das auch klassisches Projektmanagement „Wert getrieben“ das Überwachen und Steuern eines Projekts favorisiert, und das schon seit mehr als 20 Jahren, sollte den meisten agilen Ohrenbläsern auch bekannt sein. Earned Value Management, (EVM) dass im PmBok Guide mit fast 7 DIN A4 Seiten den höchsten theoretischen Anteil hat, stellt den Wert eines Projektliefergegenstands in den Mittelpunkt seiner Betrachtung. Ab dem Anfang der Generierung des Produkts, wird die Wertschöpfung des Liefergegenstands konsequent bewertet und beurteilt. Kommt es zu Ereignissen, die ein Delta zwischen der erbrachten Leistung und dem Grad der Wertschöpfung aufzeigen, werden Steuerungsmaßnahmen ergriffen, die auf einer Analyse der Anforderungen aus Sicht des Kunden sowie einer Analyse der bisherigen Leistungserbringung basieren. Vor diesem Hintergrund, wird nicht nur eine Lernkurve just in time forciert, sondern auch eine antizipierende Lernkurve, die aus Sicht des PMI, eine signifikante Kernkompetenz modernen PM darstellt.

 

Wenn also EVM nicht betrieben wird, liegt das nicht am klassischen PM, es liegt an der PM Kultur der Unternehmen.

Klassisches Projektmanagement kann daher beides: „Prognostizierendes PM“ und „Rolling Wave Planning PM“. Rolling Wave Planning (RWP) als Methode gab es schon lange bevor der Hype des agilen PMs über den Teich schwappte. RWP impliziert, dass der Scope eines Projekts nur insoweit geplant wird, wie er bekannt ist und nicht mehr die Gefahr birgt, kostenintensiven Veränderungen zu unterliegen. Schon hier galt der intensive Kontakt zum Kunden. Wenn man dann noch das EVM mit einbezieht, das Terminplanvorgänge bis zu 4 Wochen Länge vorschlägt, hatte man auch schon bisher die Körnung eines Sprints. Obendrein bietet EVM Retrospektive just in time. Anhand der Peaks von CPI und SPI lassen sich ganz hervorragend positive und negative Ereignisse aufzeigen, die schon aktuell eine Lernkurve über das Projekt und dessen Verlauf zulässt.

Peter F. Elzer sagt in einem Interview von GPM:

„Wenn man in 75 Jahre alten Bautagehandbüchern meines Großvaters nachliest, findet man Methoden, die einem heute als neueste Errungenschaften aus Übersee verkauft werden.“

Um diese agile Philosophie, Wert getrieben ein Produkt zu generieren, zu internalisieren, also zu verinnerlichen, bedarf es zumindest einer minimalen Gehirnwäsche der beteiligten Klientel. Wenn klein Scrummi nämlich gelernt hat, dass eine gute Planung Risikoereignisse und Pleiten verhindern kann und gute Ziele die Fokussierung und Motivation erhöhen können, dann muss er sich jetzt ein wenig umstellen. Wobei in agilen Projekten natürlich auch Planung stattfindet. Eben nur in kürzeren Intervallen.

Ich stelle jetzt hier nicht die Sinnhaftigkeit agiler Frameworks in Frage, nein, ich sehe durchaus die Notwendigkeit in manchen Anwendungsbereichen agil zu agieren, aber eher agil mit einer klassischen Metaebene oder einem vertikalen Fundament ausgestattet, wie es jetzt vom PMI mit dem Agile Certified Practioner praktiziert wird. 

Das System Mensch

Das System „Mensch“ wird im agilen Mindset einfach zu wenig berücksichtigt. Überall wo Menschen in Prozessen involviert sind, spricht man von „nicht trivialen Prozessen“. Prozesse die nur Maschinen oder IT enthalten, werden dagegen als trivial bezeichnet. „Nicht triviale Prozesse“ unterscheiden sich von trivialen Prozessen in ihrer Komplexität, aber nicht in ihrer Kompliziertheit. Das agile Mindset trivialisiert aber menschliche Einstellungen und Handlungsweisen und meint, erwachsenen Menschen mal eben ein neues Mindset einpflanzen zu können.

 Das agile Mindset auf der kognitiven Ebene ist vergleichbar mit den chemischen „Kampfstoffen“, die wir auf unsere Äcker ausbringen. Auch hier wurde trivialisiert. Man meinte, wenn man Stoffe entwickelt, die das Unkraut vernichten, das Korn aber leben lässt, können wir die gesamte Landwirtschaft effizienter machen. Dass über dem Kornfeld, in dem Kornfeld und unter dem Kornfeld ein interdependentes System an Mikroorganismen und Insekten tätig ist, die ein nachhaltiges Pflanzen und Ernten erst möglich machen, hat man bei der Strategie des Unkraut Vertilgens nicht berücksichtigt.

Sie meinen, der Vergleich hinkt? Zwei Beispiele:

 

1.      Beispiel: Letztens erzählte mir ein Mitarbeiter aus einem agilen Team, dass einer der Teammitglieder pünktlich kommt und pünktlich geht. Auch wenn das Team gerade in einer extrem kreativen Schaffensphase, der Lösung des Problems schon sehr nahe ist, lässt der Mann pünktlich seinen Kugelschreiber fallen und macht Feierabend. Jetzt ist es aber nicht so, dass die restlichen fünf Teammitglieder konstruktiv weiter arbeiten. Zwei der Teammitglieder sind jetzt durch das Verhalten des „Gehenden“ so frustriert, dass jegliche Kreativität über den Jordan geht und die Gruppe entnervet die Lösung des Problems verschiebt.

 

2.      Beispiel: Ein hoch kompetenter aber leicht introvertierter Entwickler muss sich ständig mit einem extrem Macht orientierten Kollegen auseinandersetzen, der seine innovativen Vorschläge  rhetorisch zerlegt. Der SCRUM Master schaut der Sache hilflos zu. Der Entwickler kündigt irgendwann entnervt. Das Team muss diesen Entwickler  jetzt ersetzen, was Zeit, Geld und neue Teamentwicklungsmaßnahmen zu Folge hat.

Ich möchte diese beiden Beispiele tiefer begründen: Carol Dweck, eine amerikanische Wissenschaftlerin,  entdeckte in Ihren Studien mit Schülern, dass es Menschen mit einem starren Mindset und Menschen mit einem dynamischen Mindset gibt. Dynamische und starre Mindsets unterscheiden sich nicht durch den Intelligenzquotienten. Nein, sie unterscheiden sich in der Herangehensweise beider Gruppen an eine Problemlösung und diese Herangehensweise ist extrem unterschiedlich geprägt.

 

Menschen mit dynamischen Mindsets haben die Fähigkeit, einen Lösungsprozess mit Höhen und Tiefen zu durchlaufen ohne zu resignieren oder aufzugeben. Menschen mit einem starren Mindset dagegen, benötigen sehr schnell die Lösung und die entsprechende Selbstbestätigung, sonst geben sie auf oder sind frustriert.

 

McGregors Theorie X und Y zeigt in eine ähnliche Richtung. Es existieren nun mal zu einem bestimmten Anteil X Menschen, die salopp formuliert, gerne einen großen Bogen um die Arbeit machen.

 

McClealands Motivationstypen

 

Wenn man jetzt noch die Theorie der Motivation von David Mcclelland hinzunimmt, dann wird ein Team von 4 – 7 Mitarbeitern dermaßen heterogen und nicht trivial, was deren Motive angeht, das metakognitive  Denken, das soziale Bewusstsein, die Machtmotivation, die Kontrollbedürfnisse  etc., etc., so dass die oberste agile Maxime, selbstorganisierte Teams zu erzeugen, durch diese Diversifikation und unterschiedlicher menschlicher Mindsets, stark leidet oder gar unmöglich macht.

Ich frage Sie: Wie sollen in einem selbstgesteuerten Team, das nur mit einer „guten Seele“, dem SCRUM Master ausgestattet ist, ohne dieses Wissen sozialer Interaktionen und Motivationstypen, zu passablen Ergebnissen in Time&Budget kommen, wenn es da nicht jemanden gibt, der auf einer Metaebene, auch ausgestattet mit einer gewissen Autorität, lenkend Einfluss nimmt?

 

Das Schwarm Mindset

Agilität wird immer gerne mit Schwarmdenken verglichen. Ein riesiger Fischschwarm wechselt wie auf Befehl die Richtung im Sekundentakt.

 

Wie sieht es in agilen Teams aus? Agieren so agile Teams? Richtungsänderungen im Sekundentakt? Das verlangt kein Mensch! Aber bezüglich der gerade beschriebenen Heterogenität von Teams, ist das gemeinsame agile Mindset reines Wunschdenken oder zumindest eine strategische Herausforderung, die nur selten in High Performance Teams mündet. Insbesondere wenn man in zunehmenden Maße wahrnehmen kann, dass Kompromisse oder Konsens in allen gesellschaftlichen Bereichen immer schwieriger werden.

 

Jetzt werden Sie einwenden „ja aber in agilen Teams handelt es sich fast immer um Konsensbildung auf der Sachebene.“

Tatsache ist, die Beziehungsebene dominiert die Sachebene. D.h. die oben beschriebenen Facetten eines Mindsets, nehmen auch immer Einfluss auf die Sachebene. Wenn es in den meisten Fällen noch um Konsensbildung bezogen auf das „Was“ gehen würde anstatt um das „Wie“. Es geht aber häufig um das Wie. Und in diesem Kontext, tun sich weit mehr Ursachen zur Uneinigkeit auf, als bei der Lösung eines Was.

 

Erst letztens habe ich den Satz gehört, „seitdem wir agiles PM eingeführt haben ist alles viel stressiger geworden“. Den Stress lösen aber nicht neue – oder besser gesagt umgeformte – Werkzeuge und Methoden wie ein Sprint, eine Retrospektive oder ein daily SCRUM aus. Der Stress ergibt sich über den fehlenden Konsens bspw. bei der Feststellung eines Problems innerhalb einer Retrospektive, und deren Neuansatz für den nächsten Sprint besser einzuplanen. Da kann es zu Abend füllenden Diskussionen kommen.

 

 

Was fehlt im agilen PM, ist eine starke Führung. Die kann sich natürlich auch in einem SCRUM Team herauskristallisieren. Der SCRUM Master ist hierarchisch auf derselben Ebene wie die Teammitglieder angesiedelt. Er ist eine Art Kümmerer. Trotzdem kann er analog zur Entwicklung eines informellen Führers auch diese Rolle erlangen. In Teams entwickelt sich immer ein informeller Führer, häufig auch als Meinungsmacher bezeichnet. Entweder als zweite Person oder in Personalunion des SCRUM Masters oder des Projektleiters. 

Problematisch ist es, wenn der informelle Führer durch ein anderes Mitglied im SCRUM Team besetzt wird. Dies ist in klassischen Projekten, in denen der Projektleiter häufig auch disziplinarisch tätig ist, natürlich auch der Fall. Aber hier wird der Projektleiter nicht zur Nebensächlichkeit. Er hat eine formale Position.

 

Das kann einem SCRUM Master schon eher passieren, zur Nebensache zu werden, dem niemand mehr zuhört. Natürlich gilt es auch für die Rolle des Projektleiters, falls er selbst die Rolle des informellen Führers nicht in Personalunion wahrnimmt, die Rolle des informellen Führers gekonnt in seinem Stakeholdermanagement zu integrieren. Darüberhinaus involviert seine Rolle als Vorgesetzter zusätzliche Werkzeuge, die es ihm besser ermöglichen Einfluss zu nehmen, trotz eines informellen Führers.

Fake Blogging!

 

Wie schon betont, es geht nicht darum agiles PM zu diskreditieren. Es geht darum, die agile Rhetorik zu fokussieren, die klassisches PM in vielen Facetten verunglimpft oder so tut als wäre agiles PM dem klassischen PM überlegen.

Das Ziel der extremen Agilisten ist ein Verdrängungswettbewerb. Zumindest erwecken viele Formulierungen diesen Eindruck.

Klassisches Projektmanagement wird aus der agilen Argumentation heraus mit diversen negativen Begriffen besetzt, oder es wird so getan, als ob es die  „super neuen“ Erkenntnisse  des  agilen Projektmanagements vorher nie gegeben hat. Ich nenne das Fake Blogging. Es werden Behauptungen aufgestellt, andere übernehmen diese und tragen sie weiter, und wenn diese Behauptungen oft genug wiederholt werden, irgendwann glauben es alle.

 

Folge: Die Diskussion bestimmter Probleme die seit 20 Jahren bekannt sind, erscheint jungen Projektleitern hochaktuell und neuartig.

 

Nur wenn man dieses Fundament, oder genauer gesagt dieses vertikale Fundament, nämlich eine stabile Wand, und da gehört ein Frame normalerweise dran, nie verinnerlicht hat, ist man manipulierbar und denkt agiles PM ist das Maß aller Dinge.

 

Beispiel: Herr Christian Vogel vom openpm Team schreibt zum Thema Matrix Ansatz in SCRUM Teams: „Wäre nicht der “richtige(re)” Weg, lieber Prioritäten zu setzen und die Aufgaben sequentieller abzuarbeiten Sprich, wir machen jetzt Projekt 1 und 2 fertig, danach Projekt 3, dann Projekt 4 und 5. Anstatt in allen 5 Projekten gleichzeitig zu arbeiten? Meine Erfahrung ist, dass bei zu vielen Aufgaben parallel der Output sowieso runtergeht, analog dazu die Mitarbeitermotivation. 

 

Da hat er Recht, der Herr Vogel! Muss man aber immer erst selbst die Erfahrung machen um es besser zu machen? Die Problematik des Ressourceneinsatzes, gleichzeitig in mehreren Projekten eingesetzt zu werden, hat Eliyahu Goldratt schon 1997 in seinem Buch „Die kritische Kette“ vor dem Hintergrund des klassischen PM erörtert. Dort wird es als „Multitaskingproblem“ beschrieben, dass innerhalb eines Projekts auftreten kann, aber auch über den Einsatz einer Ressource über mehrere Projekte hinweg. Goldratt sah in dem Multitasking einer Ressource, die Produktivität der Ressource erheblich reduziert.

Und 2 oder 3 Jahre später flossen diese Erkenntnisse in den PmBok Guide von PMI ein und sind seitdem Teil der PMP Prüfung. Ein PMP zertifizierter Projektmanager wird in seiner Projektumgebung dieses Problem immer antizipierend thematisieren!

 

In dieser Diskussion referenziert Herr Jens von Gersdorf dann auch die Erfahrungen von Herrn Vogel in Richtung PmBok Guide:

 

„Gemäß dem Matrixmodel PMI bin ich der festen Überzeugung, dass Projekte (egal welches Vorgehensmodel) erst ab balanced matrix, besser ab strong matrix funktionieren können.

 

Desweiteren werden unglaubliche  Leistungssteigerungen durch SCRUM im Vergleich zum klassischen PM betont.! Herr Rainer Eschen sagt in der Diskussion von openpm bspw.:

 

„Jeff Sutherland beschreibt es ungefähr so: ausgehend von einem klassisch gemanagten Projekt bei einer Leistungssteigerung von mindestens 30% entspricht einem ScrumBut. Alles ab 200% bis 800% entspräche dann Scrum. Da Boris Gloger von 200%-300% Steigerung innerhalb der ersten Sprints spricht, sehe ich das derzeit als den realistisch anzupeilenden Korridor an.

Ein SRCUMBUT beschreibt ein Element, was nicht eindeutig dem SCRUM Framework zugeordnet werden kann. “Wir benutzen SCRUM, but…”. Nach dieser Definition, sind etwa 95% des PmBok Guides positive Scrumbuts.

Wer glaubt denn solche Leistungssteigerungen? Wie werden die denn gemessen? Herr Victor Frank bringt es auf den Punkt:

 

„Ich kenne diese Zahlen und finde es mittlerweile ganz lustig. 800% im Vergleich zu was? Zu einem planungsgetriebenen Projektmanagement? D.h. das ein 100PT-Projekt mit gleichen Personen, mit gleichem Scope, etc. dann mit 12,5 PT realisiert wird?“

 

 

Ebenso trägt die Strategie, durch eine Art „Verakademisierung“ und  einem intellektuellen Aufhübschen der agilen Theorien dazu bei, jungen Projektleitern, eine erhebliche Überlegenheit des agilen dem klassischen PM gegenüber, zu suggerieren. Wiederum Herr Rainer Eschen sagt:

 

Scrum hat aber eigentlich das Ziel “High-Performance-Teams” zu schaffen.

 

Diese Aussage suggeriert auch wieder so eine Art „Umkehrhetorik“. Wobei das nicht das Ziel von SCRUM ist, da liegt Herr Eschen falsch.

Also wenn ich nach Hause komme und meiner Frau erzähle ich bin ein Member in einem High Performance Team, würde sie vor Ehrfurcht erstarren. Nein, das glaube ich eher nicht, sie würde sagen „ja ja, setzt Dich mal dahin und iss Deine Suppe“.

 

Von den über 1000 Projektleitern die ich ausgebildet habe, kenne ich nicht einen, der sich in einem „High Performance Team“ wähnte. 

„Kein Wunder“ sagt jetzt der Agilist ironisch, „es ging ja auch um klassisches PM“.

Aber auch die Aussage von Herrn Eschen erzeugt den Eindruck, „High Performance Teams“ sind nur mit SCRUM möglich.

 

Im klassischen PM gab es von jeher den Ansatz, Teams unter der Maxime der gruppendynamischen Entwicklungsstufen zu bilden (PmBok Guide 6th, S.338) also Teams hoher Produktivität zu bilden. Wenn diese Methoden  nicht umgesetzt werden, liegt es nicht am klassischen PM, es liegt an der Unternehmenskultur oder dem Reifegrad des Projektmanagements im Unternehmen. Das Problem, was den agilen Ohrenbläsern in die Hände spielt ist, dass in den meisten Unternehmen weltweit, immer noch PM aus dem Ärmel praktiziert wird. Die agile Rhetorik greift solche Mankos natürlich gerne auf, um diese vermeintlich fehlenden Methoden und Werkzeuge, dem klassischen PM in die Schuhe zu schieben. (Sehr guter BLOG zu High Performance Teams)

 

Sicherlich gibt es das ein oder andere „High Performance Team“, z.B. in der NASA, im Raumschiff Enterprise oder im Profisport oder auch mal rein zufällig in dem ein oder anderen Projekt, weil sich dort eine Teamkonstellation ergeben hat, die optimal interagiert und über sich hinauswächst. Das sind aber Ausnahmen! Da wird auch SCRUM oder XP nichts dran ändern. Auch der PmBok Guide kennt im Prozess 9.3 die Vorabzuweisung von Ressourcen um eine optimale Personalstruktur für ein Projekt zur Verfügung zu stellen sowie weitere Teamentwicklungsmaßnahmen, um Effizienz und Effektivität eines Teams zu erhöhen.

 

In der Praxis gilt aber die Realiät: „Man bekommt die Mitarbeiter, die verfügbar oder über sind.“

Ändert sich das durch agiles PM? Ich denke nicht.

Eine weitere Aussage der agilen Rhetorik: „Agile Werte legen den Fokus auf das Wesentliche“. Auch eine Rhetorik, die dem Unwissenden suggeriert, „aha, im klassischen PM geht es also nicht um das Wesentliche, da schlägt man sich vornehmlich mit Terminen, Dokumentation und Bagatellen herum.“

 

Ob im agilen oder klassischen PM, beiderseits sind Anforderungen die zentralen Wegweiser für das zu entwickelnde Produkt und damit die Voice of Customer. Der Unterschied zwischen beiden Vorgehensweisen liegt im Wesentlichen in der anfänglichen Beschreibung der Anforderungen. Das klassische PM nutzt den USE CASE, das agile PM die USER STORY.

 

Basiert ein USE CASE etwa auf Nebensächlichkeiten? Werden bspw. unwesentliche Anforderungen im Rahmen eines Prototyps getestet?

Um die wesentlichen Anforderungen eines Auftraggebers zu identifizieren, zu beschreiben, auf Redundanzen, Widersprüchlichkeit oder auf Machbarkeit etc. zu untersuchen, bietet der PmBok Guide im Prozess 5.2 acht Hauptwerkzeuge und Methoden, mit insgesamt 13 untergeordneten Werkzeugen und Methoden um Anforderungen interpretationsfrei und vollständig zu eruieren.

Diese Werkzeuge und Methoden sind auch alle verwendbar im agilen PM, also quasi SCRUMBUTS. Auch eine USER STORY muss irgendwann in spezifizierte Anforderungen umgewandelt werden. Im Gegensatz zum klassischen PM, wo sich bestimmte Anforderungen antizipierend mit dem Kunden comitten lassen, erfordert diese Vorgehensweise natürlich eine stringente Einbindung des Kunden just in time. Es handelt sich dabei aber nur um einen zeitlichen Versatz. Auch im klassischen Projektmanagement nähert sich die Voice of customer ihren Bedürfnissen erst einmal explorativ, vergleichbar mit einer USER STORY. Und auch das daraus resultierende Lastenheft, beschreibt immer noch das „WAS“ und nicht das „WIE“. Da können die Werkzeuge des PmBok Guides aber ebenso effektiv im agilen PM eingesetzt werden, wie im klassischen Projektmanagement. Bspw. eine Multi – Kriterien – Entscheidungsanalyse, ein Kontextdiagramm oder Interviewtechniken, um nur drei zu nennen.

 

 

 

Professor Dr. M. Glinz schreibt: “Der Umgang mit Anforderungen in XP besticht durch seine Einfachheit und bietet einen erfrischenden Kontrast zum Requirements Engineering in klassischen Methoden”.

 

Das Adjektiv „erfrischend“ hätte man beiseitelassen können. Auch wieder so eine Rhetorik, die das Anforderungsmanagement im klassischen PM mit einem bitteren Geschmäckle hinterlässt. Wie erfrischend es der Kunde findet, wenn seine Anforderungen nicht genau getroffen wurden, zeigt sich dann am Ende des Projekts. Der Professor räumt dann aber auch noch ein, dass der Kunde in solchen Projekten extrem präsent sein muss, das suggeriert ja schon der Name Extreme Programming, und somit XP sich primär für interne Projekte eignet.

 

 

 Und genau das ist der Punkt: Es gibt kein schwarz oder weiß! In manchen Projekten ist klassisches PM sinnvoll, in manchen Hybrid PM und in manchen SCRUM oder sogar XP sinnvoll. Aber jeder Framework immer mit dem Backround eines vertikalen Fundaments. Nur ein Framework zu lernen, vermisst jedes interdisziplinäre Handwerkszeug, das jeder Projektmanager, jede „eierlegende Wollmilchsau“ unbedingt benötigt!

Im 2. Teil dieser Episode möchte ich Ihnen aufzeigen, wie sich die Fachbegriffe und Methoden im agilen PM mit den Begriffen und Methoden aus dem PmBok Guide matchen lassen. Darüber hinaus gebe ich Ihnen einen Einblick in die Sichtweise des PMI, agiles PM im Kontext des PmBok Guides und des neuen „Praxisleitfaden Agilität“. Dieser Praxisleitfaden ist eine gemeinsame Produktion des PMI und Agile Alliance. SCRUM & Co werden da nicht ausgespart, die Frames greifen aber auf ein vertikales Fundament zurück, die „PmBok Wall“.

 

Keine Macht der Werbung! Des Autors einziger Lohn: Eine Referenz in Ihrem Netzwerk!

Hier schreibt Renee Ossowski, PMP

Werden Sie Mitglied in der XING Gruppe “SONOXO Akademie”: https://www.xing.com/communities/groups/sonoxo-akademie-8018-1100996

Sie erreichen uns jetzt auch in Facebook: https://www.facebook.com/Habitualisierung/

Buchen Sie unsere Seminare in Deutschland, Österreich oder auf Zypern.

Schreibe einen Kommentar

Menü schließen
Marquee Powered By Know How Media.