Agiles Projektmanagement Office: Die Just-In-Time Planung

Eine häufig geäußerte Kritik an agilen Verfahren ist, dass nicht wirklich geplant wird. Zwar gibt es ein Taskboard und auch ein sogenanntes Team-Commitment, aber es ist letztlich unklar, wer für welche Aufgabe verantwortlich ist, und wie sich die Effizienz optimieren lässt. Um diese Nachteile zu beseitigen, hat sich seit den achtziger Jahren die Ressourcen-Auslastungsplanung bewährt: Auf Basis einer soliden Analyse werde die Aufgaben so den einzelnen Ressourcen zugeteilt, dass sich eine optimale Auslastung ergibt und damit eine optimale Performance.
Letztlich spricht nichts dagegen, die beiden bewährten Ansätze im Sinne eines „Best-of-both“ zu kombinieren. Ich richte dafür in der Regel ein „Agiles Projekmanagement Office“ (APO) ein, also ein FTE, das für eine solide Projektdurchführung im Sinne eines Scientific Managements verantwortlich ist, ohne die fachliche Flexibilität des Product Owners einzubüßen. Aufgabe des APO ist die Pflege eines Gantt-Charts auf Basis des letzten Standup-Reports, der jeweils Just-in-Time den neuesten Vorgaben des PO angepasst wird. Durch konsequenten Einsatz des Teamplaners aus MS Project 10 ist diese Aufgabe leicht und effizient durchführbar.
Das ergibt folgende Vorteile:

  • Jederzeit eine klare Vorausplanung für das Team, auch über sogenannte Sprintgrenzen hinweg. Meine Kunden erreichen mit MS Project in der Regel einen Planungshorizont von 18-23 Monaten und sind daher wieder in der Lage, Termine zuzusagen
  • Klaren Überblick für den Projektleiter, wer an welcher Aufgabe arbeitet, so dass er die Auslastung optimieren kann
  • Kompatibilität mit etablierten Berichtswegen, was die Einführung von Scum gerade in Großorganisationen deutlich erleichtert
  • Aufgrund der nun klaren Berichts- und Anweisungswege kann auf ineffiziente Daily Standups und Selbstorganisation verzichtet werden und die Ressourcen können wieder ungestört ihrer Aufgabe nachgehen. Alleine das erhöht die Produktivität um 3,1%

Aufgrund des großen Erfolges bemühen wir uns derzeit darum, das APO in den neuen Scrum Guide übernehmen zu lassen.

Aufspalten einer User Story

Agile Entwicklung funktioniert umso besser, je kleiner die fachlichen Schritte sind, die man nehmen muss. Um Anforderungen klein zu hacken, verwendet man üblicherweise sogenannte „User Stories“, also einen Ablauf aus Anwendersicht, der unterstützt werden soll. Schwierig wird es vor allem für Neu-Agilisten allerdings, wenn es darum geht, diese Stories klein genug zu bekommen. Oft genug stehen am Anfang Stories, die mehrere Wochen brauchen, um fertig umgesetzt zu werden, also inklusive Integration und Test. Ziel ist aber, eine Story innerhalb weniger Tage produktionsreif zu bekommen.

Nachdem es um funktionsfähige Häppchen geht, verbietet sich eine Aufteilung „Mach die Oberfläche für XY“, „Mach die Logik für XY“ von selbst: Diese haben keinen eigenen Geschäftswert und taugen bestenfalls (bzw. schlimmstenfalls) als technische Aufgaben. User Stories sollten aber so gestrickt sein, dass sie unabhängig sind, wertschöpfend, verhandelbar, schätzbar, klein und für sich testbar („INVEST“: Independent, Negotiable, Valuable, Estimable, Small, Testable).

Richard Lawrence fasst nun in seinem Blog-Eintrag „Patterns for Splitting User Stories“ neun Strategien zusammen, die sich für die Aufspaltung von User Stories eignen. Ob es wirklich Patterns sind, darüber lässt sich sicherlich streiten. Dennoch ist der Beitrag auf jeden Fall lesenswert und sein „Crib-Sheet“ am Ende könnte auch für dogmatische Nicht-Internet-Ausdrucker ein Grund sein, mal wieder nach einem Druckertreiber zu suchen.

