Archiv der Kategorie: Planning

Looking back: Reasons for adopting the Scaled Agile Framework

In the year 2002, I started to study and apply agile thinking tools, principles, methods, and practices while working as software developer. First steps were injecting agile ideas into a small team and influence the project organization to see the benefits of implementing some aspects/ideas of Scrum and using some elements of XP to improve the engineering process and the quality of the products we were developing.

At that time I was working in Karlsruhe which is known to be one the regions where Scrum and XP have its roots in Germany. In Karlsruhe I was able to benefit from the first agile initiatives in Germany with several Scrum Trainers, Scrum Consultants, and XP experts living there and inspiring more and more companies.

With other early adopters of agile ideas, we founded „KAgile“ (Methods of agile software development Karlsruhe) in 2002. This group stopped existing after 2 years but later has found a successor in the Scrum User Group Karlsruhe which is still active today.

In 2006 I joined a medium sized company that decided to use agile concepts in the product development. At that time I was quite fluent in Scrum on the team level but still missing an official certification.

In the subsequent years I have been working occasionally as Scrum Master but soon the shift was towards being a Product Owner for developing custom solutions based on a common platform but driven by customer projects. In that role, I was sort of PO towards the team and sort of project manager towards the customer in the sense that we had limited time and resources to deliver expected outcomes. Often we had requirement specifications which we were able to „agilize“ in the sense of shifting the discussion to focus on intended outcomes instead of deliverables.

During that time the company was adopting Scrum to develop their products. This was great for the teams focusing on core product development but as we were missing any portfolio management and cross-team planning we run constantly into bottlenecks and had meetings with VP level executives for hours – every sprint.

The organization refused to plan ahead, to create a shared roadmap including critical deliveries from the project perspective backed up by teams included in the planning process. The Product Management, being part of the development group was responsible to plan the features in their products (platform) but did not take into account the needs of the projects. Following the Scrum mantra, they were pushing all responsibilities to the Project Managers – which had no power to decide anything but were the messengers that usually were slaughtered by the customer for bringing the news of additional delays and missing functionality.

During my days in that company, I saw how well paid Scrum Coaches came in and tried to implement a „Scrum by the Book“ approach without grasping the very essence of it – looking at the whole value chain not just a few (development) Scrum teams! While this approach had some positive results on the team level everything outside the development teams was in deep trouble as the „balance of power“ between roles that had a more customer-centric view and roles that had a more team-centric view was destroyed.

Looking back this sounds quite strange as the agile mindset aims to improve the relationship between customer and team instead of destroying it. Unfortunately, I saw this pattern several times in other organizations as well – agile teams losing contact with the real customer as Scrum Masters and Agile Coaches tried to „protect“ them but actually doing some local optimization.

Clearly, this setup was not working at all: Either you completely stop working on customer projects as they might inject „chaos“ into your product development organization and focus on product development only – or you had to improve customer-Dev relationship which also means to rethink the project manager role and include the project manager people in a more productive manner in the agile planning process. Additionally, it became clear that the planning process must be improved to look ahead more than one Sprint so that we all have the chance to figure out what is really valuable for the enterprise.

At this time (probably 2008/2009) I run into concepts of scaling Agile and soon I came across the work of Craig Larman/Bas Vodde as well as Dean Leffingwell.

The books written by Craig & Bas caught my attention as they are breathing an agile mindset and their idea of running experiments instead of proposing „best practices“ was resonating deeply for me. The same is true for their fantastic Large-Scale Scrum (LeSS) framework which describes some great ideas and concepts.

The books written by Dean helped me to navigate through the challenges when scaling agile development. While his early writings might not have been completely agile-minded and he was not challenging/rethinking everything from scratch it was unbelievable useful as it provided a much better overview, map or Big Picture for me at this time.

In 2012 Dean made it to the Scrum-Day conference and presented his Scaled Agile Framework in Germany for the first time. I joined his workshop and three months later the first SAFe Program Consulting training in London becoming one/the first SPCs in Germany.

Starting from that time on I was referring to the work of Dean in a way that the Scaled Agile Framework provides a great map for orientation, highlighting a lot of topics/challenges that you need to work on during an Lean-Agile transition. You then might adopt the patterns as described in the standard framework or you might need to rethink them so that they better fit your context but you will always have a handy map for orienting.

To do that successfully you need to understand the value, mindset, and principles. Unfortunately, this is something which is often skipped in many Agile, Scrum and Scaled Agile implementations. I usually try to emphasize the importance in trainings I give but often the ask is to spend more time on the practices described in the Scaled Agile Framework – and that’s probably one of the largest risks applying SAFe in your organization: Cargo Cult.

