Blog | Agiles PM

Scrum Zertifizierung = Silver Bullet oder Bauernfängerei zu honorigen Honoraren? (Teil 1)

Projektmanagement existiert seit tausenden von Jahren. Ob nun Paläste, Brücken oder Pyramiden gebaut worden sind oder auch Kriege geführt worden sind : Alles hatte etwas mit Projektmanagement zu tun. Aber schon die genannten Beispiele zeigen auf, dass nicht nur „klassisches Projektmanagement“ umgesetzt wurde. Der Kölner Dom z.B., aber auch jeder Krieg wurde agil umgesetzt oder durchgeführt. Wenn der Trigger für agiles PM beim Kölner Dom eher ein gewisser laissez faire Stil (bezogen auf die Anforderungen des Bauwerks) war, bleibt einem Feldherrn im Krieg nicht anderes übrig, als das Projekt "Krieg“ agil zu führen.

Scrum

Es dürfte also auf der Hand liegen, dass klassisches als auch agiles Projektmanagement immer schon durchgeführt worden ist. Mit dem Bau der Atombombe (Manhatten Projekt) begann man aber Projektmanagement zu dokumentieren und Standards zu entwickeln. In der amerikanischen Militärindustrie wurden erste Bücher über Projektmanagement geschrieben und Trainings in Projektmanagement angeboten.

Bis Ende der 70er Jahre war Projektmanagement in deutschen Unternehmen noch kein Thema. Sogar der Begriff „Projektmanagement“ war bis Anfang der 70er unbekannt. Erste Standards und Zertifizierungen wurden dann durch IPMA und PMI eingeführt. Das klassische Projektmanagement hielt Einzug in Wirtschaftsunternehmen.

Liest man Blogs oder Artikel von Autoren aus dem agilen Umfeld, aber auch hier und da von Autoren des klassischen Projektmanagements, könnte man meinen, Projektmanagement wird immer wieder neu erfunden. 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.“

Was auch sehr problematisch ist, ist die teilweise sektiererische Sichtweise auf das klassische Projektmanagement! Aus Sicht einiger Agilisten existiert neben dem agilen Projektmanagement nur noch das tayloristische Projektmanagement. Das klassisches Projektmanagement auch durchaus nicht tayloristisch geartet sein kann, zum Beipiel postheroisch, wird ignoriert. Der PmBok Guide fokussiert schon seit mindesten 12 Jahren das Rolling Wave Planning, was nichts anderes ist, als eine agiler Ansatz.

Was mir als ehemaliger Soldat auffällt, ist die Nähe Scrums zu militärischen Methoden.

Das klassische Projektmanagement als dokumentierte Methode, fand im amerikanischen Militär seinen Ursprung. Das erkennt man auch an den noch aktuellen Begriffen wie “After action Review oder Deadline“.

Obwohl Scrum ebenfalls mit seinem Framework eine erhebliche Nähe zu militärischen Methoden beinhaltet, habe ich den Eindruck, dass man diesen Kontext möglichst vermeiden möchte. Dies impliziert auch der Begriff "Scrum". In dem Buch "Scrum - Agilität für dynamische Systeme" wird aufgezeigt, dass Scrum ein spielerisches Element aus dem Rugby darstellt. Die Erfinder versuchen hier meiner Ansicht nach Scrum eher als verspieltes Herumwimmeln darzustellen, obwohl Scrum primär ein hochdiszipliniertes Rahmenwerk mit erheblicher Affinität zu militärischen Methoden darstellt. Dieser Zusammenhang wird aber mit dem Namen Scrum etwas verschleiert. Man beachte:

  • Ein Teammitglied, das 5 Minuten zu spät beim Daily Scrum erscheint, hat 33% des gesamten Inhalts verpasst.
  • Ein Teammitglied in einem Sprint muss die Anforderungen bedienen, egal wie wiedersinnig diese zwischenzeitlich geworden sind.
  • Scrum ist hochgradig Ergebnisorientiert.
  • Home Office hat sich erledigt.
  • Während der Arbeitszeiten befindet sich das Team in einem gemeinsamen Raum. Kontakte nach außen oder umgekehrt sind unerwünscht.
  • Der "daily Scrum" ähnelt einem militärischem Briefing.

