Impediment as cow on the track

Kurzmitteilung

Unterhaltsame Session von Sarah Scott (Northwestern Mutual) auf dem diesjährigen SAFe Summit in dem sie ihre SAFe Implementierung vorstellt.

Besonders die Visualisierung von Impediments in Form von Kühen hat zum Schmunzeln angeregt, obwohl dahinter eine richtige Geschichte steckt:

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

Und dazu passend das „Cow Board“ mit dem visualisiert wird wie der Status der verschiedenen Agile Release Trains (ART) ist:

  • Ready for SAFe
  • Vorbereitung
  • erstes PI Planning
  • Weitere Betreuung / Professionalisierung
  • weitere PIPs
  • Reduktion des Coachings..

 

SAFe Cow Board
SAFe Cow Board

Natürlich inklusive Cow Impediments :-)

 

 

Eine Einführung in das Scaled Agile Framework (SAFe) und das Problem dabei genügend Luft zu bekommen…

Beginnt man sich mit dem Scaled Agile Framework (SAFe) zu beschäftigen und sucht eine Kurzeinführung SAFe, dann fällt der Blick zuerst auf das sogenannte „Big Picture“ welches die Startseite von http://www.scaledagileframework.com dominiert.

Hat man bisher bereits Erfahrungen mit agilen Teams gesammelt und ist stets dem Agilen Prinzip

Simplicity–the art of maximizing the amount of work not done–is essential. (http://agilemanifesto.org/principles.html)

gefolgt, dann kommt es häufig zu einer Gegenreaktion im Sinne von „DAS kann doch nicht agil sein!“.

Es gibt nun diverse kurze Einführungen in SAFe die hauptsächliche auf die Elemente, Struktur und Abläufe fokussieren, wie sie im Big Picture abgebildet sind.Sehr schön ist beispielsweise das SAFe 4-0 in 5 Minuten Video von Inbar Oren:

Diese Darstellungen sind sehr nützlich, um einige wichtige Praktiken und Mechanismen zu verstehen. SAFe alleine auf die konkreten Praktiken zu reduzieren ist allerdings weniger hilfreich, weil diese recht konkret sind und sicherlich nicht in jedem Kontext passend.

Mein Ansatz in Trainings zum Scaled Agile Framework ist deshalb, relativ viel Zeit mit Themen wie

zu verbringen. Gerne wedel ich dabei auch mit den Büchern von Donald Reinertsen (Flow) und Kotter (Change Management) herum.

Dies sind Grundlagen, die sicherlich nicht direkt die konkreten und aktuellen Probleme der Teilnehmer adressieren. Sie müssen jedoch verstanden sein, damit SAFe im eigenen Kontext richtig interpretiert und adaptiert werden kann.

Vor ein paar Tagen durfte ich nun sehr kurzfristig für meinen Kollegen Thorsten Janning, dem ersten deutschen SPCT, kurzfristig einspringen, um eine Kurzeinführung SAFe beim Agile Roundtable Rhein-Main zu geben.

Was tun, wenn keine Zeit für eine intensive Vorbereitung da ist? Klar, man nimmt sich eine der Standardpräsentationen und eine gehörige Portion Improvisation dazu. Meine Wahl fiel auf die „SAFe in 8 Pictures“ Präsentation, wie sie über die ScaledAgileFramework.com Seite verfügbar ist (http://www.scaledagileframework.com/videos-and-presentations/).

safe8picturestalk1

 

Schön, ich habe ca. 45 Minuten Zeit und kann einen komprimierten Überblick über SAFe geben. Da Prinzipien, Werte und das House of Lean nicht Teil dieser Präsentation ist, kommen diese Dinge auf ein Flip und ich erkläre (leider nur) kurz etwas dazu.

safe8picturestalk2

Es gab nur einen kleinen Schönheitsfehler bei diesem Plan – statt der erhofften 45 Minuten gabs für alles zusammen nur einen Slot von 20 Minuten.

Sehr schön, vor allem wenn man bedenkt, dass ein beliebtes Feedback für die zweitägigen Trainings ist, dass diese mindestens drei Tage lang dauern sollten :-)

Egal, nicht erschrecken lassen sondern Gas geben und noch ein bisschen Humor einstreuen, u.a. die Frage wer denn diesen Satz lesen kann:

safe8picturestalk3

Eine kurze Summar im Sinne von „Hey, da gibts auch noch etwas reduziertes“ mit dem Hinweis auf das Essential SAFe gabs am Schluss auch noch …

Für mich waren die 20 Minuten (die ich recht gut einhalten konnte) ein spannender, schneller Sprint mit der zentralen Frage: „Hole ich Luft oder geht noch ein weiterer Satz?“. Die Antwort war zumindest zwei mal ein lautes Luftholen :-). Na, da steckt doch noch ein bisschen Energie in den alten Knochen …

