Letzte Chance auf PDUS - vor dem Auge des Sturms

Das PMI (R) ändert die Regeln für die Anerkennung von PDUs. Künftig muss man als PMP das "Talent Triangle" bedienen: Technical Project Management, Business & Management, Leadership - alles im Zeichen von "Education".

Startet ab: 1.12.2015

Heißt soviel wie: Jetzt schnell noch PDUs eintragen lassen!



PS: Auch für die Beschäftigung mit dem Triangle kann man ja mal PDUs anmelden, gelle. 0.5 machten jedenfalls keine Probleme...

Agile Techniken – Story Points

Was ist das?

Story Points sind numerische Werte, meist angelehnt an Fibonacci-Zahlen: 0, 1, 2, 3, 5, 8, 13, 20, 40, 80. Das Scrum-Team verwendet sie zur Bewertung der Komplexität von Anforderungen in Stories.

Sie dienen als „psychologischer Trick“ und Diskussionsanker, um Komplexität zu bewerten und zu erforschen.

Wozu kann ich das verwenden?

Die Erstellung von Aufwandsschätzung ist fehlerbehaftet:

• Menschen sind schlechte Schätzer – und zwar fast alle! Insbesondere haben wir keinen Instinkt für Wahrscheinlichkeiten. Zur Illustration kann ich nur empfehlen: Rolf Dobelli, Die Kunst des klaren Denkens. 
• Menschen halten sich jedoch für gute Schätzer, die wenigsten kennen jedoch ihr „Handicap“.
• Implizite Annahmen und widrige Umstände führen zu massiven Schätzabweichungen. Umso mehr, wenn z.B. in der Softwareentwicklung gerade mal wieder Hektik vorherrscht und man keine Zeit für endlose Analysen hat.
• In Stresszeiten gerät man häufig auch unter Druck: „Das können wir nicht verkaufen“ – „Das muss doch einfacher gehen, die sollen mal richtig programmieren und nicht rumprobieren“. 

Der Trick der Story Points ist nun die Loslösung der Komplexität vom Aufwand: Wenn ich einmalig 1000 Sätze in einer Excel-Tabelle bearbeiten muss mit einfachen Editier-Vorgaben, dann ist dies womöglich aufwändig – aber nicht komplex! 

Muss ich jedoch die gleiche Excel-Tabelle aus meiner Anwendung erzeugen, dann kann das komplex sein: woher bekomme ich die Daten? Welche Umwandlungen muss ich vornehmen? Sind diese Transformationen algorithmisch lösbar oder nur durch Menschen? Welche Zeichensätze verwende ich?

Agile Teams verwenden Story Points, um Komplexität zu bewerten und in eine Diskussion zur Erforschung der Anforderungen einsteigen zu können: Abweichungen in den Einschätzungen im Planning Poker zeigen Bedarf zur Klärung von Annahmen auf – wenn die Fragen geklärt sind, dann kann das Team die Anforderung realistisch einschätzen.

Worauf muss ich achten?

Meist nutzt das Team implizit oder explizit einen Wert für „unendlich“ oder „viel zu hoch“, z. B. die 100. Die Fibonacci-Reihe ermöglicht eine Vorstellung über die Größenordnungen – jedoch müssen die Teammitglieder in den ersten Zyklen gemeinsam eine Skala nach und nach festlegen.

Gerne verwenden Anfänger Stunden statt Story Points – weil das Management ja Aufwandschätzungen, Budgets und Pläne verlangt und man das jahrelang so gemacht hat. Häufig haben diese Teams noch nicht am eigenen Leib erfahren, wie gefährlich Schätzungen und darauf basierende Aussagen sind: wenn ein Auslieferungstermin nicht gehalten oder ein Budget überschritten wird, ist oft noch das Management in der Pflicht – nicht das Team. 

Abschätzungen in Story Points helfen dem Team, sehr schnell und effizient Fallstricke zu identifizieren und Komplexität in den Griff zu bekommen.

So kann das Team vom Product Owner verlangen, eine komplexe Story aufzuteilen in beherrschbare Teile, um das Risiko zu verringern.

Beispiele 

Story: „Als Anwender kann ich mich jederzeit ausloggen, damit ich den Zugriff auf  meine Daten verhindern kann.“

