Bas Vodde zu Large-Scale Scrum (und SAFe)

Die Konferenz Adventures with Agile (AWA) fand vor kurzem in London statt. Einige interessant Vorträge sind via YouTube zugänglich, u.a. ein Vortrag von Donald Reinertsen sowie ein Vortrag von Bas Vodde, einem der beiden Autoren von LeSS.

Bas Vodde geht in seinem Vortrag auf die Entstehung und Grundsätze des Large-Scale Scrum (LeSS) ein. Personen die sich mit der Skalierbarkeit agiler Ansätze beschäftigen bekommen hierbei interessante Einblicke, wie LeSS bei Nokia Networks sich langsam herausgebildet hat.

Interessant ist, welche Grundzüge von LeSS Bas betont:

  • Bei der Produktentwicklung stets den Kunden bzw. den Kundennutzen im Auge behalten (customer centric whole product focus) und eben nicht abstrakte Prozesse- oder Systemlandschaften mit deren „Ownern“ befriedigen.
  • Die Bedeutung von Feature-Teams. Ohne Feature-Teams ist LeSS nicht möglich, da nur mit Feature-Teams Abhängigkeiten aufgelöst bzw. drastisch reduziert werden können.
  • Die Unterscheidung zwischen „Multi-Team Scrum“ (LeSS) und „Multiple Scrum-Team“ Ansätzen und die unterschiedliche Sichtweise auf die Skalierung von Scrum Praktiken.
  • Verlagerung von Verantwortung (und Entscheidungsbefugnissen) in das Team bzw. in die Teams. Damit geht einher, dass koordinierende Rollen abgeschafft werden. Für Koordination, Abstimmung und Klärung sind die Teams alleinig verantwortlich.
  • Der grundlegende Überzeugung „Less is More„: Durch konsequente Eliminierung von Prozesselementen (Rollen, Artefakte, Prozess-Schritten) wird Raum geschaffen für echte, für mehr Verbesserungen. Dahinter steckt das Zusammenspiel von übertragener Verantwortung und geschaffenem Gestaltungsspielraum durch konsequente Reduzierung von Vorgaben.


Im zweiten Teil wird „dem Elefanten im Raum“, dem Scaled Agile Framework (SAFe) einiges an Zeit eingeräumt. Bas erklärt, weshalb er Ansätze wie SAFe für schädlich für eine echte Agilisierung von Unternehmen hält. Im besten Fall wäre SAFe ein „workaround in a context where the real (hard) questions are not answered“. Hierbei bezieht er sich u.a. auf die Etablierung von Featureteams, die sich im Großen und Ganzen selbst organisieren können (Verantwortung übernehmen, Gestaltungsspielraum erhalten), was letztendlich dem Aufbrechen aller existierender Strukturen entspricht.

Diese Einschätzung wurde vor mehr als einem Jahr aus meinem LeSS Kurs auch durch Craig Larman vermittelt. Viele LeSS Praktiken oder Ideen können zunächst in einem „mäßigen“ Umfeld erfolgreich eingeführt werden. Ähnlich wie einer Scrum-Einführung im Kleinen, stößt man aber schnell an die Grenzen, falls die Trägerorganisation an ihren existierenden Strukturen und Rahmenbedingungen festhalten will.

Ein Muster, das sich übrigens auch in Larman’s Laws of Organizational Behavior wieder findet:

Larman’s Laws of Organizational Behaviour

  1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
  2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
  3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, „religion“, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
  4. Culture follows structure.


becoming self employed – 12 questions that keep you from it and how I answered them

This week, after ten years of being an employee, I’ve started my new career as an independent agile coach and kanban trainer. While I feel way more motivated and super positive we all know our weaker self. These are the questions I had to answer “it”.
(It is known, that our weaker self starts questions with a BUT and oftentimes ends them with a ! instead of a ?)