Die genannten Punkte sind nicht als Kritik zu verstehen. Es handelt sich hier um Fakten.

In dieser Leserreihe soll es von daher darum gehen:

  • Zu zeigen, dass die Elemente des agilen Projektmanagements aus dem klassischen Projektmanagement sowie den militärischen Methoden entspringen.
  • Zu zeigen, dass agiles Projektmanagement nicht im Wiederspruch zum klassischen Projektmanagement steht, sondern das beide sich gegenseitig befruchten können: Stichwort „Hybrid Projektmanagement“.
  • Was ist wirklich neu? Was ist brauchbar?
  • Das agiles Projektmanagement in bestimmten Projekten sinnvoll ist und seine Berechtigung hat.
  • Zu zeigen, dass Zertifizierungen im agilen Umfeld häufig „moderne Bauernfängerei“ sind.

Fangen wir mit dem letzten Punkt an

  • Zu zeigen, dass Zertifizierungen im agilen Umfeld häufig „moderne Bauernfängerei“ sind.

Björn Schotte schreibt in seinem Blog, Zitat:

„Ich habe selbst eine CSM und CSPO Zertifizierung. In diesem Blogbeitrag möchte ich mich über den Sinn und vor allem den Unsinn dieser Zertifizierungen beschäftigen.“

„Ein Teil der Unternehmen, die mich nach den Zertifizierungen fragen, möchten gerne eine Silver Bullet kaufen. Es gibt den Irrglauben, dass man doch nur die Grundlagen wissen müsste (denn Scrum ist ja ein sehr einfaches Rahmenwerk mit nur wenigen Regeln, Aktivitäten und Artefakten) und schon könnte man loslegen. Es sind also alle sehr schnell aufgeschlaut und können sofort loslegen.“

Um es noch einmal zu sagen: Es geht nicht darum, agiles Projektmanagement zu hinterfragen. Es geht aber um die Frage, ob Sie 2300€ für einen Guru aus den USA zahlen sollten, der Ihnen in 2 Tagen „ein sehr einfaches Rahmenwerk“ vermitteln will? Was allerdings nicht bedeuten soll, dass ich Scrum in der Durchführung als einfach einstufe. Ganz im Gegenteil! Scrum ist Projektmanagement und Projektmanagement ist hochgradig interdisziplinär. Und gerade die "nicht trivialen Prozesse", die verstärkt in Scrum Projekten vorkommen, erfordern ein hohes Maß an Führungskompetenz.

In diesem Blog soll es darum gehen, Ihnen im Vergleich PmBok Guide und Scrum aufzuzeigen, dass Scrum im Prinzip nicht viel Neues enthält und relativ leicht selbst erlernt werden kann. Ich bin seit 15 Jahren Projektmanagementtrainer (ohne agile Methoden) und habe beim Lesen der Scrum Literatur  95% nur „schon Bekanntes“ gelesen, so dass sich für mich die Formel ergibt:

Wording ausgetauscht, Werte verstärkt in den Fokus gestellt, sowie die zeitlichen Perspektiven verändert = Scrum.

In diesem Artikel soll aufgezeigt werden, dass ein Projektleiter, der PmBok kann, mit sehr wenig Aufwand auch Scrum kann. Aber ein Projektleiter, der dagegen nurPmBok Scrum kann, einen langen Weg vor sich hat, auch PmBok zu können. Scrum ist im Gegensatz zum PmBok Guide nur ein Rahmenwerk, was man sehr schnell erlernen kann.  Auch dies soll nicht als Kritik verstanden werden. Es geht darum aufzuzeigen, dass erst interdisziplinäres Projektmanagement mit seinen Werkzeugen und Methoden erlernt werden sollte, bevor man mit Scrum anfängt. Scrum ist nur ein Framework.

Abgesehen von ein wenig HTML für unsere Website, bin ich kein Softwareentwickler und hatte auch nie ein Scrum-Training. Ich schreibe diesen Blog über Scrum also aus Sicht eines Lernenden. Falls ich das ein odere ander falsch beurteile, bedanke ich mich für entsprechende Hinweise.

 

Werkzeuge und Methoden des PmBok Guides im direkten Vergleich zu Scrum

(Die Scrum Elemente orientieren sich am „Scrum Guide“ von Ken Schwaber und Jeff Sutherland sowie weiterführender Literatur)