Da ich früher gehen musste, konnte ich die versprochenen Zertifikate „I survived the SAFe speed run“ doch nicht an die Teilnehmer verteilen – vielleicht das nächste Mal :-).

 

Jeff und Ken über den neuen Scrum Guide 2016

Nach mehreren Jahren wurde der offizielle Scrum Guide aktualisiert. Die aktuelle Fassung ist hier verfügbar:

Eine wichtige Änderung im Scrum Guide 2016 sind die explizit aufgeführten Scrum Values:

  • Courage
  • Focus
  • Commitment
  • Respect
  • Openess

Die Bedeutung dieser Werte wurde/wird systematisch unterschätzt (vgl. auch Gründungstreffen der Scrum User Group Karlsruhe, 2009). Die Werte sind Teil einer Kultur, die viele kritische Aspekte von Scrum kompensiert.

Ein Beispiel hierfür ist, dass in vielen Scrum Teams sehr respektlos über nicht agilen Unternehmensteile geredet wird, obwohl diese häufig mittelfristig die tragenden Säulen der sich ändernden Organisation sind und viele gute Mitarbeiter dort ihr Bestes tun, damit die Organisation erfolgreich ist. Hier ist ein respektvoller Umgang miteinander Grundlage, um gemeinsam zu lernen und gemeinsam die Organisation weiter zu verbessern.

Wie Ken es schön zusammenfasst: Lebt man diese Werte, dann ist Scrum „ein Ort an dem Du leben möchtest“, ohne diese Werte sei Scrum „ein Ort, an dem Du nicht unbedingt sein möchtest“.

Spannend ist die Diskussion rund um den Wert „Commitment“. Ein Scrum Team „versucht nicht sein Bestes“ sondern es commitet sich auf die Dinge die im Sprint Planning als Ziel besprochen werden. Wichtig ist jedoch auch das Commitment über den Sprint hinaus – eine Verpflichtung auf die Organisation und die Zielsetzung des Vorhabens als solches. Hierzu gibt/gab es in der Vergangenheit immer wieder auch Verwirrungen.

Ein weiterer Punkt der neu aufgenommen wurde ist, dass Sprint Ziele nun Teil des Scrum Guides sind. Die bisher empfohlene Praxis ist damit zu einem „Muss“ geworden.

Das Video in dem Jeff und Ken über den neuen Scrum Guide bzw. vor allem über die Scrum Values sprechen ist bei vimeo zu finden:

Scrum Guide Refresh (July 2016) from Scrum Inc. on Vimeo.

Weiteres Video zur SAFe Implementierung bei LEGO

In dem Video „Is SAFe Evil?“ (letzter Beitrag) wurde bereits darauf eingegangen, wie das Scaled Agile Framework als Startpunkt für die „Scaled Agile Implementierung“ bei LEGO® genutzt wurde.

Auf der Lean Kanban Europe 2015 gab es nun einen weiteren Vortrag hierzu.

Das Video ist via vimeo verfügbar:

Learnings from SAFe @ Lego – Mattias Skarin & Eik Thyrsted Brandsgård at LKCE15 from Lean Kanban Central Europe on Vimeo.

Wichtige Punkte:

  • Impressionen zum Release Planning Event (16:00) – hier kann man richtig Spaß haben!
  • Was machen wir eigentlich mit SAFe? Das gleiche wie im Kindergarten (17:50) :-)
  • Schöne Visualisierungen, welche Prinzipien hinter SAFe stecken. Es ist eben nicht das „Big Picture“ sondern diese Prinzipien, die die Basis für eine Scaled Agile Implementierung sind.
  • Generell „play it unsafe“ – bewusst Dinge anders tun als in SAFe beschrieben. Hier heißt es keine Angst vor Experimenten! Sich dumpf an die Vorgaben zu halten ist langfristig nicht sinnvoll (als Startpunkt aber ok).
  • Algorithmus, um zu entscheiden was beibehalten und was wegfallen sollte:
    • die Elemente die Energie erzeugen – behalten
    • die Elemente die dazu führen, dass alle einschlafen – entfernen