So one of the main challenges you face as coach for Lean-Agile transitions – regardless of being Scrum-based or SAFe-style – is to look out for cargo cults and try to emphasize the importance of Lean-Agile principles and values.

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.

 

 

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.

Scaling Agile & Lean – Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe)

Das Scaled Agile Framework (Abkürzung: SAFe) ist ein umfangreiches, deskriptives Framework, um Agile/Lean auf der Team-, Programm- und Portfolio-Ebene zu ermöglichen und für große Organisationen handhabbar zu machen. Hierzu beschreibt es Strukturen, Rollen, Prozesse und Artefakte die relevant sind für ein agiles/lean Programm- und Portfoliomanagment. Eine komplette interaktive Beschreibung von SAFe befindet sich auf der Webseiten des Frameworks:  http://scaledagileframework.com/.

Adressierte Problemfelder

Mit SAFe werden vielfältige Herausforderungen adressiert, die für große Vorhaben und Organisationen nicht unüblich sind. Hierzu gehören:

  • Entropie / Varianz und lokaler Optimierung: Agilität auf der Team-Ebene mit sich selbst organisierenden Teams und nicht koordinierten Product Ownern führt zu einer hohen Entropie / Varianz. Kurz: Es kommt zu lokaler Optimierung die einer organisationsweiten Optimierung entgegenwirkt.
  • Intransparenz: Hohe Freiheitsgrade und mangelndes Alignment führt unternehmensweit gesehen zu einer geringen Transparenz. Die möglicherweise gesteigerte Produktivität einzelner agiler Einheiten kann nicht mehr übergreifend gebündelt werden und Steuerungsmechanismen versagen. Dies wiederum führt zu einer Gegenbewegung und Fehlentscheidungen.
  • Agilität bei Großkonzernen: Viele agilen Frameworks fokussieren in ihren Implementierungspraktiken auf die Team-Ebene als Kern des Wertschöpfungsprozesses. Vereinfachte Konzepte wie „PO definiert Business Value“ versagen jedoch in einem skalierten Umfeld, in dem der PO aufgerieben wird zwischen Anforderungen aus der Trägerorganisation, Kontakt zu Markt/Kunden und Verfügbarkeit für das Team.

Basierend auf Praxiserfahrungen wurden im SAFe Konzepte und Vorgehensweisen definiert, die auch in einem skalierten Umfeld tragfähig sind.

Scaling Agile & Lean – Scaled Agile Framework (SAFe) weiterlesen

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Ansätze, um hinweg über viele Teams zu skalieren (Scaling Agile) fehlen häufig und werden für größere Unternehmen die auf Agilität setzen möchten immer wichtiger. Häufig scheitern Implementierungen von Scrum jedoch an dem fehlenden übergeordneten Koordinierungsbedarf, da der Fokus in den meisten Fällen zu sehr auf die Entwicklungs-Teams und weniger auf die Unternehmens- oder Portfolioebene gelegt wird. Besonder viele Reibungsverluste gibt es bei der Integration von agilen Organisationsteilen (z.B.: Entwicklung von neuen Systemen) und weiterhin eher traditionell organisierten Organisationsteilen (z.B.: Vertriebsorganisation, Abteilungen mit Fokus auf Wartung, Zulieferer).

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht neu. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Scaled Agile @ Spotify im Detail

Einen sehr interessanten Ansatz für die Skalierung von agilen Teams verfolgt Spotify. Hier wurde auf über 30 Teams („Squads“) skaliert. Teams die in einem Kontext arbeiten, werden in sogenannten „Tribes“ gruppiert.  Der Kontextübergreifende Austausch geschieht durch die Etablierung von so genannten “Chapters”.

Diese Begrifflichkeiten mögen für einige gewöhnungsbedürftig sein aber sind sicherlich für viele Agilisten attraktiv, da diese häufig den klassischen Methodenwerken schon alleine wegen der vielfach missbrauchten Begrifflichkeiten ablehnend gegenüber stehen.

Liefereinheiten

Squad

Entspricht in etwa den üblichen agilen Teams, wobei kein spezifisches Vorgehen oder Framework wie beispielsweise Scrum oder Kanban vorgeschrieben ist. Es gibt einen Product Owner, der die Themen vorgibt und jemanden, der sich um das Team und die Einhaltung von Regeln kümmert (“Agile Coach”). Der “Agile Coach” gehört nicht ausschließlich zu einem Squad er muss aber für „seine“ Mitarbeiter verfügbar sein.

Scaling Agile @ Spotify
Scaling Agile @ Spotify

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters weiterlesen