Das Team bewertet die Komplexität einstimmig mit 2, weil neben dem Logout im Test geprüft werden muss, ob der Anwender noch Zugriff nach Logout hat.

Story: „Als Anwender kann ich die angezeigten Daten der Maske als XML abrufen, damit ich sie in anderen Anwendungen weiter verwenden kann.“

Das Team bewertet mit: einmal 1, viermal 3, einmal 8. Das Teammitglied mit der niedrigsten Schätzung (1) befragt das Teammitglied mit der höchsten Schätzung (8), worin die Komplexität besteht. Es stellt sich heraus, dass ggf. ein XML-Schema zu verwenden ist oder eine DTD, während die einfachste Variante in einer Standard-Konvertierung der verwendeten Library besteht. Der Product Owner entscheidet sich für die einfache Variante, erneutes Pokern führt zu einer einstimmigen 3.

Story: „Als Anwender kann ich jede Maske auf DIN-A4 ausdrucken, damit ich die Inhalte mitnehmen kann.“

Das Team bewertet fast einstimmig mit 80, weil unklar ist, wie viele Masken es gibt und ob sie überhaupt auf das Format angepasst werden können. Daraufhin gibt sie dem Product Owner die Story zur Reduktion zurück. Der Product Owner ändert die Story in „Als Anwender kann ich die Maske Nr. 1 ohne Grafiken in einer Druckansicht im Browser anzeigen, damit ich sie über die Browser-Funktionalitäten ausdrucken kann.“

Agile Techniken – Planning Poker

Was ist das?

Planning Poker ist eine Methode zur Einschätzung von Themen in einer Gruppe.

Wozu kann ich das verwenden?

Zunächst verwenden Scrum Teams das Planning Poker zur Bewertung der Stories aus dem Backlog. Dies geschieht meist während des Sprint Planning Meetings. Der Product Owner kann das Team auch an anderen, geplanten Terminen bitten, die Stories zu bewerten. Dadurch kann er anhand der Story Points und der durchschnittlichen Velocity abschätzen, wie viele Sprints bzw. die Umsetzung des gesamten Backlogs dauern würde.

Oft ruft der Product Owner das Team vor dem Sprint Planning zusammen, um die Stories für den nächsten Sprint zu bewerten – das hilft ihm vor allem, frühzeitig Unklarheiten und implizite Annahmen aufzudecken, die sonst erst im Sprint erkannt werden. Ein guter Product Owner zerlegt komplexe Stories in weniger komplexe, um die Risiken zu minimieren.

Man kann Planning Poker auch für die Priorisierung von Themen nutzen, z.B. in einem Meeting mit zu kleinem Zeitfenster: dann legt das schnelle Bewerten eine gemeinsame Reihenfolge fest. Gleichzeitig werden unterschiedliche Bewertungen im Team deutlich. Die Priorität ist dabei nach oben offen – damit nicht wieder „Priorität 0“ eingeführt werden muss.

                                    

Worauf muss ich achten?

Der Ablauf ist:

1. Der Product Owner stellt die Story aus dem Backlog vor.
2.  Das Team stellt Verständnisfragen zur Klärung – Diskussionen finden dabei nicht statt.
3. Alle Teammitglieder zeigen gleichzeitig ihre Schätzungen. Sie schätzen dabei die Komplexität – nicht den Aufwand: 1000 Blätter zu falten ist aufwändig, aber nicht komplex. Aus einem Blatt einen Papierflieger zu falten, der 10 Meter weit fliegen kann, kann ziemlich komplex sein.
4. Falls sich unterschiedliche Einschätzungen ergeben: Die Teammitglieder mit der höchsten und niedrigsten Schätzung diskutieren ihre Annahmen – alle anderen schweigen.
5. Falls zu viele Fragezeichen oder sehr unterschiedliche Bewertungen gezogen  werden, kann das Team die Überarbeitung der Story durch den Product Owner verlangen.
6. Falls Fragen geklärt wurden, wird die Pokerrunde wiederholt.
7. Bei Einigkeit vermerkt der Product Owner die Story Points zur Story.
8. Der Scrum Master achtet auf eine zügige Abwicklung.

Das Team muss dafür sorgen, dass auch Teammitglieder schätzen können, die das Thema vorher nicht oder nur ansatzweise kennen – insbesondere sind keine Expertenschätzungen gewünscht, weil die Experten womöglich gar nicht zur Verfügung stehen. Eine Vorherrschaft von einzelnen Experten steht auch der Bildung eines leistungsfähigen Teams entgegen.