(Siehe auch mein Eintrag „Schneiden von Stories“ vom 2.12.2008)

Vortrag auf der W-Jax zu langfristiger agiler Planung

Kurzfristig werde ich am kommenden Montag, 9.11.2009 auf dem Agile Day der W-JAX in München von 9:00 Uhr bis 10:00 Uhr einen Vortrag zu langfristiger agiler Planung halten:

Techniken zur agilen Planung führen regelmäßig zu hoher Termin- und Vorhersagetreue. Dies liegt vor allem an einer belastbaren Basis von Erfahrungswerten und statistischen Daten, die sich agile Teams aufbauen. Richtig aufbereitet können diese Informationen weit über den reinen Planungsprozess hinaus eingesetzt werden. Ist die Organisation bereit, ausgetretene Pfade zu verlassen, können aus diesen Informationen belastbare langfristige Prognosen gewonnen werden, die wertvolle Informationen für Vertrieb, Geschäftssteuerung und Kundenmanagement liefern. Dieser Beitrag zeigt Praxisbeispiele für solche Ansätze, deren Nutzen und deren Einschränkungen.

Und natürlich beteilige ich mich am Nachmittag von 14:00 Uhr bis 15:00 an der Pecha Kucha Session von Martin Heider und Bernd Schiffer mit 6 Minuten und 40 Sekunden zu dem Thema „Mein agiler Koffer“ — ein Beitrag, auf den ich mich besonders freue!

Folien der Karlsruher Entwicklertage online

Zu meinen Vorträge auf den Karlsruher Entwicklertagen stehen nun auch die Folien online zur Verfügung:

Danke an die andrena objects ag für das Bereitstellen der Unterlagen

Beiträge zu den Entwicklertagen in Karlsruhe

Logo EntwicklertageVom 22. bis zum 26. Juni finden in Karlsruhe die Karlsruher Entwicklertage statt, zu denen ich mit zwei Vorträgen und einem Worshop beitrage:

Ziele agiler Planung

Wenn agile Planung richtig durchgeführt wird, leistet sie einen wichtigen Beitrag, das Projekt zum Erfolg zu führen. Dabei ist Erfolg nicht als Einhaltung von Zeit, Umfang, Budget und Qualität definiert, sondern als Beitrag zur Maximierung des Geschäftsnutzens der Software. Das bedeutet, dass agile Planung sowohl die Effektivität der Softwareentwicklung fördern sollte, als auch deren Effizienz – und zwar in dieser Reihenfolge.

Zur Förderung der Effektivität werden mehrere Teilziele verfolgt:

  • Das Team soll sich darauf fokussieren durch die Anwendung den geschäftlichen Mehrwert des Systems zu optimieren
  • Das Planungsverfahren soll Änderungen unterstützen und nicht erschweren. Änderungen gelten im agilen Kontext als unvermeidlich und sind Teil des Lernprozesses aller Beteiligten
  • Risiken sollen minimiert werden, also entweder frühzeitig ausgeschaltet oder durch entsprechende Sicherungen unschädlich gemacht werden. In diesem Sinne ist Risikomanagement integraler Bestandteil agiler Planung

Weitere Teilziele sollen die Effizienz der Entwicklungsarbeit optimieren:

  • Voneinander abhängige Aktivitäten sollen koordiniert werden
  • Die Planung soll realistische Voraussagen ermöglichen, damit sich andere Projektbeteiligte rechtzeitig darauf einstellen können. Zum Realismus zählt auch das explizite Eingeständnis, dass jede Voraussage nur mit einer gewissen Wahrscheinlichkeit eintritt. Eine Abschätzung für diese Wahrscheinlichkeit ist eine der „Königsdisziplinen“ agiler Planung
  • Die Planung sollte eine Basis für realistische Statusbestimmungen liefern. Dafür muss klar definiert sein, wann eine Aufgabe abgeschlossen ist. Dieses Kriterium muss sich an dem Beitrag zum Projektergebnis orientieren, es muss eindeutig feststellbar sein und darf nicht interpretierbar sein. Der Fortschritt sollte sich an den ausgeräumten Risiken orientieren und der Status muss ausreichend Informationen enthalten, um schnelle Eskalationen zu ermöglichen

