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 :-).

 

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

Kurzmitteilung

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

Is SAFe unSAFe – My Thoughts

Thoughts on how the Scaled Agile Framework is perceived by some agilists

At the moment the Scaled Agile Framework is getting a lot of attention as it provides answers to challenges common for large scale agile initiatives / large agile programs. SAFe being an agile/lean framework is also part of the Agile 2013 conference, something Ken Schwaber doesn’t seem to like:

Beside this tweet Ken also wrote a small article where he explains (his impression) that SAFe might be more dangerous as helpful as it has it’s root in RUP and Processes & Tools are overemphasized in comparison to People & Interactions:

Ken Schwaber’s Blog: Telling Like It Is – unSAFe at any speed.

While the article itself lacks some substance (you just notice how uncomfortable Ken is with SAFe) the comments are very interesting as real practitioners share thoughts and their experience with SAFe (good ones, bad ones).

*Updated*

A far more detailed article has been written by David Anderson (Mr. Software Kanban) in which he also expresses his concerns regarding SAFe. He wrote his article „Kanban – the anti-SAFe for almost a decade already“ about SAFe but also acknowledged that he just did some brief research and has no real experience with it:

To be honest, I don’t know a great deal about SAFe.

Still his summary is:

It is fair to say that this approach is the antithesis of the Kanban Method!

and also adds

I’m not impressed with the Kanban related material or its suggested usage in SAFe.

From his point of view

SAFe appears to collect together a number of techniques from software development processes from the 1990s and 2000s. It offers these as one large framework.

With that he seems to underestimate how many feedback cycles (learning & improving) during the last years finally resulted in what is now known as SAFe and he completely misses (from my perspective) the embedded Lean Product Development Principles (Donald Reinertsen) and the Lean Leadership foundation (part of the SAFe Lean Thinking House).

As you might have noticed I do not share the opinions of Ken Schwaber or David Anderson but I am happy to see that these two thought leaders finally found something they can agree on.

What are my thoughts on the Scaled Agile Framework?

SAFe is prescriptive – but it is just the start of your journey

From my own experience the implementation of SAFe is a quite challenging undertaking as SAFe seems to be a quite prescriptive framework with a lot of guidance and governance („Processes & Tools“) but still you have to have a deep understanding of the agile / lean foundations to implement (tailor, adapt) it in an organization specific way („People & Interactions“). I personally feel it is worth the effort because SAFe provides a proven framework with values, principles and best practices that address the common challenges you have to overcome when scaling agile and especially when scaling agile in a non green field environment. Having said that I believe it is key that you teach/establish real agile/lean thinking and learning cycles so the organization can further adapt and improve  („Kaizen“). Only with these Inspect & Adapt cycles „SAFe“ is going to work for your organization on the long run.

There are a lot more topics to discuss and to improve over time (your „SAFe Path“):
maus-lesend

  • how to find / optimize your agile release trains
  • how to do the portfolio planning in your context
  • how to optimize the demand management
  • how to prioritize in a scaled environment
  • what to do with the HIP sprint
  • when and how to release to production (the shorter the cycles the better)
  • how to facilitate & organize the inspect & adapt workshop for optimal group feedback
  • decide on which KPIs are really important for your company

Failing to see that this is the journey your organization needs to undertake will leave you stuck in the predefined default practices / processes / tool that you can find on the SAFe website. Keep in mind: Real agile-lean companies are always learning, adapting and improving.

Resistance as it is not Agile?

In companies that have existing Scrum teams I usually experience some resistance of agile practitioners as the team level loses some freedom of choice. Have a look at the role of the SAFe Product Owner for example, the need to have cadence AND synchronization or the need to commit to several sprint during the release planning event (sounds weird for most agile people who did not experience such an event before).

Global optimization required

Very often these people need to be trained to see the value of overall alignment and enterprise wide transparency (see SAFe Cove values). Single teams excelling in their own context _may_ sum up to a lot of local optima but (at the same time) may not be useful to reach a global (organization) optimization. Not understanding this is like not understanding how your company is creating value.

Role of Scrum in SAFe

Important to note is also that SAFe is not against Scrum but uses the principles of Scrum as a team process (perfect match for most teams in a SAFe environment) and Scrum as thinking model (guiding you how to organize and optimize your organization). However one could argue that it is not „Scrum.org Scrum“ as there are some adjustments made (as with most Scrum implementations „in the wild“) but still it shares the same spirit and goals, taking inspiration also from Donald Reinertsen’s Product Development Principles not only for developing products but also for improving the own processes.

What does really matter? It’s you!

While SAFe is about alignment, transparency, program execution and (code) quality it’s about how YOU are going to implement the ideas, principles and practices in YOUR environment. In the end it’s the implementation that matters: It’s you, your colleagues, your shared goals/values and the business value you produce.

Thoughts on how the Scaled Agile Framework is perceived by some agilists

At the moment the Scaled Agile Framework is getting a lot of attention as it provides answers to challenges common for large scale agile initiatives / large agile programs. SAFe being an agile/lean framework is also part of the Agile 2013 conference, something Ken Schwaber doesn’t seem to like:

Beside this tweet Ken also wrote a small article where he explains (his impression) that SAFe might be more dangerous as helpful as it has it’s root in RUP and Processes & Tools are overemphasized in comparison to People & Interactions:

Ken Schwaber’s Blog: Telling Like It Is – unSAFe at any speed.

While the article itself lacks some substance (you just notice how uncomfortable Ken is with SAFe) the comments are very interesting as real practitioners share thoughts and their experience with SAFe (good ones, bad ones).

*Updated*

A far more detailed article has been written by David Anderson (Mr. Software Kanban) in which he also expresses his concerns regarding SAFe. He wrote his article „Kanban – the anti-SAFe for almost a decade already“ about SAFe but also acknowledged that he just did some brief research and has no real experience with it:

