Category Archives: Product Owner

Keine Tasks mehr in Scrum – nur noch Stories?

Posted on by

Ron Jeffries scheint kein Freund von Tasks in Scrum zu sein und schlägt vor Stories in einem Sprint nicht mehr in Tasks aufzubrechen. Die Ideen wurde von Kelly Waters aufgegriffen. Kelly möchte durch Verzichten auf Stories u.a. die Prozesskosten senken.

Ja, das Ziel die Prozesskosten zu senken verfolge ich auch – trotzdem ist das Planning 2, in dem die ausgewählten Stories in Tasks aufgebrochen werden, den Aufwand in den meisten Fällen mehr als wert. Warum?

Einige Gründe Pro Stories / Pro Planning 2 sind:

  • Plausibilitätschecks: Wenn eine Storie in Einzelteile zerlegt wird, kommt es immer wieder mal vor, dass ein Risiko bzw. ein erheblicher Mehraufwand identifiziert wird.
  • Abhängigkeiten: Ja, ich weiß. Abhängigkeiten sollen schon auf Story-Ebene reduziert bzw. eliminiert werden. Wir haben aber beispielsweise eine extreme Abhängigkeiten zu internen Zulieferern (Termine, Qualität) und zu unserem Betrieb. Abhängigkeiten werden auf Task-Ebene schneller gefunden und sind besser zu managen.
  • Schwerpunkte in der Entwicklung: Obwohl in Scrum Generalisten bevorzugt werden, hat doch jeder Entwickler seine Stärken und Schwächen. Dies kann man in der Planung ebenfalls besser berücksichtigen. Nicht immer ist jeder verfügbar, nicht immer hat jeder alle Themen im Blickfeld. Ein TASK-Board hilft dabei.
  • Task-Breakdown: Auch wenn ein Task-Breakdown anscheinend immer unbeliebter wird und letztendlich auch die DONE-DONE Scrum Stories das Sprint-Ergebnis ausmachen, ist ein Task-Breakdown ein wichtiger Indikator. Ein Hilfsmittel, um zur rechten Zeit die rechten Fragen zu stellen. Die Antwort (vom Team) kann dann immer noch sein „passt schon“, aber es kommt auch immer wieder mal vor, dass auch im gesamtem Team der Optimismus stärker ausgeprägt ist als der Realitätssinn.

Trotz all dieser wichtigen Aspekte vom Planning 2 hat Kelly wohl Recht, wenn er behauptet, dass Planning 1 der wichtigere Teil ist: Anforderungen stellen, verstehen, priorisieren. Normalerweise nehme ich als Product Owner auch nicht am Planning 2 teil. Falls das Team jedoch Rückfragen hat oder die Analyse (Zerlegung der Stories in Tasks) den Umfang von Planning 1 in Frage stellt, dann wird nochmals mit mir über den Umfang des Sprints geredet.

Kundenzufriedenheit vs Kosten

Posted on by

In der Gedankenwelt vieler Agilisten wird das Thema “Kosten” gerne verdrängt und auf das Ziel Erfüllung des Kundenwunsches verwiesen. Ich habe mittlerweile mehrere Projekte mit agilen Ansätzen – vor allem Scrum – als Projektleiter und ProductOwner durchgeführt und glaube, dass hier sehr schnell unverantwortlich vereinfacht wird.

Kundenzufriedenheit vs Kosten

Zu einem Artikel von Jens habe ich bereits vor einiger Zeit eine Antwort verfasst, in der ich letztendlich darauf hinweise, dass nicht die Kundenzufriedenheit das primäre Ziel sein kann – sondern die Gewinnerzielung / Sicherung der Existenz das primäre Ziel jedes  Unternehmens ist. Die einfach Regel ist für Unternehmen immer: Einnahmen > Ausgaben (der zu betrachtende Zeitraum ist abhängig von liquiden Mitteln und externen Marktgegebenheiten). Alle anderen Grundsätze sind nachgelagert und dienen diesem Primärziel, welches jedoch nicht mit der Gewinnmaximierung um jeden Preis verwechselt werden darf. Ausgenommen hiervon sind gemeinnützige, nicht profitorientierte Organisationen.

