Archiv der Kategorie: Product Owner

Workshop zu Lean Product Development Principles mit Donald Reinertsen

Viele Agilisten ist nicht bewusst, auf welchen grundlegenden Prinzipien agile Methoden basieren und warum manche Praktiken eben nicht immer hilfreich sind, auch wenn sie im Kanon der agilen Frameworks einen Stammplatz haben.

Bei Nachfragen wird schnell auf das agile Manifest und die zugehörigen agilen Prinzipien verwiesen. Der eine oder andere wird es noch um die „agilen Werte“ ergänzen (vgl. Scrum Values).

Diese Betrachtungsweise – so hilfreich und inspirierend sie sein mag – ist jedoch für tiefergehende Überlegungen jedoch nur bedingt geeignet. Da sowohl Manifest als auch die zugehörigen „Agile Principles“ aus einem bestimmten Kontext heraus formuliert wurden, gibt es immer wieder Bemühungen diese zu aktualisieren und in ihrer Anwendbarkeit auszuweiten (z.B. durch Scott Ambler). Mangels Problembewusstsein vieler agiler Protagonisten bleiben diese Bemühungen bisher leider eher unbeachtet.

Seit einigen Jahren wird neben „Agile“ auch zunehmend über „Lean“ gesprochen, welches unter dem Stichwort „Lean Production“ und „Lean Management“ im produzierenden Gewerbe schon länger bekannt und im Einsatz ist.

Lean Product Development

Es wurde immer wieder versucht die Prinzipien aus der Lean Production auf die Produktentwicklung anzuwenden – häufig mit mäßigem Erfolg. Dies liegt daran, dass einige grundlegende Regeln und Prinzipien bei der Produktentwicklung anders sind als bei der Produktion von Produkten. Richtig verstanden, helfen diese Lean Product Development Principles dabei, geeignete Praktiken und Bewertungsfunktionen für Agile und Lean Prozesse zu definieren bzw. einzuordnen.

Genau mit diesen Prinzipien im „Lean Product Development“ beschäftigt sich der auf dieem Gebiet international als Vordenker bekannte Donald Reinertsen seit Jahren. Sein Buch „The Principles of Product Development Flow: Second Generation Lean Product Development“ kann hier mittlerweile als Standardwerk angesehen werden.

 

Executive Workshop mit Donald Reinertsen

Im März konnte ich zusammen mit ca. 30 anderen Beratern und Executives an einem Workshop mit Donald Reinertsen teilnehmen. Herzlichen Dank an dieser Stelle an die Organisation durch bor!sgloger training KG und KEGON AG, die diesen Workshop möglich gemacht haben.

Der Einstieg in den Workshop war eine kurze Zusammenfassung, wie Lean die Produktion verändert hat und warum dies die Ertragslage von Unternehmen verbessert. Im nächsten Schritt verdeutlichte Don nochmals die Unterschiede zwischen Produktion und Entwicklung um dann über die momentan existierenden Spielarten (Schulen) von Lean Product Development zu sprechen:

  • Toyota School – Toyota definiert Lean und man muss nur Toyota kopieren, um Erfolg zu haben. Interessant an dieser Stelle war der Hinweis auf die begrenzte Innovationskraft von Toyota (Welche Innovationen neben Prius / Hybrid kommen von Toyota?)
  • Repackaging – Einfach die Ideen aus dem Lean Production übernehmen und unreflektiert anwenden.
  • Basic Principles – Identifikation von logischen und mathematischen Prinzipien im Lean Manufacturing und diese dann übertragen auf Lean Production. Übernahme fortschrittlicher Konzepte aus anderen Domänen (Verkehrswesen, moderne Kriegsführung, Internet/Netzwerkoptimierung).