Das Video enthält viele Ideen, wie das SAFe Release Planning Event adaptiert werden kann. Die eine oder andere Idee eignet sich dafür, sie direkt in der eigenen Scaled Agile Implementierung auszuprobieren.

Die Slides zu dem Vortrag sind via einem Blog Artikel bei Crisp verfügbar.

Ich halte die Impressionen von der SAFe Implementierung bei LEGO für sehr erfrischend. Hier in Deutschland neigen wir – gerade bei großen Organisationen – dazu, uns zu ernst zu nehmen und in Details zu verlieren. Es geht nicht darum, stumpf Backlogs abzuarbeiten, sondern wir sollten auch gemeinsam Spaß haben und eine Vision teilen.

Zudem ist es wichtig zu verstehen, dass SAFe lediglich der Startpunkt für die eigene Scaled Agile Implementierung („Land of Awesome“) ist. Dies versuche ich bei meinen „SAFe“ Implementierungsprojekten stets zu vermitteln. Je größer die Unternehmen, umso weiter jedoch der Weg zur Erkenntnis, dass sich Innovationen nicht standardisieren lassen.

 

 

Is SAFe evil? The answer …

Is SAFe evil?

Die Frage, ob das Scaled Agile Framework ein nützliches oder eher schädliches Hilfsmittel für die Skalierung von Agilität im Unternehmenskontext darstellt spaltet die agile Community seit mehreren Jahren.

Sehr erfrischend ist ein neues Video in dem die aktuellen Ansätze für die Skalierung von Agilität bei LEGO erläutert werden. Sehr schön auch der Einstieg, d.h. die „erste Präsentation“ ;-).

 

Henrik Kniberg erklärt die wichtigsten Konzepte aus SAFe

  • „SAFe = Shu-level scaling“, danach anpassen
  • momentan wird (bei LEGO) nach SAFe gearbeitet, in einem Jahr wird dies wohl anders aussehen. Mit dem SAFe Framework hat die Reise lediglich begonnen.

Lars Roost erklärt, wie diese bei LEGO eingesetzt werden – schöne Impressionen

  • Release Planning @ LEGO

Grundlegendes

  • Wichtige ist eine Grundhaltung: Es gibt viele Quellen der Inspiration: Nutze sie alle: NEXUS, LeSS, SAFe, DAD und viele, viele weitere …
  • Auch ohne SAFe muss man sich immer um die Portfolio- und die Team-Ebene kümmern.
  • Mehrwert im SAFe vor allem der „SAFe Program Level“, da dadurch Portfolio-Management und die agile Teams verunden werden. Hierbei spielt der Release Train Engineer („Chief Scrum Master“) eine sehr wichtige Rolle.
  • Gestaltet man diese teamübegreifende Ebene gut, dann wird die Vorhersehbarkeit verbessert (Mittelfristplanung).
  • SAFe macht wie Scrum bestimmte Probleme sichtbarer, was nicht bedeutet, dass diese automatisch gelöst werden.

Scaled Agile Framework- Chancen und Risiken 

  • LIKE
    • Einiges rund um das Release Planning: Die Energie, Release Planning als Social Event, Visualisierung (Transparenz!) über das Dependency Board und das Risk Board
  • BEWARE
    • SAFe – nicht alles auf einmal!
    • Nicht auf dem Shu-Level bleiben sondern Strukturen und Regeln anpassen
    • Queues & Batches – aufpassen, dass die Arbeit fließt und nicht gewartet wird
    • Mount Stupid – Hype & Anti-Hype
  • Warpup
    • SAFe als Hilfsmittel
    • SAFe basiert auf Lean & Agile Prinzipien
    • SAFe = Shu-level Skalierung
    • SAFe can be useful, wenn Teams voneinander abhängig sind
    • Nicht auf Shu-Level bleiben – viel experimentieren

 

Interessantes am Rande: Noch Ende 2014 war man bei CRISP viel kritischer eingestellt. So ändern sich die Zeiten bzw. die Einstellung, wenn man sich intensiv mit einem Thema beschäftigt.

Die Slides sind via einem Blog-Artikel bei Crisp abrufbar.

 

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.

http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

 

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:

less-summary

 

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.