But Markus, think about the safety you had with your previous employer!
A quote from “the matrix” comes to mind: „try to realize the truth! there is no spoon“ – the same is true for job security. In case of a consultancy, if you’re not „sold“ to a customer, there is a limited amount of undesirable jobs you can do – not more, and not less. You have to see the fact, that you are employed to create value for your employer. As soon as you’re not doing that, you’re out.

But Markus, you won’t get paid when you’re ill!
Let’s boil it down to money then.. how many days per year don’t you have a cold? The amount of money you make on these days hopefully far exceeded your sick leave.

But Markus, what if you get too many customers and just can’t handle all of them?
Well, the good thing in the agile (and most other) communities is, that you can always get help if you choose to ask for it. If indeed, you have too much on your plate, ask a fellow peer if she wants to help out or knows other coaches, facilitators or trainers that are looking for contracts at the moment.

You might even find the perfect fit for a customer you could only halfheartedly help.

But Markus, what if your customer doesn’t pay you?
Same thing as with every other aspects of your life. It is wise to have a legal costs insurance.

But Markus, nobody will pay for your education/trainings!
You are right, weaker self. There is no boss interested in my education.
And there shouldn’t be. Nobody should be more interested in my personal development than myself! It helps to set aside some (or a lot of) money to pay for the trainings I (or my fellow peers) deem useful for me.
A good friend of mine has set a minimum of 10.000eur/year for his own advancement. He knows that knowledge – and the application of it – distinguishes him from the competition.

I will set aside a similar sum per year for sharpening my mind. Maybe 10% of my income?

But Markus, you as a one man show don’t scale!
Indeed. If I wanted to „scale“, I would take a closer look at companies like crisp, oose, it-agile or kegon. These companies chose to reinvent themselves, thereby creating happier employees and also happier customers.

But Markus, what if your customers are abroad/want you to travel?
Then, my dear weaker self, it is totally up to me, if that customer fits into my current style of living.

But Markus, how can you survive in a market so full of amazing agile coaches?
Most colleagues of mine have their unique selling point. The same is true for me.
If you want to know more about it, just klick here.
For my german speaking readers: There is an amazing 3min youtube video called “Das Pinguin Prinzip”. Take a look if you understand some german.

But Markus, how can you possibly manage your time without a boss, a bonus or goals to drive you?
Weaker self, we both have read “Drive” by Daniel Pink. You should know how little I think of monetary bonuses or performance appraisals for skillful or creative work.

But Markus, are you not scared you won’t find a “real” Job, if you ever decided to go “corporate” again?
You are right, some companies don’t accept CV’s of candidates that have been self-employed. The question you should ask yourself is:

  • Why would an employer not want candidates with an entrepreneurial spirit?
  • Would you want to work for a company like that?

I will combine the next four questions…
But Markus, how will you acquire new clients if you’re working all the time?
But Markus, what if you can’t work with big firms for legal reasons? (payrolling)
But Markus, what about your retirement plans?
But Markus, won’t you hate doing tax reports and all the other back office stuff?
Now we’re looking at the „real“ problems, that need real solutions.
At the moment, I’m handling my customers through a supplier/provider.
What does that mean? I’m basically employed by them and get my hourly rates on the 10th of the next month with some percentage for back office, contract creation, retirement plans, taxes and so on.
I will invest more time at conferences, meetups and so on to reinvent myself as a „product“ and find new customers. Already some of my previous customers are helping me to spread the word, which I’m very thankful for.

But Markus, is it really worth the trouble?
I can only speak from the experience I got from the last three days.
So far my answer is: „Yes, yes, yes! I should have done it earlier.“

I’d love to hear read your comments on being self employed, or why you think it is a bad idea after all!

Large-Scale Scrum Site available

During a presentation @ QS-Tag 2014 in Nuremberg this November I summarized Large-Scale Scrum / LeSS like that:



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:

Ü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.


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.




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


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 ( beschrieben sind, selbst durchspielen möchte, sollte sich schnell zum Training anmelden:

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.