Interessant sind aber auch Ziele, die oft mit Plänen verbunden werden, die aber von agilen Planungsverfahren explizit nicht verfolgt werden:

  • Es soll keine korrekte Vorhersage des Projektablaufs erstellt werden, weil das nicht möglich ist. Erfolg ist der geschaffene Mehrwert, nicht das Einhalten eines Plans
  • Die Mitarbeiter- und Ressourcenbelegung soll nicht vorausgeplant werden, weil diese Pläne in einem nicht vorhersehbaren Umfeld sehr aufwändig und fragil sind und keinen Nutzen stiften
  • Agile Planung ist kein Vehikel, um über „ambitionierte Pläne“ Druck auf das Team auszuüben. Hilfreicher Druck kommt in agilen Teams vom gemeinsam verfolgten Ziel. Übermäßiger Druck führt zu Qualitätseinbußen und damit kritischen Zeitverzögerungen. Die Grenze zwischen heilsamer Fokussierung und übermäßigem Druck liegt deutlich niedriger, als die meisten Manager glauben
  • Agile Planung ist kein Vehikel, um Verantwortung weiter zu schieben, indem man unrealistische Zulieferungstermine aufstellt und dann den Verzug verantwortlich macht für eigene Verzögerungen. Da Planungen stets mit Wahrscheinlichkeiten versehen sind, versucht wird, Abhängigkeiten aufzulösen und die Teams für Risiken Rückfallstrategien aufbauen, taugen solche Spielchen nicht mehr, um die Verantwortung abzuwälzen
  • Agile Planung erzählt Managern nicht, was sie gerne hören wollen, sondern bietet einen realistischen Blick auf das, was möglich ist. Das erfordert für viele Manager Umgewöhnung, erlaubt ihnen aber, früher zu reagieren und schädliche Auswirkungen zu begrenzen

Agile Planung ist damit ein wichtiges Instrument für das Team und das Management, die Wertschöpfung eines Projekts nicht so sehr trotz, sondern mit Hilfe vieler Änderungen zu optimieren. Wie Jim Highsmith schreibt: „Agile Projektmanager kümmern sich bevorzugt um Wertschöpfung, Teams und Anpassbarkeit. Diese sind für ein erfolgreiches Projekt wichtiger, als die Beschränkungen durch Zeit, Kosten und Anforderungen“ („Cutter Agile E-Mail Advisor“ am 13.11.2008, Cutter Consortium).

Roman Pichler zu Produktvisionen

Roman Pichler hat einen schönen Artikel zur Vision geschrieben, die jedem Produkt (und jedem Projekt) zugrunde liegen sollten („The Product Vision„). Für mich waren die fünf Elemente einer guten Vision am wertvollsten, auch wenn sie zum Standard einer guten Produktstrategie gehören:

1. Who is going to buy the product? Who is the target customer?
2. Which customer needs will the product address?
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
5. What is the target timeframe and budget to develop and launch the product?

Hinzufügen könnte man noch die beiden Fragen, wer das Produkt eigentlich will (und wer nicht!) und was geschehen würde, sollte das Produkt nicht (rechtzeitig) kommen.

Der Schlüssel einer guten Vision ist der richtige Kompromiss zwischen Verständnis und Kürze. Roman verlangt, dass man die Produktvision innerhalb einer Fahrstuhlfahrt erklären können muss — allerdings stammt der „Elevator Pitch“ aus den USA, wo Bürogebäude in der Regel deutlich höher sind, als bei uns… Wichtig ist auch das Verständnis, dass die Vision im Laufe des Projektes reift. Man sollte nicht am Anfang ein halbes Jahr investieren, um die Vision zu erstellen bevor man anfängt zu arbeiten und damit durch die Hintertür den Wasserfall wieder einführen. Kundenfeedback und eigene Erfahrung sind wichtige Bestandteile einer Produktvision und beides bekommt man erst, wenn man schon ein Stück unterwegs ist.