Die Kundenzufriedenheit spielt bei der Erreichung des Ziels der Existenzsicherung und der langfristigen Profitabilität unbestritten eine zentrale Rolle, wird jedoch gerade in der agilen Welt zu oft als alleiniges Heilmittel angesehen. Es wird oft aus der Sicht des Ingenieurs argumentiert, der Prozesse und Arbeitsergebnisse optimieren möchte.

Die Rolle des ProductOwner ist beispielsweise bei Scrum nur unzulänglich ausdiskutiert. Themen wie Cashflow und (kurz- und mittelfristige) Rentabilität werden ausgeklammert und auf die (möglichen) langfristigen positiven Effekte der Kundenzufriedenheit verwiesen. Risiken wie ein Liquiditätsengpass finden in die Argumentation keinen Eingang. Die Argumentation in Scrum lautet dann fast immer “der ProductOwner ist für das BusinessValue zuständig” oder “der ProductOwner ist für den finanziellen Erfolg verantwortlich” – kurz: Der ProductOwner soll sich um diese Details kümmern! Wenn dieser mit hohen Kosten unzufrieden ist, dann wird das Qualitätsargument angeführt oder die Kundenzufriedenheit als Primärziel benannt. Beides sind wichtige Punkte, die strategische Wettbewerbsvorteile darstellen (was in vielen Untersuchungen nahegelegt wird). Aber beide können ein Unterfangen aus finanzieller Sicht auch ruinieren, da die Kosten erhöht werden. Ist das Projekt nicht strategischer Natur und wird die angestrebte Rendite nicht erreicht, dann ist es schlichtweg gescheitert – selbst wenn ein hervorragendes Produkt erstellt wurde. Dieses kann eventuell als Referenz für die Fähigkeiten eines Teams herangezogen werden, aber das Projektziel wurde nicht erreicht.

Jens ist in einem zweiten Artikel auf bestimmte Aspekte meiner Argumentation eingegangen und hat seine Aussagen bezüglich Kundenzufriedenheit weiter konkretisiert. Er verweist darauf, dass in der agilen Welt das Projektziel als “Kunde ist sehr zufrieden” definiert wird, während in der traditionellen Welt “Projekt erreicht Zeit, Budget, Qualität” als Ziel angenommen wird.

Probleme mit Werkverträgen als Realität für die meisten Teams

Ich glaube bei der Diskussion um Kosten wird schnell vereinfacht und letztendlich darauf hingewiesen, wie es eigentlich sein sollte – die Realität interessiert weniger. In den meisten Fällen arbeiten heute Teams in der Projektentwicklung weiterhin mit Werkverträgen, d.h. es wird ein definiertes Ergebnis zu einem bestimmten Termin geschuldet. Schon diese Rahmenbedingungen machen es schwer bestimmte agile Praktiken umzusetzen.

Viele ScrumMaster machen sich das Leben einfach und sagen “die Vertriebler sollten andere Verträge machen” oder “der ProductOwner muss damit umgehen”. Dies ist genau die große Herausforderung, mit der viele Projektleiter / ProductOwner heute zu kämpfen haben und unterstreicht die große Bedeutung dieser Rollen. Ansätze zur besseren Vertragsgestaltung werden glücklicherweise mittlerweile diskutiert.

Der Kunde wählt einen Werkvertrag meist, um Aufwand und vor allem Risiken an den Auftragnehmer zu verschieben. Der Auftragnehmer stimmt dem zu, da er glaubt die Kosten (inkl. finanziell bewerteter Risiken) sind geringer als die Einnahmen (oder es gibt “strategische Ziele”).

Konfliktpotential

Die Angebotskalkulation (Aufwand/Kosten) bei Werkverträgen basiert auf dem geschuldeten Ergebnis, welches dann leider im Voraus in genügender Genauigkeit definiert werden muss (erhebliches Konfliktpotential mit agilen Gundsätzen). Es ist demnach von sehr hoher Bedeutung, die Kosten (den Aufwand) genau im Blick zu haben.

