Schlagwort-Archive: LeSS

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.

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.