Die Rollen in Scrum: Product Owner (PO), Scrum Master (SM) und Team

Der Product Owner (Fachvertreter, Kunde oder Stellvertreter des Kunden)

  • Vertritt die Wertmaximierung aus Kundensicht und des Business Values, ist quasi Produktbesitzer im Auftrag des Kunden
  • Verantwortlich für das Product Backlog / Erste Produktvision
  • Der PO kann selbst Entwickler sein, aber auch an ein Team delegieren
  • Falls ein Team existiert, ist er für die Transparenz gegenüber dem Team verantwortlich und ist selbst Teammitglied
  • Seine Entscheidungen müssen von der gesamten Organisation respektiert werden
  • Nur der PO definiert die Anforderungen

Laut Umgebungsliteratur ist der PO ständig anwesend. Dies impliziert aber auch der Scrum Guide, da die Aktualisierung des Backlogs im Daily Scrum ein wichtiges Element ist. Meiner Ansicht nach macht Scrum überhaupt nur Sinn, wenn der PO zum Unternehmen des Kunden gehört. Kann sich eine PO mehr mit dem Kunden identifizieren, als mit dem eigenen Unternehmen? Ich sehe da doch erhebliche Risiken bezüglich der Preisentwicklung, die erst am Ende des Projekts feststeht.

Der Scrum Master

  • Setzt Scrum Regeln und Vorgehensweisen mit dem Team um.
  • Nimmt Aufgaben gegenüber dem Product Owner, dem Team und der Organisation war.Bild: Scrum Master outet sich als Kuschelbär
  • Regelt die Kommunikation im Team.
  • Ist der eigentliche Verantwortliche für die Scrum Prozesse.
  • Befindet sich in der Rolle eine Primus Interpares.

Der "Master" im Name ist meiner Ansicht eher unglücklich gewält, da es beim Scrum Master explizit auch um Führung von Menschen geht. Der Name erinnert an Sklavenhalterei und Kreditkarten. Seine Rolle ist auch eher eine laterale Führungsrolle. "Scrum Coach" wäre z.B. die bessere Wahl gewesen.

Das Scrum Team

  • Besteht aus Produkt Owner, Scrum Master und Entwicklern.
  • Meist interdisziplinär.
  • Erledigt die Anforderungen mit dem Ergebnis einer inkrementellen (fortschreitend in kleinesten Einheiten; hier greift der Begriff des "Rolling Wave Planníngs" des PmBok Guides noch besser als im klassischen PM) Auslieferung des Produkts.
  • Das Team teilt die Arbeiten selbstständig ein und auf.

Kritische Bewertung:

Die Rolle des Product Owners ist ähnlich der des Produktmanagers. Allerdings wird sein Aufgabenbereich komplexer und er rückt näher an das Team, sogar in das Team hinein, wogegen der klassische Produktmanager seine Aktivitäten, die eher strategischer Art sind, vor und nach dem Projektlebenszyklus vornimmt. Ähnlich wie der Produktmanager kümmert er sich um die erste Produktvision, das Produktmarketing, die Produktanforderungen, die Wertschöpfung und zusätzlich das Product Backlog.

Zusätzlich übernimmt er Teilaufgaben des Projektmanagers. Er ist täglich im Rahmen der „Daily Scrums“ anwesend (scheint in der Praxis aber noch nicht angekommen zu sein) und entscheidet über Anforderungen, deren Änderungen und Budgetierung aus Sicht der Wertschöpfung als lenkende Prämisse gesteuert werden müssen. Dies dient in positiver Weise der Agilität und Kostensenkung im Änderungsmanagement.

Der PO erhält aber durch seine Unantastbarkeit in seinen Entscheidungen eine erhebliche Machtfülle. Daraus ergibt sich die Frage, ob alle Stakeholder der Organisation damit konstruktiv umgehen, nur weil der PO diese Rolle auf Basis des agilen Manifests erhält? Die Konflikte, die beispielsweise in einer klassischen Matrix zwischen Projektleiter und Linienmanager köcheln, könnten hier eher noch verstärkt werden.

Die Rolle des eigentlichen „klassischen Projektmanagers“ übernimmt der Scrum Master, wobei man häufig hört, dass da der PO auch nochmitspielt, weil er sich von der klassischen Rolle des Projektleiters nicht trennen kann.