Fast automatsich kommt es bei Festpreisprojekten zu Konflikten zwischen Projektkalkulation (Aufwand/Kosten/Ergebnis) des Auftragnehmers und aktuellem Kundenwunsch. Änderungen im Projektverlauf sind normal und mit einer agilen Entwicklungsmethodik auch möglich. Wenn der Kunde mitten im Projekt erkennt, dass vom spezifizierten Ergebnis abgewichen werden muss, dann ist ein Scrum-Team in der Lage dies zu tun. Zusammen mit dem ProductOwner kann das Team vor der Umsetzung den Aufwand hinreichend genau schätzen und die Kosten können ermittelt werden.

Die agile Sichtweise schlägt jedoch stark vereinfacht vor, Kundennutzen grundsätzlich zu maximieren. Dies darf jedoch nicht zu Lasten des Gesamtbudgets des Projektes gehen! Dieser Konflikt muss durch den ProductOwner bzw. den Projektleiter erkannt und zusammen mit dem Kunden gelöst werden. Der PO/PL muss zusammen mit dem Kunden im Rahmen einer Diskussion um Änderungswünsche ein neues Ergebnis unter Einbeziehung aller Faktoren definieren. Hierbei kann es zu finanziellen/terminlichen Änderungen kommen.

Eine solche Diskussion muss im Projektkontext geführt werden, auch wenn sie den “Kunden nicht glücklich macht”; aber sie zu unterlassen wäre fahrlässig.

Natürlich kann auch eine Entscheidung basierend auf dem Wunsch nach langfristiger Kundenbindung getroffen werden. Das führt schließlich dazu, dass erkannter Mehraufwand dem Kunden nicht in Rechnung gestellt werden muss.

Lösungsansätze

Diese Situation kann nur entspannt werden, wenn genügend Verhandlungsmasse in dem Werkvertrag vorgesehen ist (der Kunde kann Stories tauschen). Wenn möglch sollte ein Dienstvertrag geschlossen werden. Der zweite Weg ist der bessere für agile Teams, allerdings erfordert er den aktiven Kunden, der leider sehr selten ist.
Es ist demnach von großer Bedeutung, die Vertragsgestaltung dahingehend zu verbessern, dass Änderungen möglich sind. Von sehr viel größerer Bedeutung ist jedoch wohl die noch stärkere Einbindung des Kunden mit entsprechender Entscheidungsbefugnis. Genau dies wird von fast allen agilen Ansätze gefordert aber hier gibt es meist auch noch die größten Defizite.

Review-Spruch des Tages

Posted on by

(geklaut aus unserem internen Team-Blog)

Der Review-Spruch des Tages kam diesesmal von Entwickler G., der uns mit einer kleinen Perle beglückt hat:

G. führt gerade ein neues Feature vor, als plötzlich die AjaxMap weg ist. Felix fragt natürlich gleich, wo die Karte ist. Einsatz G.:

“Was weiss ich, wo die Karte ist. Die ist halt grad nicht da. Eben ist jemand hier gesessen, der ist jetzt auch nicht mehr da. So was passiert.”

Hintergrund: Wir entwickeln Web-Anwendungen mit der Routen berechnet und Karten dargestellt werden. Seit einige Zeit leiden wir etwas unter unserer Infrastruktur (Server, Netzwerk, Loadbalancer) – ein Thema, um welches sich unser SM im Prinzip in jedem Sprintkümmern muss. Als Effekt bekommt man teilweise komische Auswirkungen, v.a. im Review wenn das Testsystem genutzt wird.

Story habe ich abgenommen, da ich zuvor gesehen habe, dass es funktioniert. Ist schon was wert, immer mal wieder im Team-Raum rumzuhängen ;-)

Story Points und Personentage

Posted on by

Klassische Bewertung von Arbeitspaketen