Ich persönlich versuche, die Vision am Anfang eines zwei- bis dreitägigen Kickoff-Workshops erstmals zu fixieren. Das ist zwar häufig nur der allererste Anfang, er stellt aber sicher, dass alle Teammitglieder an ihrer weiteren Ausarbeitung beteiligt sind. Zugegebenermaßen kann man auch deutlich mehr Zeit in eine Vision investieren, ohne gleich dem Wasserfall zu verfallen, doch habe ich die Erfahrung gemacht, dass der Diskussions- und Lernprozess im Team wichtiger ist, als das formale Ergebnis. Und es schadet durchaus nicht, wenn einige Fragen erst im Laufe der ersten Iterationen geklärt werden.

Agile Planung und Vorhersagen

Nachdem ich mich in meinem Beitrag „Was ist anders bei agiler Planung“ mit den grundlegenden Mechanismen agiler Planung beschäftigt habe, stellte Maximilian Scherf die Frage, „Wie kann ich denn so beurteilen zu welchem Zeitpunkt ich was fertig haben werde?“ Die Frage ist sehr berechtigt, aber nicht so einfach zu beantworten, so dass ich hier in einem eigenen Eintrag darauf antworten möchte – zumindest grob.

Grundsätzlich muss man sich darüber im klaren sein, dass eine Terminaussage in einem Softwareprojekt die Vorhersage eines chaotischen Systems ist und damit der Wettervorhersage ähnelt (ich rede hier von chaotischen Systemen im Sinne der Theorie komplexer Systeme, nicht aus der Perspektive von Eltern, die in das Kinderzimmer schauen). Chaotische Systeme zeichnen sich dadurch aus, dass ihr Verhalten umso schwerer vorhersagbar ist, je weiter man in die Zukunft schaut: Die Wettervorhersage für die nächsten fünf Minuten bekommt auch der Laie üblicherweise korrekt hin, für den nächsten Tag müssen selbst Profis erheblichen Aufwand treiben und für mehr als eine Woche sind seriöse Vorhersagen derzeit nicht möglich.

Im Projektmanagement sind die planbaren Zeithorizonte zum Glück deutlich länger: Eine Woche ist meist kein Problem, einen Monat bekommt man auch noch ganz gut hin, ab einem Quartal wird es eng. Eine „genaue“ Vorhersage ist daher unmöglich, bei einer „verbindlichen“ Zusage muss man schon relativ vorsichtig sein, was man unter welchen Voraussetzungen verspricht. Erlaubt ein Planungsverfahren nur digitale Aussagen darüber, was „geschafft wird“, ist es also unrealistisch und nur wenig brauchbar. Statt dessen braucht man ein Verfahren, das einem zumindest ungefähre Aussagen zur Wahrscheinlichkeit ermöglicht: „So wie dieses Feature derzeit priorisiert ist, wird es mit 80% Wahrscheinlichkeit im nächsten Release enthalten sein“. Genügen einem diese 80% nicht, muss man es eben höher priorisieren – auf Kosten anderer Features, die dadurch weniger wahrscheinlich werden.