Dadurch, dass SM und PO täglich gemeinsam involviert sind, lassen sich einerseits viele zeit- und kostenintensive Probleme lösen, anderseits kommt es aufgrund der eben beschriebenen Rollenüberlappungen häufig zu Konflikten.

Die Aufteilung und Nähe des PO und SM ist daher eher positiv zu bewerten. Allerdings stellt sich in kleinen Projekten die Frage der Auslastung, falls die beiden Rollen nicht auch als Entwickler involviert sind, was dem agilen Manifest wiedersprechen würde.

„Das Team entscheidet eigenständig, alle kommunizieren offen und aufrichtig….“

Werte sind etwas Gutes! Mit stellt sich nur die Frage, warum Werte in einer Scrum-Umgebung besser funktionieren sollten als in einer klassischen Projektumgebung nicht tayloristischer Natur? Scrum fordert Mut, Offenheit und Respekt und somit Werte und Eigenschaften, die in jeder Arbeitsumgebung erforderlich sind, aber in der Regel nicht gelebt werden. Insbesondere wenn Sprints nicht die erforderlichen Artefakte liefern, Termine nicht gehalten werden und Druck sowie Stress entstehen und es zu Schuldzuweisen kommt. Warum sollten Menschen im Kontext von Scrum verantwortlicher handeln als sonst? Nur weil ein Rahmenwerk Offenheit und Aufrichtigkeit vorgibt, muss es ja noch lange nicht funktionieren. Übrigens auch eine Maxime, die in Vorschriften der Bundeswehr enthalten ist. Fast so sinnvoll wie die Vorschrift: „Ab 1,20 Wassertiefe beginnt der Soldat eigenständig mit Schwimmbewegungen."

Eine weitere Frage die sich stellt: Ich konnte in keinem Buch oder Dokument zu Scrum Angaben finden, wer die Entwickler in ihrer Karrieresicht beurteilt. Die Scrum Teams arbeiten autonom, ohne Einblick der Linienmanager. Eine Möglichkeit sind Peer Reviews. Ich persönlich habe damit noch keine Erfahrungen, halte aber das, was ich darüber gelesen habe, für sinnvoll und praktikabel. Aus Sicht des Arbeitgebers bleiben aber eventuell Fragezeichen.

Ein anderes Element sind Konflikte in Scrum. Obwohl Konflikte bei „Scrum“ quasi überspitzt forumuliert verboten sind, passieren gerade in Scrum-Teams Konlikte, die in klassischen Projekten in dieser Häufung nicht vorkommen.

„Problem erkannt, leider nicht gebannt!“ Die Lösung wird in der „Coaching-Fähigkeit“ des SM gesehen oder, damit keine Verwechslung entsteht, "SCRUM Master".

Ich habe in meiner beruflichen Laufbahn etwa 5000 Menschen geführt oder in Seminaren über längere oder kürzere Zeiträume ausgebildet. Mindestens 10% dieser Menschen waren aus meiner Sicht mit partizipativen Methoden nicht „führbar oder coachbar“. Ein SM, der gleichberechtigt in einem Team agiert, muss sehr starke Persönlichkeitsmerkmale und Charisma mit einbrigen, um quasi als „informeller Führer“ anerkannt zu werden. Andere SM werden es schwer haben, auf das Team einen signifikanten Einfluss zu nehmen, wenn in dem Team Mitglieder agieren, die sich nicht konstruktiv verhalten wollen.

Bei der Bundeswehr kennt man das Phänomen des Fraternisierens (Verbrüderung). Junge Vorgesetzte haben das Problem gegenüber Gleichaltrigen oder Älteren, die Position des Vorgesetzten zu besetzen. Ich konnte viele junge Vorgesetzte beobachten, die den Versuch unternahmen, durch diese Art der „Kumpanei“ dieses Problem zu umgehen. Aber die meisten scheiterten damit und wurden von Ihren Gruppen nicht mehr ernst genommen, außer es trat der o.g. Fall des informellen Führers ein.

Meiner Ansicht nach wäre es eine bessere Lösung, einen SM als formalen Führer einzusetzen, der in der Lage ist, sich wie ein „informeller Führer“ zu verhalten.