In der klassichen Projektplanung werden Arbeitspakete üblicherweise mit Aufwand und Dauer geschätzt (beides in Tagen), teilweise wird auch mit Spannbreiten gearbeitet. Zusätzlich zu der Angabe des Aufwands und der Dauer kann noch eine Risikobewertung hinzugefügt werden. Es wird üblicherweise nicht mit relativen Größen gearbeitet.

Story Points in Scrum

In Scrum nutzt man zur Einschätzung von Stories relative Größen, die sogenannte Story Points (SP). Die SPs sind keine absoluten Werte (wie Personentage) sondern ein recht unscharf definiertes Konstrukt, welches Komplexität und Aufwand beschreibt. Wichtig hierbei ist, dass eine Story mit 5 SP größer/komplexer ist als eine Story mit 2SP. Die Einträge im ProductBacklog werden durchgeschätzt, für eine Sprint-Planung werden die Schätzungen meist noch einmal evaluiert und geprüft, ob die Stories auch wirklich gut geschrieben und gut geschätzt sind. Letztendlich muss eine Entscheidung getroffen werden, wieviele Stories mit ihren Story Points in einen Sprint übernommen werden können. Zumindest wenn die Sprint Planung auf Basis von Story Point durchgeführt wird, was von den meisten Scrum-Evangelisten so vorgeschlagen wird.

Sprint Planning ohne Story Points

Mike Cohn verweist in einem älteren Beitrag darauf, dass er Abschätzungen mit Story Points nur für die Release Planung, nicht für die Sprint Planung einsetzt. Im Sprint Planning lässt er das Team die vom PO gewünschten Stories im Detail analysieren und in Stunden/Tage bewerten.

Sein Hauptargument:

Suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.”

This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Planning 1 und Planning 2

Wir setzen ein zweistufiges Verfahren ein: Planning 1 und Planning 2. In Planning 2 diskutieren wir auf Basis Story Points und einer durchschnittlichen bisher erreichten Velocity und prüfen, ob das Ergebnis “passen kann”. In Planning 2 werden die ausgewählten Stories wie von Mike beschrieben vom Team im Detail nochmals analysiert und die einzelnen Tasks bewertet. Hierbei kann es vorkommen, dass eine Korrekturmaßnahme nötig ist oder weitere Detailinformationen benötigt werden. In Planning 2 ist der ProductOwner üblicherweise nicht anwesend, sondern wird nur bei Rückfragen hinzugezogen.

Umrechnung/Abbildung von Story Points auf Personentage

Sobald Story Points benutzt werden stellt sich immer die Frage der Umrechenbarkeit von Story Points zu Personentagen. Wie bereits erwähnt nutzen wir hierzu eine durchschnittliche Velocity (Velocity der letzten n Sprints).

Eine Herausforderung ist hierbei, dass gerade bei komplexen langlaufenden Projekten die Forderung “fixed sprint length” zwar meist eigehalten werden kann, allerdings im Ergebnis nicht immer gleich viele verplanbare Tage vorliegen. In den letzten 4 Sprints unseres Teams gab es beispielsweise nie eine gleich große Anzahl verplanbarer Tage (sizeable days) sondern stets große Schwankungen. Hier spielen Themen wie “Einfluss der Linie”, “Urlaub”, “Weiterbildung” etc. eine Rolle. In einem Sprint können 20 PT verplant werden, im nächsten 15 und im übernächsten 30. Es ist also sehr wichtig festzuhalten, wieviele Story Points in wievielen Tagen umgesetzt werden konnten.

Puffer und Story Points

Interessant ist auch die Frage, wie mit (“den elenden”) Support-Puffern umgegangen wird. Die reine Scrum-Lehre stößt sich an solchen gedeckelten Puffern, die böse harte Welt da draussen fordert diese jedoch aktuell (noch) ein. Ziel muss es IMHO immer sein, den Puffer so klein wie möglich zu behalten, d.h. so viele Tage wie möglich mit Stories zu belegen (“sizable days”) und so wenig wie möglich für Support-Tasks zu blocken.