In den Diskussionen zu höchster und niedrigster Schätzung geht es nicht um Meinungen, sondern um Risiken, Grundannahmen, unterschiedliche Vorstellungen über den Umfang der Arbeiten, ...

Das Team kann zu neuen Einschätzungen gelangen, etwa, dass der Product Owner die Story zurücknehmen und überarbeiten muss.

Oft hilft es bei komplizierten Sachverhalten, die Kernaussagen und Argumente zu verdichten auf das Niveau der „Schlagzeilen einer Boulevard-Zeitung“ – prägnante Begriffe und Sätze helfen, die unterschiedlichen Varianten abzugrenzen, auch wenn sich hinter ihnen viele Details verbergen.

Ein effizientes Planning Poker erfordert eine disziplinierte Diskussionskultur in der Gruppe.

Beispiele

Der Product Owner lässt das Team Planning Poker für Stories aus dem Backlog durchführen, damit er anhand der Bewertung die Verteilung der Stories auf die nächsten Sprints planen kann – und damit z.B. dem Kunden die mögliche Gesamtdauer ankündigen kann.

Das Team ist frustriert, weil zu viele Themen in einer Besprechung zu diskutieren sind. Andererseits kann es sich auch nicht auf eine Priorisierung einigen. Der Scrum Master lässt das Team per Planning Poker die Prioritäten festlegen. In der folgenden Timebox werden dann die Themen nach absteigender Priorität bearbeitet. 

Planung?

Vor kurzer Zeit las ich einen Eintrag in einem Business Social Network in einer Gruppe zum Projektmanagement. Dort verwiesen die Autorinnen auf einen Blogeintrag ihrer Firma zum Thema „Klassische vs. Agile Planung und der dritte Weg“.

Der recht kurze Text gab die Annahme wieder, dass in klassischen Wasserfall-Projekten viel und in neumodischen, agilen Projekten wenig geplant werde, um dann eine Synthese als zusammengesetztem Weg vorzuschlagen. Die Kommentare priesen die Idee – und ich fühlte mich gemüßigt, einen Kommentar zu hinterlassen. Der Kommentar ist nicht mehr online – dafür hat man weitere Kommentare aus dem besagten Netzwerk hineinkopiert. Warum nur?

Ach ja: Ich lobte die Idee der Kombination aus „best of“ – musste aber mitteilen, dass ich die Grundannahme nicht teile. Denn: in agilen Projekten wird deutlich mehr geplant als in klassischen. Dazu gleich mehr.

Warum die Autorinnen den Kommentar gelöscht haben? Das Ganze ist eine Hurra-wir-sind-toll-Werbeseite. Wobei ich wirklich – ohne Flachs – verstehen kann, wenn man als Freelancer oder 2-Mann-Bude auf sich aufmerksam machen muss. Aber warum man keine Diskussion zulässt, sondern nur simuliert? In Zeiten von Open Source und Communities wie www.openpm.info?

(Da ich niemanden „trollen“ will, habe ich das Thema leicht verfremdet und verlinke hier nicht auf den Blog.)

Aber schauen wir uns mal die Grundannahme an: „in Wasserfall-Projekten wird mehr geplant als in agilen Projekten“. Wir haben also eine Art Skala zwischen zwei Extremen:

Wasserfall

Oft zitiert und keiner hat den Artikel ganz zu Ende gelesen. Der gute Mann hatte nämlich nicht gemeint, dass ein Wasserfall-Vorgehen toll ist, sondern dass dies nicht funktioniert und man Rückwege bzw. Zyklen einbauen muss. Leider ist der Name zum Synonym für ein Vorgehen geworden, in dem das Projektleiter-Genie alles vorgibt.

Wenn das PL-Genie also alleine in John-Wayne-Manier unser Projekt X plant, dann braucht es z.B. einen ganzen Mann-Monat, also 20 PT. Dann läuft das Projekt und der PL passt die Planung alle paar Meilensteine an. Macht für ein Jahr Laufzeit vielleicht noch mal 3 PT pro Quartal, also 12 PT, in Summe 32 PT.

Experten einbinden 