Der restliche Workshop war ausgerichtet an der bekannten Strukturierung aus seinem Buch:

  • Ökonomische Betrachtung / Wirtschaftlichkeit: Wir müssen Attraktivität und Investitionsbedarf bewerten und vergleichen können.
  • Warteschlangen: Zu hohe Auslastung als primärer Grund, dass Systeme kollabieren bzw. nicht mehr zu beherrschen sind und der Investitionsbedarf („Kosten“) immer weiter steigt.
  • Variabilität / Schwankungen: Wenn in der Entwicklung Wert erzeugt wird, dann steigt automatisch auch die Variabilität . Dies ist jedoch nicht automatisch negativ zu bewerten.
  • Losgröße: Die Funktion aus Lagerkosten und Transaktionskosten muss optimiert werden.
  • Umlaufbestand (WIP, unvollendete Arbeit): Bedeutung von Transparenz, um für das Problem des Umlaufbestands zu sensibilisieren.
  • Umgang mit Unsicherheit: Bedeutung von Rhythmus und Synchronisation beim Umgang mit Unsicherheit.
  • Schnelles Feedback: Varianz und Risiken sind immer Teil einer Produktentwicklung – umso wichtiger ist schnelles Feedback.
  • Kontrolle & Entscheidungen: Zentral vs. Dezentral – soviel wie möglich „vor Ort“ entscheiden, da „Warten auf Entscheidungen“ eine erhebliche Investition darstellt und Risikokosten steigen (da der Markt sich weiter bewegt).

Diese Inhalte des Buches waren mir bereits bekannt, allerdings wurden sie durch weitere Erläuterungen und Beispiele sehr anschaulich und eingängig erläutert. Besonders die immer wieder angesprochenen Fallbeispiele konnten deutlich machen, welche Relevanz die Product Development Principles gerade bei grundlegenden Entscheidungen für das Management haben.

Für mich ist erstaunlich, wie wenig die meisten agilen Praktiker und Berater über diese Prinzipien wissen, reden und umsetzen. Im Vergleich zu der fundierten Betrachtungsweise die die Lean Product Development Principles darstellen, kann man viele beliebte Beiträge auf unseren „agilen Konferenzen“ eher dem Unterhaltungsgenre zuordnen: Schöne bunte Bilder, unterhaltsame Geschichten und ein wenig Zauberei und Show.

Hierzu bot der Workshop ein klares Kontrastprogramm:

  • Keine bunten Bilder sondern eher altbackene Folien. Dafür gut erläuterte (minimalistische) Skizzen auf Flipcharts und wenige, klare Zahlen mit hoher Aussagekraft.
  • Keine leicht verdaulichen Anekdoten sondern Einblicke in schwierige Fallbeispiele mit gekonnter, detaillierter Erläuterung des Kernproblems – und dem Hinweis, dass es eben nicht die eine Wahrheit gibt sondern das Formulieren einer hilfreichen Lösung schwere Arbeit ist.
  • Keine Zauberei sondern relativ trocken aber absolut fundierte Argumentationsketten.

ReinertsenSkizze

Herrlich! Zumindest ein Kontrastprogramm nach einem (durch mich wahrgenommenen) Zuviel an Marktschreierei und Esoterik auf den üblichen Veranstaltungen, welches gerade die letzten 1-2 Jahre durch das Thema „Agile @ Enterprise“ bzw. Skalierung von Agilität zugenommen hat.

Mein Fazit: Ein gut investierter Tag für jeden Entscheider, der dazu bereit ist seinen eigene Sichtweise zu hinterfragen und nach mehr sucht als das, was wir heute häufig als agile Rezepte verkauft bekommen.

Hinweis: Eine weitere Zusammenfassung des Workshops findet sich im Blog von KEGON.

KEGONLogo300dpi

 

 

Eine bessere Version des Scrum Flow DiagrammsA better Version of the Scrum Flow diagram

Da ich morgen einen Workshop zum Thema Scrum und JiraAgile halte, habe ich nach bekannten Bildern des Scrum-Flow gesucht, um einen „Roten Faden“ duch den Workshop (Tabs: Plan, Work und Report) zu ziehen. Leider empfinde ich die existierenden Versionen des Scrum Flow Diagramms als unzureichend, da sie die Arbeit der Product Owner bestenfalls als „Sortierer“ von Listen darstellt.

Ich begann mit dem klassichen Flow um nach der dritten Iteration eine Skizze eines besseren Flow’s zu erhalten.

scrum_flow_creation

Das Ergebnis war anders als ich es mir zu Beginn vorgestellt hatte, aber die Darstellung der Arbeit des Product Owner (und seines PO-Staff) fand ich eben so gut, wie die Möglichkeit einige Artefakte und Zeremonien darzustellen. Weiter Aufgaben eines Product Owner (z.B. Abstimmung der Stories im skalierten Umfeld) können einfach hinzugefügt werden.
Die Zeichnung geht auch wunderbar mit Marty Cagan’s Dual-Track-Scrum einher.

scrum_flow_final