Wenn mit Puffern gearbeitet wird, dann kommen Frage auf wie:

  • Sollen solche Puffer – die eigentlich in Tagen reserviert werden müsssen – auch in Story Points ins Planning einfliessen?
  • Falls Stories (geschätzt mit SPs) in einem Support-Puffer umgesetzt werden – zählen die Story Points zur Velocity falls man die dazu benötigten PTs in die verfügbaren (sizeable) Tage hinzufügt?
  • Wie kommuniziert man den Erfolg eines Teams nach aussen, wenn sich dieser zusammensetzt aus erledigten Stories und extrem produktiven Support-Puffern?

Es ist ersichtlich, dass dieses Thema ein sehr ergiebiges ist, in dem die unterschiedlichsten Meinungen vertreten sein können.

Scrum: Einsatz von Jira & Confluence

Posted on by

Immer wieder kommt die Frage auf, welche Tools eingesetzt werden können, um die Backlogs und Sprints besser handhaben und planen zu können.

Ich habe jetzt einige Erfahrung mit dem Einsatz von Jira und Confluence und auch entsprechend auf eine Frage in der scrumdevelopment-Mailingliste geantwortet:

Hi Ivo,

I think using Jira & Confluence (or any other good tracker+wiki) will
allow you to maintain your Scrum product backlog and help you to plan
and track sprints. I do this as PO with my team for quite some time
now. However we feel like it is best for planning 2 to eliminate all
disturbing technology to help the team to focus on the stuff they have
committed to.

Our approach work basically like this:

BACKLOG MAINTENANCE
The stories and bugs are collected in Jira and flagged for the
backlog. Everybody interested in the backlog can check what’s in and
what’s not. The backlog is maintained on a regular basis (estimations,
business value, questions/details added).

SPRINT PLANNING 1
In the planning 1 session we figure out what will fit into the next
sprint, the issues are marked correspondingly. We agree on a sprint
goal. A page describing the current sprint is created in Confluence,
containing the selected stories as links to Jira issues and some
additional information (available days, predicted story points,
external events, sprint goals). Everybody interested is able to
understand what the team is working on in the current sprint.

SPRINT PLANNING 2
The panning 2 is made without Jira (or any other electronic tools)
using a good old white board (actually it became a whole wall in the
team room) full of sticky notes. The stories chosen in planning 1 are
analyzed in detail, the details end up as sticky notes (tasks) on the
white board. Everybody interested in the details can either ask the
PO/SM or visit the team room.

SPRINT RESULTS
The results (issue/story resolved or questions that must be
documented) will end up in Jira again. This will give an overview if
the selected stories could be finished. The sprint page in Confluence
is updated with details for the review meeting.

To handle all the “marking” or “selecting” you will end up working a
lot with Jira filters. That’s fine as the results from these filters
can be integrated into Confluence.

Cheers
Felix

http://www.armerkater.de – Scrum und so …

SLM: Agile Offshoring – With Success!

Posted on by

YOU NEED TO COMMUNICATE!

Ein sehr lehrreiches Interview mit Jeff Sutherland & Serge Beaumont in dem die Geheimnisse erfolgreicher agiler Softwareentwicklung mit verteilten (offshore) Team besprochen wird.

Obwohl Offshoring auf den ersten Blick dafür geschaffen zu sein schein, um Kosten zu sparen wird in vielen Projekten eine andere Erfahrung gemacht: Nur wenn die indischen Entwickler so produktiv sind wie die lokalen Entwickler rentiert sich Offshoring unter Kostengesichtspunkten. Jeff spricht ein Beispiel an, in dem die Kosten für einen indischen Entwickler lediglich 1/3 so hoch waren wie die für einen Entwickler im lokalen (US) Team. Trotzdem hat sich das Offshoring  nicht gelohnt. Diese Erfahrung wurde genutzt, um die Kostentreiber zu identifizieren und Praktiken zu entwickeln, welche die Probleme verringern. Kommunikation und Vertrauen stehen seitdem im Fokus.