Frei nach dem PMBoK (das aber keine Methodik vorgibt!!!). Also: zwei Mann-Monate, dabei können sich die Leute ja abwechseln, sagen wir 40 PT. In der Laufzeit die gleiche Anpassung, aber mit Hilfe, sagen wir mal 24 PT, in Summe 64 PT.

Scrum! 

Hier plant das Team – zu Beginn eines jeden Sprints. Bei 5 Teammitgliedern plus Product Owner für die Gesamt-Planung und stressigen 2 Wochen Sprint-Dauer über 13 Monate im direkten Vergleich (oben hatten wir ja einen Monat Planung vorab):

6 Personen * 4h pro Sprint Planning * 13 Monate * 2 Sprints im Monat: 78 PT

Dabei habe ich Backlog Grooming und zusätzliche Planning Poker Sessions noch gar nicht berücksichtigt!

Erkenntnis

Agil verursacht MEHR Aufwand für Planung – kein Wunder, es wird häufiger geplant und von einer größeren Anzahl von Personen! Für Scrum-Teams sind die häufigen Besprechungen sogar erfahrungsgemäß oft nervig – aber unabdingbar: sonst plant ja keiner.

Leider ist es oft so, dass agil als Ausrede für „Arbeiten auf Zuruf“ dient. Oder als Projektionsfläche für andere, gerade genehme Vorgehensweisen. Das bringt Agilität in Verruf, weil viele nie verstanden haben, dass man zwar im Rennwagen im zweiten Gang schon sehr schnell fährt – dass man aber nur in den höheren Gängen das Rennen gewinnen wird.

Der "agile Verlierer"

Etwas anderes viel mir in den Kommentaren auf, auch in anderen Foren:

Es finden sich immer „gestandene“ Projektmanager, die agile Ansätze zynisch kommentieren oder sich echauffieren. Ich sehe sie mittlerweile als „agile Verlierer“ – genau wie Senioren, die kein Online-Ticket erstellen können. 

Der typische agile Verlierer war früher der „Bestimmer“: sein Projekt – sein Plan – sein Erfolg. Das ist alles weg, nur Unsicherheit ist geblieben. Und Unbehagen – wird man noch gebraucht? Ist man schon alt? Veraltet? Vielleicht ist genau dies die Klientel der o.g. Anbieter – wer weiß?

Ich gebe zu, ich habe Scrum anfangs sehr abgelehnt – und stehe der Methode noch immer skeptisch gegenüber. Aber ich bin nun Professional Scrum Master und habe nach langer Zeit verstanden, wie Scrum funktioniert. Und das ist nicht leicht umzusetzen. Aber es hat mir viele, viele Best Practices geliefert. Die wichtigste davon heißt: Erkenntnis – an der Wirklichkeit. Ein guter Rat auch für Werbe-Blogger, übrigens.

Aus Fehlern lernen?

Klar - aus Fehlern anderer! Ist nämlich billiger, oder?

Ich stieß auf eine 3Sat-Sendung in der Reihe Scobel, die interessante Standpunkte aufzeigte: sowohl agil als auch klassisch kontrollierend.

Must see.

Agile Techniken – Scrum Master

Was ist das?

Scrum Master ist eine Rolle der Scrum Methodik. Der Scrum Master ermöglicht dem Team die Anwendung von Scrum. Er gehört nicht zum Team selbst. Insbesondere ist er dem Management der Organisation gleichgestellt, um Probleme des Teams in der Organisation beheben zu können.

Wozu kann ich das verwenden?

Scrum basiert auf Erkenntnis und Eigenverantwortung. Daher steuern sich die Teams selbst, so dass sie aus Planung und Erkenntnis lernen. Der Scrum Master muss daher außerhalb des Teams angesiedelt sein, damit nicht er das Team steuert – das Team soll autark, auf das Ziel hin gerichtet agieren. Damit fördert Scrum die Eigenverantwortung, die Zielorientierung und das Erkenntnis-basierte Vorgehen.

Gleichzeitig agiert der Scrum Master in der Organisation, vor allem im Management, um die möglichst reibungsfreie Ausführung des Scrum Prozesses zu ermöglichen.

                                    

Worauf muss ich achten?

Der Scrum Master muss Mitglied des Managements sein: er muss auf Augenhöhe mit Managern in der Organisation interagieren, um die vom Team identifizierten Anforderungen an die Organisation zu realisieren.