Wenn Ihr Ideen habt, wie ich diese Zeichnung weiter verbessern kann, oder wenn Ihr mehr darüber erfahren wollt, wie man Jira mit Scrum vereint, dann kommentiert diesen Beitrag oder schreibt mir persönlich.

The click here to open the english version of this post.

Ihr könnt dieses Bild frei für Trainings oder Workshops benutzen, solange ich als Urheber genannt werde ;-)As I’ll be holding a workshop about the best way to use JiraAgile with Scrum, I planned to show the „standard“ Scrum Flow Chart to explain the three JiraAgile-Tabs (Plan, Work and Report). What I found missing in all of the existing Diagrams is the visualizations of the Product Owners‚ work. One could believe their sole purpose is sorting lists.

I started with a sketch of the regular flow and continued to iterate until I came to the bigger painting.

my version of the Scrum Flow Chart

The Result was a different kind of diagram than I had in mind at the start, taking the PO (and his staff) into account, while explaining some of the Ceremonies and Artifacts of a Sprint along the way. You could easily adapt it for a scaled Environment.
This „piece of art“ also corresponds quite nicely with Marty Cagans‘ Dual-Track-Scrum.

My final version of the Scrum Flow Chart

If you have any Ideas on how to improve this Scrum Flow Diagram, or want to know more about the art of using Jira with Scrum leave a comment below or contact me directly.

You can use this drawing freely for your trainings of workshops as long as you acknowledge me as the author ;-)

Alistair Cockburn über Use Cases vs User Stories

Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later.

Auszug aus einem lesenswerten Artikel („Why I still use use cases“), in dem Alistair Cockburn erklärt, warum er Use Cases für ein wertvolles Mittel zur Identifikation und Dokumentation von Anforderungen hält.

Mike Cohn zu Release Planning

Mike Cohn in einer (sehr interessanten) Diskussion über Release Planning nach einem Hinweis, dass viele Teams glauben nur ihre Sprints planen zu müssen:

I had spent years as a VP of Development and if my teams had ever come to me with statements like that as part of selling me on a great new process, I would have not tried the new process. Some amount of predictability is valuable (and easily achieved).

Commitment Product Owner

Stefan Roock schreibt über das Commitment des Product Owners, dass dieser sich ebenfalls auf die Sprint-Planung verpflichtet. Der PO darf – wie das Entwicklungsteam auch – deshalb das Ergebnis der Sprint-Planung nur dann akzeptieren, wenn er es für sinnvoll hält.

Ziele der Sprint Planung

Zunächst ist das Planning ein Instrument, um die kommenden 1-4 Wochen (je nach Länge der Sprints) zu planen. Im Rahmen der Planungssitzung einigen sich Entwicklungsteam und Product Owner auf die zu erreichenden Ziele und die hierfür zu erledigenden Stories. Es ist entscheidend, dass eine Übereinkunft erzielt wird, dass die vereinbarten Ziele und Sprint-Elemente sinnvoll sind und umgesetzt werden können. Nur Planungssitzungen die mit einer Übereinkunft hinsichtlich Umfang, Zielsetzung und Sinnhaftigkeit enden sind zielführend. Plannings, die nur „pro forma“ durchgeführt werden und deren Ergebnisse im Sprint-Verlauf ignoriert werden (Priorität, „ach da kommt was Neues!“, „machen wir doch nicht“) sind nicht hilfreich sondern schädlich.

Probleme bei der Planung von Sprints

Typische Probleme von Product Ownern im Rahmen der (Sprint)Planung sind:

  • Die Planung wurde nicht vorbereitet, das Team sieht die Stories im Planning zum ersten Mal. Unsicherheit erhöht den geschätzten Aufwand. Im Planning die Unsicherheiten zu reduzieren kann zeitaufwändig und nervenaufreibend sein.
  • Trotz Vorbereitung durch Backlog Groomings und Weitergabe von Informationen an das Team kann es vorkommen, dass erst in der Planungssitzung oder erst im Planning 2 Abhängigkeiten aufgedeckt werden, die eine (wirtschaftlich) sinnvolle Planung des Sprints sehr schwer machen.
  • Aus Sicht des Product Owners wird zu viel Aufwand in Grundlage wie Infrastruktur und Entwicklungsumgebung investiert. Das Vorhaben erscheint nicht mehr wirtschaftlich umsetzbar. Der geschätzte Aufwand für die besprochenen Stories ist so hoch, dass eine wirtschaftliche Umsetzung zweifelhaft erscheint. Dies wird jedoch erst im laufenden Projekt erkannt.