Die Herausforderung ist es, bei einem verteilten Team eine funktionierende Kommunikation zu etablieren und ein echtes Team zu formen. Es gilt technische und psychologische Hürden zu überwinden.

Einige Best Practices:

  • Kommuniziert! Sorgt dafür, dass die Kommunikation zur gleichen Zeit von allen Seiten vorangetrieben wird, damit der “Kommunikationsgraben” überwunden wird.
    • Hier ist v.a. der Scrum Master gefragt alle möglichen Hindernisse so schnell wie möglich aus dem Weg zu räumen.
  • Lernt euch kennen! Bei verteilten Teams ist es wichtig, dass gegenseitige Besuche von Teammitgliedern stattfinden. So entsteht Vertrauen.
  • Daily Standup so organisieren, dass alle Teammitglieder teilnehmen können! Konkret bedeutet dies den Einsatz von Telefon- und Videokonferenzen und Screensharing. Wenn möglich elektronische Whiteboards einsetzen.
  • Moderne Kommunikationsmittel nutzen! Alles nutzen das irgendwie helfen kann! Videowalls, elektronische Whiteboards, Screensharing, IM, …
  • Velocity des lokales Teams muss bekannt sein bevor Mitglieder am entfernten Standort hinzugezogen werden! Nur so kann gemessen werden, ob die Produktivität steigt oder sinkt.
  • Scrum Master nach Indien/Russland/Hindukusch. Ja, der SM wird verschickt ;-)
  • …

Leider habe ich es bisher selbst nur zu einem einzigen REMOTE DAILY gebracht – und davon habe ich mangels Equipment auch nicht sonderlich viel mitbekommen.

Im zweiten Teil wird noch über die Herausforderungen der Rolle “Product Owner” gesprochen, v.a. dass diese Rolle meist unterschätzt wird.

Der Product Owner

Posted on by

Optimale Arbeitsweise

Boris erläutert seine Sicht auf die Rolle des Product Owners.

Laut ihm gibt es zwei Modelle:

Modell 1 (Jeff Sutherland)

  • Der PO arbeitet mit Business Analysts zusammen und kann das Team detailliert informieren.
  • In diesem Szenario ist der PO relativ nahe am Team.

Modell 2 (Ken Schwaber)

  • Der PO fokussiert sich auf die finanziellen Aspekte, ist relativ weit weg vom Team.
  • In diesem Modell gibt der PO nur das Ziel vor und das Team muss sich mit Business Analysten abstimmen um Details zu klären.

In beiden Modellen wird der PO an dem finanziellen Erfolgs des Produktes gemessen, genau das soll sein Fokus sein. Er muss wissen wohin die Reise gehen muss – er muss nicht jedes Detail kennen. Dafür gibt es Business Analysten. Ein PO arbeitet 100% in seiner Rolle als PO und ein Entwicklungsteam hat genau einen PO.

Bekannte Modelle aus der Praxis

Leider habe ich noch nie eines der oben genannten Modelle in der Praxis beobachten können. Vielmehr ist der PO wohl die Rolle in Scrum, die am stärksten von der Umwelt unter Druck gesetzt werden kann. Oftmals soll es der PO leisten aus der Scrum-Welt in die “andere Welt” zu übersetzen (Festpreisangebote, Ressourcenplanung). Aus diesem Spannungsfeld leitet sich wohl auch die Forderung vieler Scrum-Evangelisten ab, dass die ganze Organisation agile werden muss.

Entscheidungsfindung

Zu oft ist der PO jedoch eben nicht mit echter Entscheidungsbefugnis ausgestattet sondern reportet an ein Steering Committee oder an einen übergeordneten Manager. Dieses gibt dann die entsprechenden Grundsatzentscheidungen vor. Um eine Entscheidungsgrundlage zu schaffen ist der PO damit beschäftigt den aktuellen Stand und den Blick in die Zukunft in geeigneter Form zu visualisieren.

Multi-Projekt-Scrum