Wie kommt man auf Basis agiler Planung zu einer solchen Aussage? Die Basis sind die Schätzungen und die Erfahrungswerte aus den vorigen Iterationen. Die Grafik unten stammt von einem meiner Kunden, also aus einem real existierenden Projekt. In ihr sieht man die aus der Häufigkeitsverteilung abgeleitete Wahrscheinlichkeit, dass innerhalb einer Iteration mindestens n Aufwandspunkte abgeschlossen werden. Man kann aus dieser Kurve zum Beispiel ablesen, dass in mehr als 50% der Fälle mindestens 21 Punkte abgeschlossen wurden, in mehr als 80% der Fälle mindestens 13 Punkte und so weiter. Mit anderen Worten: Ist eine Aufgabe so hoch priorisiert, dass ihr eigener geschätzter Aufwand und der aller höher priorisierten Aufgaben in Summe weniger als 13 Punkte ausmacht, so wird sie in dieser Iteration mit mindestens 80% abgeschlossen werden. Oder noch anders formuliert: Ich kann Aufgaben für bis zu dreizehn Punkte Aufwand für diese Iteration zusagen, wenn mir 80% Erfüllungswahrscheinlichkeit ausreichen. Brauche ich 90%, sollte ich mich auf 10 Punkte beschränken, mit (fast) 100% erreiche ich 8 Punkte und reichen mir 50% so kann ich munter 21 Punkte „versprechen“. Unabhängig von dem, was man versprochen hat, zeigt diese Grafik aber auch, dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen, auch wenn man ziemlich sicher weiß, dass man das kaum erreichen wird (Die Grafik stammt übrigens aus meinem Vortrag für die OOP 2009).

Verteilung der Velocity

Kann ich für eine gegebene Aufgabe sagen, mit welcher Wahrscheinlichkeit sie innerhalb der nächsten Iteration fertig wird, so kann ich daraus auch längerfristige Vorhersagen ableiten, allerdings erstmal nur unter der — reichlich unrealistischen — Annahme, dass sich die Priorisierung in der Zwischenzeit nicht ändert. In der Regel ist das aber schon mehr als ausreichend, um zum Beispiel den Umfang des nächsten Releases kommunizieren zu können, ohne sich hinterher zu blamieren.

Für längerfristige Vorhersagen wird aber auch eine solche wahrscheinlichkeitsbasierte Technik zu unrealistisch. Hier kann man wieder Anleihen in der Meteorologie nehmen, diesmal in der Klimavorhersage. Dort wird nicht mit einem Modell gearbeitet, sondern es werden verschiedene Szenarien unter verschiedenen Annahmen berechnet, aus denen sich ein Korridor ergibt. Aber das würde jetzt den Umfang eines Blogeintrags endgültig sprengen.

Aufmerksame Leser werden jetzt anmerken, dass ich Maximilian Scherfs Frage eigentlich gar nicht beantwortet habe: Mit diesen Techniken kann man nämlich erstmal nur Vorhersagen darüber treffen, welche Features ich zu einem gegebenen Zeitpunkt wahrscheinlich fertig haben werde, nicht aber, wann ein gegebenes Feature fertig sein wird. Auch wenn der Unterschied subtil ist (und in den meisten Kontexten ohne Bedeutung), reflektiert das eine Grundidee iterativer Entwicklung: Die Termine stehen fest, gedreht wird am Umfang.

Das ist zwar unbequemer, als das übliche „Termine und Umfang stehen fest“, aber dafür erspart man sich das ebenfalls übliche Drehen an der Qualität, um die Zusage einzuhalten. Schlechte Qualität ist schließlich ein Selbst- und Fremdbetrug, der für alle Beteiligten sehr teuer ist. Zwar kann man auch bei agiler Planung darauf bestehen, dass bestimmte Features zu bestimmten Terminen fertig sind, aber eben nicht mehr, als erfahrungsgemäß realistisch sind. Also in unserem Beispiel für nicht mehr als 8 Punkte pro Iteration. Das ist zwar nicht immer bequem für die Verantwortlichen, aber realistisch. Und Management auf Basis unrealistischer Annahmen sollte angesichts der derzeit in der Weltwirtschaft zu besichtigenden Folgen nur noch von wenigen mit „durchsetzungstarkem Management“ verwechselt werden und damit verdienter Maßen und endgültig wieder aus der Mode kommen.

Was ist anders bei agiler Planung?

