Webinar: Vorstellung SAFe Big Picture 3.0

Die Version 3.0 des Scaled Agile Framework Big Picture wird Ende Juli auf der Agile 2014 in Orlando vorgestellt und enthält einige wichtige Neuerungen. In einem 30 minütigen Webinar werden diese Neuerungen und Änderungen vorgestellt und danach diskutiert.

Struktur des Webinars:

  • Entwicklung des Big Pictures seit 2009
  • Strukturelle Änderungen des Big Pictures
  • Änderungen auf der Portfolio-Ebene
  • Änderungen auf der Programm-Ebene
  • Änderungen auf der Team-Ebene
  • Änderungen “hinter” dem Big Picture
  • Reflektionen und Anmerkungen
  • Fragerunde / Diskussion

Anmeldung zum Webinar via XING: https://www.xing.com/events/webinar-safe-big-picture-3-0-1423952.

Über SAFe und KEGON

Das Scaled Agile Framework (SAFe) ist ein Framework für Skalierung von Agilität in Unternehmen. Die KEGON AG ist ein offizieller Scaled Agile Partner mit mehreren erfahrenen SAFe Program Consultants (SPCs) und setzt SAFe neben anderen Skalierungsstrategien erfolgreich bei Kunden ein.

 

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

 

 

Nächster Termin der Agile User Group Rhein Main: Die Agile Organisation – Irritationen statt Trivialisierungen

Aside

Am 10. April trifft sich die Agile RM in Wiesbaden bei der KEGON AG. Dort wird Hans-Peter Korn einen Impulsvortrag zum Thema “Die Agile Organisation – Irritationen statt Trivialisierungen” geben.

Dieser Impulsvortrag bietet einen Kontrapunkt zu den derzeit oft allzu trivialisierenden Aussagen im “agilen Dunstkreis” und dem Trend, alles allzu vereinfachend und möglichst kurz darzustellen. Statt dessen soll hier ein Impuls gesetzt werden, sich demnächst mal rund fünf Stunden Zeit zu nehmen um in essentielle Themen einzutauchen statt unverbindlich an der Oberfläche diverser Modebegriffe “Herumzuzappen”.

Hans-Peter Korn ist nicht dafür bekannt in seichten Gewässern zu segeln; intensive Diskussionen können erwartet werden! Anmeldung via XING.

Innovation Games Training

In dem Interview von Jürgen Dittmar war ich voll des Lobes für sein Management 3.0 Training.

Heute möchte ich eine weitere Empfehlung für einen sehr interessanten Termin aussprechen. Die Kollegen von Scrum Events (bekannt durch die Organisation des jährlich statt findenden Scrum Days in Deutschland) haben ein Innovation Games Training am 13. und 14. Februar in Stuttgart organisiert.

Vielleicht kennen Sie die Spiele schon aus den Büchern von Luke Hohmann (Innovation Games) oder Dave Gray, Sunni Brown und James Macanufo (Gamestorming). Bei diesen Spielen handelt es sich eigentlich um Übungen, die man gut in einer Gruppe spielen kann. Während Gamestorming eine größere Sammlung von Übungen für verschiedene Anlässe ist, geht es bei den Innovation Games speziell um Kundenwünsche.

Welche Übungen kann ich mit meinen Kunden machen, um mehr über deren Anforderungen an meine Produkte zu erfahren? Product Box ist zum Beispiel eine Übung, bei der ein Team eine Schachtel so gestaltet, dass sie die Vorzüge eines neuen Produkts gut darstellt. Einerseits ist es eine schöne Alternative zum Schreiben von Market Requirements Dokumenten, weil es mehr Sinne anspricht. Andererseits ist die Übung auch lebendiger, weil jedes Team ein paar Minuten Zeit bekommt, um seine Schachtel den anderen Team werbend vorzustellen.