Es gibt beim Multi-Projekt-Scrum die Konstellation, dass der PO gleichzeitig der PM (Project Manager) mehrere im Team bearbeiteter Projekte ist und weitere Aufgaben von anderen PMs (Projekten) an ihn herangetragen werden. Die Stories muss er (zusammen mit dem PMs) bewerten, in eine entsprechende Reihenfolge bringen und dann dafür die Freigabe bekommen.

Multi-Projekt-Scrum ist per se recht problematisch, ich behaupte jetzt einfach mal, dass ein Multi-Projekt-Team auch nie “hyperproduktiv” werden kann. Es gibt zuviele Scope-Wechsel, selbst wenn der PO es schafft die Sprints mit so wenig Projekten wie möglich zu bestücken. Es gibt auch zuviele Stakeholder, die von aussen auf den PO und das Team einwirken – egal wie sehr sich der PO und der SM anstrengen – das Team wir doch immer wieder abgelenkt.

Vielleicht schreibe ich bei Gelegenheit mal etwas mehr über die ganzen Herausforderungen und Gefahren beim Multi-Projekt-Scrum. Interesse?

Risiko: PO als Verwaltungsjob

Gerade in Team die mehrere Projekte und zusätzlich Supportaufgaben übernehmen müssen, ist eine aussagekräftige Planung über die nächsten beiden Sprints hinaus eine große Herausforderung (die nie entsprechend gewürdigt wird). In dieser Form degeneriert der PO schnell Richtung “Team- und Storyverwalter”. Das muss erkannt werden und der PO muss aktiv gegensteuern und sich auch gegen viele Widerstände durchsetzen können. Hierzu benötigt er den Rückhalt seiner Vorgesetzten, d.h. er muss (uneingeschränktes) Vertrauen geniessen.

eXtreme Pragmatic Agile Project Manager

Posted on by

Das Leben ist kein Streichelzoo und drum haben wir es nicht so leicht, wie wir’s gerne hätten.

Worauf ich hinaus will? Nunja, auf mein Job als “XPAPM” (“eXtreme Pragmatic Agile Project Manager”). Ich musste ja vor kurzem wieder einmal erfahren, dass es im Kontext von Scrum keinen “Agile Project Manager” geben darf.

Aus Protest bin ich jetzt auch XPAMP und setze auf XPSLP (eXtreme Pragmatic Scrum-Like Process).

Als XPAPM bin ich weder ein reiner PO noch ein SM noch Team. Ich bin damit aus Scrum-Sicht nicht existent sondern in einer Zwischenwelt unterwegs ;-)

Beispielsweise beschäftige ich mit dem kritischen Pfad in Projekten und benutze MS Project, um Meilensteine und Aufgaben grob zu visualisieren und als Diskussionsgrundlage mit dem Kunden, falls dieser sich nicht auf eine Betrachtung des PBL oder der Sprint-Backlogs einlassen will. Ausgehend von diesem grundlegenden Plan, in dem wichtige Termine festgehalten sind werden Themen (Scrum-speak “Epics”) einem oder mehreren Sprints zugeordnet. Schnell erkennt man Abhängigkeiten, die besonderer Aufmerksamkeit bedürfen – und noch viel wichtiger – schnell erkennen eine ganze Menge Stakeholder in dem Projekt, dass sie evtl. auch noch etwas tun müssen oder eine Zulieferung benötigen.

Alles ziemlich verrucht im Scrum-Universum ;-)

Mike Cohn schlägt ja hier eine aus dem PBL erzeugbare (?) Visualisierung vor: Visualizing a Large Product Backlog with a Treemap. Auch nicht schlecht, allerdings muss ich dann meinen Kunden zunächst coachen.

Also, ich setze MS Project ein, obwohl ich gerade ein großes Projekt mit Vollgas als PO in einem Team entwickeln lasse – soviel zu “Traditional Project Management Software“. Der Projektplan im MS Project darf nur nie eine gewissen Komplexität übersteigen – es sollten nur die wichtigsten Meilensteine und grobe Vorgänge enthalten sein. Meine Kunden wollen meist mehr, aber da gelingt es dann doch recht häufig für Details auf die Sprintplanungen zu verweisen.