Ein Thema, das meiner Meinung nach oft bei der Ausbildung von Coaches und Scrum Mastern und bei der Einführung von Agilität zu kurz kommt, ist agile Planung. Ich erlebe immer wieder Projektleiter und Scrum Master, die verzweifelt versuchen, ihre Teamplanung in MS Project zu gießen, „weil das hier so gefordert wird“. Das ist in etwa, als würden Sie Spikes unter Ihre Ski montieren, „weil das so gefordert wird“. Machbar, aber sicher keine gute Vorbereitung für außergewöhnlich gute Leistung. Was ist also anders bei agiler Planung?

Um den Eintrag in Grenzen zu halten, möchte ich mich auf die reine Planungstechnik beschränken, also Team- und Kooperationsaspekte außer Acht lassen. Schließlich kann ein Team auch kooperativ Gantt-Diagramme malen, nur es ist eben nicht sonderlich sinnvoll. Warum? Ein wesentlicher Unterschied zu traditioneller Projektplanung ist, dass bei der Agilität nicht die Auslastung der einzelnen „Ressourcen“ (dieser Ausdruck lässt so schön vergessen, dass wir über vernunftbegabte Menschen reden!) optimieren, sondern den Durchflussgeschwindigkeit und Durchsatz von neuen Fähigkeiten des Systems. Wir versuchen also, so viel zusätzliche Wertschöpfung fertig zu stellen, wie in guter Qualität möglich, nicht so viel zu arbeiten, wie möglich.

Schlüssel zu diesem Ziel ist die Erkenntnis, dass in der DV-Entwicklung ja keine Maschinen verplant werden, sondern in der Regel hoch qualifizierte Experten, die durchaus in der Lage sind, sich um ihre eigene Auslastung zu kümmern. Die Planung dient also der Koordination und Fokussierung, nicht der der Arbeitszuweisung. Etwas weniger abstrakt wird festgelegt, was zu tun ist, nicht wer etwas tun soll. Die nächste Person, die frei ist, bzw. das nächste freie Paar kümmert sich dann um die nächste Aufgabe, die ansteht. Das wird üblicherweise als „Pull-Prinzip“ bezeichnet, oft auch (nicht ganz korrekt) als Kanban.

Dieses System hat Vor- und Nachteile. Zum einen ist es wesentlich flexibler, als eine Zuteilungsplanung, die nur dann gut funktioniert, wenn die Bearbeitungsdauer pro „Ressource“ gut vorhergesagt werden kann, aber sehr empfindlich auf Schätzfehler reagiert. Das lässt sich mathematisch mit Hilfe der dabei konstruierten gekoppelten Warteschlangen begründen, die ein chaotisches System darstellen, aber das würde hier zu weit führen. Intuitiv kann das jeder Projektleiter bestätigen, der einmal versucht hat, sein Gantt-Diagramm durchzuhalten oder auch nur aktuell zu halten. Das Pull-Prinzip hingegen reagiert sehr gutmütig auf Schätzfehler und Veränderungen in den Vorgaben, was ebenfalls warteschlangentheoretische Gründe hat.

Der Nachteil ist, dass das Verfahren einen Generalistenansatz im Team benötigt. Teams, in denen jedes Mitglied genaustens seinen „Claim“ abgesteckt hat, in dem nur diese eine Person arbeiten darf („Code Ownership“) bauen trotz Pull-Prinzips genau das gleiche fragile Warteschlangensystem auf, das die Auslastungsplanung schon instabil macht. In der agilen Planung erkennt man diese Situation normalerweise daran, dass an niedrig priorisierten Aufgaben gearbeitet wird, obwohl noch höher priorisierte Aufgaben anstehen, weil „das nur die Eva machen kann“.

Dieser Nachteil ist aber verschmerzbar, weil er ohnehin keine erstrebenswerte Situation darstellt: Wird Eva krank, kann daran das ganze Projekt scheitern. Zudem sind in meiner Erfahrung Kopfmonopole eine der wichtigsten Ursachen für verpasste Termine. Sicherlich wird es immer Aufgaben geben, die Eva effizienter erledigen kann, als Adam. Aber das spielt erst dann eine Rolle, wenn beide auch gleichzeitig anfangen könnten. Bei der Optimierung des Durchsatzes spielt nämlich die Wartezeit auch eine Rolle, anders als bei der Optimierung der Auslastung. Oder, wie Alistair Cockburn formuliert, „Effizienz wird zur Dispositionsmasse abseits des kritischen Pfades“.