To be honest, I don’t know a great deal about SAFe.

Still his summary is:

It is fair to say that this approach is the antithesis of the Kanban Method!

and also adds

I’m not impressed with the Kanban related material or its suggested usage in SAFe.

From his point of view

SAFe appears to collect together a number of techniques from software development processes from the 1990s and 2000s. It offers these as one large framework.

With that he seems to underestimate how many feedback cycles (learning & improving) during the last years finally resulted in what is now known as SAFe and he completely misses (from my perspective) the embedded Lean Product Development Principles (Donald Reinertsen) and the Lean Leadership foundation (part of the SAFe Lean Thinking House).

As you might have noticed I do not share the opinions of Ken Schwaber or David Anderson but I am happy to see that these two thought leaders finally found something they can agree on.

What are my thoughts on the Scaled Agile Framework?

SAFe is prescriptive – but it is just the start of your journey

From my own experience the implementation of SAFe is a quite challenging undertaking as SAFe seems to be a quite prescriptive framework with a lot of guidance and governance („Processes & Tools“) but still you have to have a deep understanding of the agile / lean foundations to implement (tailor, adapt) it in an organization specific way („People & Interactions“). I personally feel it is worth the effort because SAFe provides a proven framework with values, principles and best practices that address the common challenges you have to overcome when scaling agile and especially when scaling agile in a non green field environment. Having said that I believe it is key that you teach/establish real agile/lean thinking and learning cycles so the organization can further adapt and improve  („Kaizen“). Only with these Inspect & Adapt cycles „SAFe“ is going to work for your organization on the long run.

There are a lot more topics to discuss and to improve over time (your „SAFe Path“):
maus-lesend

  • how to find / optimize your agile release trains
  • how to do the portfolio planning in your context
  • how to optimize the demand management
  • how to prioritize in a scaled environment
  • what to do with the HIP sprint
  • when and how to release to production (the shorter the cycles the better)
  • how to facilitate & organize the inspect & adapt workshop for optimal group feedback
  • decide on which KPIs are really important for your company

Failing to see that this is the journey your organization needs to undertake will leave you stuck in the predefined default practices / processes / tool that you can find on the SAFe website. Keep in mind: Real agile-lean companies are always learning, adapting and improving.

Resistance as it is not Agile?

In companies that have existing Scrum teams I usually experience some resistance of agile practitioners as the team level loses some freedom of choice. Have a look at the role of the SAFe Product Owner for example, the need to have cadence AND synchronization or the need to commit to several sprint during the release planning event (sounds weird for most agile people who did not experience such an event before).

Global optimization required

Very often these people need to be trained to see the value of overall alignment and enterprise wide transparency (see SAFe Cove values). Single teams excelling in their own context _may_ sum up to a lot of local optima but (at the same time) may not be useful to reach a global (organization) optimization. Not understanding this is like not understanding how your company is creating value.

Role of Scrum in SAFe

Important to note is also that SAFe is not against Scrum but uses the principles of Scrum as a team process (perfect match for most teams in a SAFe environment) and Scrum as thinking model (guiding you how to organize and optimize your organization). However one could argue that it is not „Scrum.org Scrum“ as there are some adjustments made (as with most Scrum implementations „in the wild“) but still it shares the same spirit and goals, taking inspiration also from Donald Reinertsen’s Product Development Principles not only for developing products but also for improving the own processes.

What does really matter? It’s you!

While SAFe is about alignment, transparency, program execution and (code) quality it’s about how YOU are going to implement the ideas, principles and practices in YOUR environment. In the end it’s the implementation that matters: It’s you, your colleagues, your shared goals/values and the business value you produce.

Vorstellung SAFe bei der AgileRM – Zusammenfassung und Folien

Vorstellung des Scaled Agile Frameworks beim Treffen der Agile User Group Rhein Main

Am 20. Juni hatte ich Gelegenheit im Rahmen eines Treffens der Agile User Group Rhein Main (#agileRM) eine Einführung in das Scaled Agile Framework (SAFe) zu geben.

Herzlichen Dank für die Fotos an Tobias Cieplik.

scaled_agile-06516
SAFe Big Picture

Die Räumlichkeiten für das Treffen stellte die Seibert Media GmbH in Wiesbaden zur Verfügung. An dieser Stelle einen herzlichen Dank an alle Organisatoren!

Trank und Speis wurde durch Atlassian (Jira, Confluence) gesponsort. Es gab auch genug Bier, um so auch die kritischen Geister etwas zu beruhigen ;-).

Jeder der sich mit bereits intensiver mit der Skalierung von agilen Konzepten und dem Scaled Agile Framework im Besonderen beschäftigt hat, weiß um die Schwierigkeiten eine kurze und in sich stimmige Einführung in das Thema zu geben.

scaled_agile-06501
Teams in SAFe

Für alle Interessenten hier die Folien: 20130619_AgileRM_SAFe_presentation

Der Teilnehmerkreis bestand aus mehr als 20 Interessenten, teilweise erfahrene Agile Consultants / Coaches mit umfangreicher Erfahrung. Dies spiegelte sich auch in den hochwertigen Fragen und der Diskussionsqualität wieder.

scaled_agile-06448
Erläuterung der Rollen Produktmanagement, Product Owner und Entwicklungsteam

Weitere Informationen

Die deutschsprachige Community „SAFeDACH“ (#safede, #safedach) organisiert sich via Xing und Google+.

An dieser Stelle sei auch der sehr gelungene Vergleich von Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) und Path to Agility (P2A) erwähnt, die Lutz Ehrlich (EnBW) in einer Präsentation auf dem Karlsruher Entwicklertag vorgestellt hat.