Claudia Meindl nennt in ihrem Blog Eigenschaften, die ein PO mitbringen sollte, die aber mindestens ebenso wichtig für einen SM sind:

  • sollte eine starke Persönlichkeit haben.
  • sollte sehr gute, kommunikative Fähigkeiten mitbringen.
  • sollte Menschen begeistern und führen können.
  • sollte Softskills wie Teamfähigkeit, Motivationsfähigkeit und Präsentationsfähigkeit mitbringen.

"Starke Persönlichkeit" interpretiere ich als "Mensch mit Character und Anstand". Eine solche Person muss mit einer gewissen Autorität ausgestattet werden, aber darin trainiert werden, sich nicht als formal eingesetzter Führer zu gebärden sondern sich als postheroischer Führer mit Y-Denke in Szene zu setzen.

Innerhalb der Bundeswehr, als auch in der freien Wirtschaft, habe ich immer wieder beobachtet, dass solche (formellen) Führer, Anerkennung, Kreativität und Motivation geradezu vorbildlich bei Ihren Mitarbeitern erzeugten.

Sicht des PmBok Guides:

Der  PmBok Guides favorisiert schon von je her die Trennung von Produkt- und Projektmanagementprozessen. Allerdings wird im Kontext der Produktprozesse die Verantwortlichkeit einer Rolle wie die des PO nicht so intensiv beschrieben, wie dies bei Scrum der Fall ist.

Bei den klassischen Projekten im Kontext der sequentiellen Phasenmodelle erübrigt sich dies durch die klaren Anforderungen und geplanten Inhalte über den gesamten Projektlebenszyklus.

Bei den überlappenden oder parallelisierten Phasenmodellen (PmBok 5th, S. 43) kommt dagegen das Prinzip des Simultaneous Engineering zum Einsatz, was einerseits „Tim to market“ beschleunigen soll, andererseits interdisziplinäres Arbeiten forciert. In diesem Fall können sich ebenfalls neue Anforderungen ergeben, was eine Rolle wie die des PO aus Scrum sinnvoll machen würde.

Der PmBok Guide nennt im Kontext der Produktprozesse das Fachurteil oder Fachexperten, die dem Projketleiter Expertise zur Verfügung stellen. Hier wäre sicherlich eine Befruchtung durch Scrum wünschenswert.

Briefing = „Daily Scrum“?

Beim „Daily Scrum“ handelt es sich um eine 15 Minütiges tägliches Treffen des Teams, das im Stehen abgehalten wird, häufig an einem Kanban Board.

Jeder Entwickler beantwortet drei Fragen:

  • Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?
  • Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
  • Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?

Das „Daily Scrum“ ist das Genialste am ganzen Scrum Konzept! Aber wirklich neu ist die Idee auch nicht. Aber der Reihe nach!

Ich selbst habe vor etwa 15 Jahren bei einer Tochter von Mercedes MS Project eingeführt. Eine der Kernanforderungen des Managements war es, eine genaue Statusmeldung der Ressourcen in sehr kurzen Abständen zu erhalten.

Ich schlug den MS-Project-Server vor, der es ermöglicht, kollaborativ die Daten der Ressourcen zu erfassen. Das Management sah aber das Problem, dass die Ressourcen nicht pünktlich melden und schon gar nicht objektiv. Ein Problem, das schon Elihua Goldratt mit seiner „Theorie of Constraints“ erkannte aber auch den meisten Praktikern die Projekte durchführen, bekannt ist. Im Gegensatz zu vielen anderen Unternehmen nahm die Tochter von Mercedes dieses Problem aber sehr ernst und hatte den Nutzen von realen und objektiven Statusmeldungen erkannt.

Quasi als Witz meinte ich, dass man dann eine Stelle ausschreiben müsste, die die Meldungen der Ressourcen täglich persönlich einsammelt. Meinen Witz nahm man allerdings ernst und so wurde eine Stelle ausgeschrieben, die weit über den Anspruch der Zeiterfassung hinausging. Es wurde ein sozial kompetenter Controller gesucht, der nicht nur täglich die Daten einsammelte, sondern auch in der Lage war, alle drei oben aufgeführten Sachverhalte des „Daily Scrum“ zu hinterfragen sowie tiefergehende Fragen zu stellen, die auch Erkenntnisse zu speziellen Ursachen für Verzögerungen transparent machen sollte.