Der Scrum Master darf nicht Teammitglied sein – auch nicht, wenn gerade kein Scrum Master zur Verfügung steht! Viele Anfänger-Teams gehen fälschlicherweise nach wenigen Wochen davon aus, dass sie die Scrum-Mechanismen bereits verstanden hätten. Eine Vermischung von Rollen ist erst nach Jahren und nur für erfahrene Scrum-Teams möglich, aber auch dann bedeutet dies in der Regel einen Leistungsverlust!

Ein Scrum Master ist zudem nicht der disziplinarische Vorgesetzte eines Teammitglieds. Er ist zwar Mitglied des Managements, steht aber zwingend außerhalb der Linienorganisation.

Eine Vermischung von  Scrum Master Rolle und Linienorganisation oder Teamorganisation führt in der Regel zu einem Abfall der Leistung – den viele Unternehmen nicht wahrnehmen, weil sie bereits sehr früh Mischformen zulassen: sie haben dann den erreichbaren Wirkungsgrad noch gar nicht erfahren.

Beispiele

1. Das Team will ein physikalisches Scrum Board einrichten, um seine Tätigkeiten zu visualisieren und zu koordinieren. Das Unternehmen hat Großraumbüros eingerichtet, in denen keine Poster etc. an den Wänden aufgehängt werden dürfen. Ein dauerhafter Teamraum steht auch nicht zur Verfügung.
1. Der Scrum Master identifiziert die beteiligten Ansprechpartner und erklärt ihnen die Wichtigkeit des Vorhabens zur Selbststeuerung des Teams.
2. Ggf. eskaliert er Verweigerungshaltungen an die oberste Geschäftsführung, damit diese entscheiden kann, ob sie die Leistungssteigerung des Teams oder die strikte Einhaltung der Hausordnung priorisiert.
2. Das Team zeigt Schwächen in internen Diskussionen: Mitglieder schweifen ab oder lassen andere nicht ausreden, einzelne Mitglieder dominieren, etc. 
1. Der Scrum Master spricht mit einzelnen Mitgliedern, um sie zu motivieren, sich zu Wort zu melden.
2. Der Scrum Master richtet eine Team-bildende Maßnahme außerhalb des Arbeitsalltages ein.
3. Der Scrum Master konfrontiert das Team in einer dafür eingerichteten Sitzung mit seinen Beobachtungen und moderiert die Diskussion – bei erfahrenen Teams sehr effektiv, bei unerfahrenen Teams mitunter sehr heilsam.

Agile Techniken – Timebox

Was ist das?

Eine Timebox ist eine Zeitspanne mit einem definierten Anfang und einem definierten Ende.

Wozu kann ich das verwenden?

Die Timebox definiert eine „harte“ Grenze – nur so können die Beteiligten einen echten Lerneffekt erfahren! Vor allem aus den Fehlschlägen können sie Verbesserungen ableiten und umsetzen. 

Worauf muss ich achten?

Die Beteiligten bestimmen vorab die Inhalte für die definierte Timebox selbst. Sollte die Timebox nicht ausreichen, wird das Meeting bzw. die Aktivität abgebrochen. Um die notwendigen Inhalte doch noch zu erarbeiten, können sich die Beteiligten auf das Ansetzen einer weiteren Timebox verständigen.

Eine Verschiebung der Deadline am Ende einer Timebox führt hingegen zu einer Gewöhnung an die „weichen“ Grenzen – wie in der klassischen Software-Entwicklung häufig zu finden.

Beispiele

1. Ein Sprint ist eine Timebox:

•  Der Sprint startet mit dem Sprint Planning Meeting an einem festgelegten Tag.
•  Der Sprint endet mit dem Review Meeting und der Retrospektive – an einem vor dem Start festgelegten Tag.

Wenn der Sprint eine Woche dauert und am Mittwoch beginnt, so endet er am Mittwoch in der Folgewoche. Alle Anforderungen, die dann nicht „done“ sind, gelten als nicht umgesetzt.

2. Ein Sprint Planning Meeting ist eine Timebox von z.B. zwei Stunden Dauer für eine Sprint-Dauer von einer Woche: der Scrum Master bricht das Sprint Planning ab, wenn es länger als zwei Stunden dauert.