Wer die Innovation Games, die übrigens alle auf der Webseite (http://innovationgames.com/resources/the-games/) beschrieben sind, selbst durchspielen möchte, sollte sich schnell zum Training anmelden:http://www.scrum-events.de/zertifizierungen/certifiedinnovationgamestraining/.

PMCamp Rhein-Main 2014

Die Idee für ein PMCamp in der Nähe von Frankfurt wurde auf dem PMCamp 2012 in Dornbirn geboren. Sommer 2013 fand das erste #PMCampRM in Bad Homburg statt und war ein großer Erfolg.

Das PMCamp Rhein-Main 2014 wird vom 27. bis 28. Juni erneut in Bad Homburg stattfinden. Mehr Informationen auf der Homepage.

https://twitter.com/AgileRescue/status/422351509125607424

Management 3.0 Trainer Jürgen Dittmar im Interview

Mit Management 3.0 hat Jurgen Appelo 2011 ein Buch publiziert, welches die wichtigsten Ideen eines modernen Führungsverständnisses gebündelt darstellt. Mittlerweile gibt es neben Jurgen weltweit eine ganze Reihe offizieller Management 3.0 Trainer, die dieses Seminar anbieten.

Einer dieser Trainer ist Jürgen Dittmar, der mich im September 2013 in seinem Management 3.0 Seminar begeistert hat. Jürgen ist bekannt für die Übersetzung der Kursunterlagen ins Deutsche und sicherlich einer der etabliertesten Management 3.0 Trainer im deutschsprachigen Raum.

An diese Stelle der Hinweis auf sein nächstes Seminar am 20. Januar in Frankfurt: http://www.scrum-events.de/zertifizierungen/management30/index.html. Ich selbst habe damals die Teilnahme sehr genossen und obwohl ich das Buch schon kannte eine ganze Menge Inspiration und Ideen mitnehmen können.

Jürgen Dittmar und das Management 3.0 Model
Jürgen Dittmar und das Martie, das Management 3.0 Model

So, jetzt ein paar Fragen an Jürgen.

Kannst Du Dich kurz vorstellen? Was beschäftigt Dich?

Vorstellen? O.k. hier ein paar Daten: Ich bin inzwischen 50 Jahre, verheiratet, 3 Töchter, 4 Enkelkinder und wohne in München. Ich habe Geographie, Politikwissenschaft und Arbeits- und Organisationspsychologie studiert und bin als freiberuflicher Unternehmensberater für Organisations- und Managemententwicklung insbesondere in agilen Transformationsprozessen tätig.

Dabei verstehe ich mich eigentlich als Entwicklungshelfer. Entwickeln dabei in zweierlei Hinsicht: Ich entwickle und entfessle Menschen und Organisationen. Und da sehe ich viele Fesseln, die sich Unternehmen und Menschen selbst auferlegen und nicht mehr hinterfragen.

Und was mich so beschäftigt?

Wenn ich so zurückblicke ist das bestimmende Thema in meinem Berufsleben schon immer das Thema Systeme oder “komplexe Systeme”. Zunächst als Diplom Geograph waren es die Ökosysteme in der Umweltanalyse und -planung, dann komplexe IT Systeme in meiner Zeit als Entwickler und Projektleiter und spätestens seit 12 Jahren – als ich Führungskraft und Manager wurde – das Thema Mensch und die komplexen soziale Systeme in (IT-)Organisationen und Projekten. Und das ist das was mich aktuell treibt: wie kann man wirklich Organisationen schaffen, in denen Menschen extrem motiviert, kooperativ und produktiv zusammenarbeiten. Mit Agile und Scrum als Erfolgsmodell und Basis stehen wir aus meiner Sicht da aktuell an einer Zeitenwende was das betrifft.

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 ;-)

ScrumMasters – The Good, the Bad and the UglyScrumMasters – The Good, the Bad and the Ugly

Video

Ende Oktober hatte ich die Freude beim Google Developer Fest zu sprechen. Da die meisten Teilnehmer Entwickler sind, hatte ich meine Session speziell für Teams entworfen: “ScrumMasters – The Good, the Bad and the Ugly”

https://www.youtube.com/watch?v=f_3q1m6pJ_8I had the pleasure to speak at the Google Developer Fest in late october. As most participants were developers – I wrote a session just for them: “ScrumMasters – The Good, the Bad and the Ugly”

Alistair Cockburn über Use Cases vs User Stories

Aside


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.