Von da an wurden die Projekte nicht nur stringenter gesteuert, die Ressourcen waren auch motivierter (siehe „Hawthorn EffektHuman-Relations-Bewegung)

Analysiert man die Effekte des „Daily Scrum“, muss man wissen, welchen Hintergrund die Erfinder Jeff Sutherland und Kenn Schwaber hatten.

Kenn Schwaber war Besitzer einer Softwareschmiede und Jeff Sutherland war Absolvent der United States Military Academy.

Ich selbst war mal Panzerzugführer Kpz Leopard 1A1 bei der Bundeswehr. Ich kann mich sehr gut an meine Gefechtsübungen erinnern. Fast täglich mussten wir zu einem „Briefing“ bei unserem Kompaniechef antanzen. Dies dauerte maximal 20 Minuten, zwangsweise im Stehen, da es nichts zum Sitzen gab. Danach tanzte unser Kompaniechef zum Briefing beim Bataillonskommandeur an und der Bataillonskommandeur danach sicherlich beim Brigadekommandeur.

So etwas nennt man bei Scrum „Scrum im Scrum“. Wenn Teams größer als vorgeschrieben werden, dann bildet man weitere Srum Teams, die über eine Schnittstellen, ähnlich wie im genannten Beispiel bei der Armee, miteinander kommunizieren.

Mit Jeff Sutherland und Kenn Schwaber hatten sich zwei Männer getroffen, die eine optimale Symbiose ergaben: Der eine Arbeitgeber von Softwareentwicklern, der andere militärisch ausgebildet und nicht nur beschlagen in den Methoden des Briefings, sondern auch weiterer brauchbarer Erkenntnisse in prägnanter Kommunikation und Menschenführung (Stichwort: Strategie und Taktik).

Klaus Schmidtbauer unterscheidet in seinem Buch „Professionelles Briefing – Marketing und Kommunikation mit Substanz“ drei Arten an Briefings:

  1. Strategisches Briefing
  2. Kreatives Briefing
  3. Operatives Briefing
Grundsätzlich beschreibt er Briefing aber als ein freundliches Verhör.
 
Ich wiederhole noch einmal: Das „Daily Scrum“ ist neben der Retrospektive das Genialste an der gesamten Scrum Methode.
Eine realistische und objektive Zeiterfassung ist seit Jahrzenten eines der größten Probleme im Projektmanagement. Ohne realistische Überwachung keine Steuerung!
Was kann einem Projektleiter, in dem Fall PO und SM denn Besseres passieren, als täglich aus erster Hand zu erfahren, was passiert ist, was heute passieren wird und welche Probleme jeder Einzelne für die Erfüllung seiner Aufgaben sieht?

Diese Reform des Reportings wäre auch für klassische Projekte ein Quantensprung und wäre auch ein probates Mittel für das Earned Value Management.

Der verantwortliche SM für das Daily Scrum muss allerdings sozial so kompetent sein, dass er für die Mitglieder des Teams daraus einen Motivator erzeugt und nicht ein Gefühl des Gruppenzwangs und der Gängelei. Die Zeit des Home Office und flexiblen Arbeitszeit ist mit Scrum schließlich vorbei, auch das wird nicht unbedingt auf freudiger Erregung stoßen.

Nichts desto trotz, die jahrelange Schönfärberei von Projekten kann mit dieser Methode durchaus ein Ende finden, gerade auch in klassischen Projekten.

 

Lesen Sie weiter im zweiten Teil:

  • Scrum Ergebnisorientierung: Welche Geländegewinne haben wir zu verzeichnen? Wieviel Verluste hat der Feind erlitten?
  • Product Backlog und Burndown Chart ersetzen MS-Project?
  • Burndown Chart und Earned Value Management – wo liegen liegen die Gemeinsamkeiten?
  • Passt jede User Storie auf eine Pinnwand?
  • Wie verhält sich Scrum vor dem Hintergrund der Section 404 SOA/SOX?

Tip: Bei PMI exisiert jetzt neben der PMP Zertifizierung auch eine Zertifizierung für agiles Projektmanagement.

Renee Ossowski, PMP

Geben Sie uns Ihr Feedback! Bitte melden Sie sich an, um einen Kommentar zu posten!