Darf man also noch Gantt-Diagramme malen? In seiner Freizeit natürlich. Für ein agiles Projekt spielen sie aber keine Rolle, es gibt keine Entscheidungen, die auf ihnen basieren und sie sind daher Zeitverschwendung. Fortschritt wird mit Hilfe von Burnup bzw. Burndowncharts gemessen und mit lauffähiger Software. Das ist aussagekräftiger, als ein Balken im Gantt-Diagramm, der zu 80% fertig ist, weil 80% der Zeit vergangen sind. Diese Instrumente sind einfacher, effektiver und effizienter, als die beeindruckende Kombinatorik von Ressourcen bei Werkzeugen zur auslastungsbasierten Planung, die von der Realität in der Regel schneller überholt werden, als man sie an der Wand aufhängen kann.

[OOP 2009] Vortrag Agile Planung – Vom Schätzpoker zum Geschäftsmodell

Vortrag Agiles Schätzen und Planen (Photo: Oliver Wihler)„Zu agilen Planverfahren ist eigentlich schon alles gesagt“ meinte Stefan Roock kürzlich auf der Eröffnung der XP Days und nur wer in den vorderen Reihen saß, konnte das ironische Blitzen in seinen Augen sehen. In der Tat stelle ich in Workshops und Diskussionen immer wieder fest, dass den wenigsten die volle Bandbreite agiler Planung bewusst ist. Viele wissen noch, wie man Planungen robust macht gegen Schätzfehler und unvorhergesehene Ereignisse und manch einer beherrscht auch noch selbst-adaptierende Schätzverfahren. Aber Techniken zur langfristigen Vorhersage oder Aussagen zur Wahrscheinlichkeit, dass bestimmte Planungspunkte auch wirklich abgeschlossen werden, sind weithin unbekannt. Dabei erlaubt der Werkzeugkasten agiler Planung nicht nur recht zuverlässige kurzfristige Vorhersagen, sondern bietet bis hin zur Entwicklung neuer Geschäftsmodelle vielfältige Möglichkeiten.

Dieses Spektrum werde ich in meinem Vortrag „Agile Planung – Vom Schätzpoker zum Geschäftsmodell“ auf der OOP in München am 29.1. ab 17:00 Uhr beleuchten. Ich werde zunächst die Basis agiler Schätz- und Planungsverfahren vorstellen und mich dann über mögliche Erweiterungen bis zu Geschäftsmodellen vorarbeiten. Leider kann man das Thema in 60 Minuten nicht erschöpfend behandeln. Ein paar Anregungen und neue Ideen können Sie aber sicher mit nach Hause nehmen, egal ob Sie Projektleiter(in), Scrum Master(in), Fachverantwortlich(e), Product Owner, oder ganz normales Teammitglied sind. Nur über Agilität sollten Sie schon ein wenig gehört haben.

Falls nicht, empfehle ich Ihnen eher den ganztägigen Workshop „Agile Praxis erleben„, den Henning Wolf, Bernd Schiffer und ich gemeinsam am Freitag auf der OOP abhalten werden.

Nachtrag: Mittlerweile sind auch die Feedbackbögen der XPDays in Hamburg ausgewertet (an dieser Stelle noch mal Danke an Arne Roock für die super Organisationsarbeit!). Der Vortrag wurde dort auf einer Skala von +2 bis -2 mit 1,9 bewertet und errang damit Platz 1 von allen Bewertungen. Danke an alle, die mitgeholfen haben, das möglich zu machen, insbesondere Bernd Schiffer! Zitate aus den Feebackbögen:

  • sehr konkret und konzentriert, guter Inhalt
  • regt zum Nachdenken an
  • gute Vortragsweise, super, sehr beeindruckend, viele neue anregungen

Das Photo stellte freundlicherweise Oliver Wihler zur Verfügung