ScALeD Agile Lean Development – The Principles

Agile methods are becoming ever more popular, and a growing number of companies has adopted agile practices on a large scale. But successfully scaling agility is challenging. As companies, projects and teams differ, there is no silver bullet solution to large-scale agile  development.

We believe that not a new method or an additional framework is required to successfully apply agile practices at scale but rather a set of guiding principles, which we have described below. The principles are not genuinely new. We have rather taken existing ideas and reworded them to address the scale challenges. Feel free to reuse the text below but please reference this site.

Excited Customers

Excited customers enable sustained business growth. The task of product development is to create the basis for this growth.

Define Value and how it is Created

A shared understanding of the product’s value proposition is especially important in a scaled organisation. Product goals help to achieve the strategic objectives, and shared values provide guidance for all project members

Produce small, deliverable increments

Increments build on each other while presevering the functionality of the previous increments. They help create and measure value. A deliverable product increment can be released while additional features can still be added.

An increment ideally provides value for the customer. But even if that is not possible, small, deliverable increments provide the basis for the continuous growth of the product; they minimize risks and reduce complexity.

Happy and Productive Employees

In product development the employees offer the greatest improvement potential, and satisfied employees achieve a higher productivity. It is therefore important to create a work environment that results in motivated employees.

Create Independent, Cross-functional Teams

Teams are the most effective way to accomplish complex work. How people interact within one team and be extended to the interactions between several teams: Teams should be able to communicate with each other independently and without artificial barriers. The company’s job is to provide the right goals, structures, environment and support.

Authorize and Empower your Employees

Employees working on a large-scale agile project require not only the right technical skills. They have to take on ownership for their work and support each other. Only then can teams do a great job for the organisation and the customer. Teams have to be empowered to own and manage their work and to make the necessary decisions.

Global Optimization

When scaling a modular, loosely coupled product architecture is essential. But focussing only on individual components can quickly lead to sub-optimisation. It is therefore necessary to consider the entire value chain and to integrate modules and components frequently.

Create Transparency in all Directions

To make the right decisions, employees require the right information particularly the objectives, constraints, agreements and the current status. It is not enough to store this information. Encourage an active exchange of relevant information to foster continuous improvement.

Prefer Direct Communication

Personal and direct communication promotes the exchange of knowledge, skills, goals, needs, concerns. Tacit information is often only available when people communicate directly. Personal contact is important not only within a team but also between teams and with the rest of the organisation.

Create Flow and Rhythm

Flow and rhythm throughout the entire value chain are important enablers for high-performance teams alongside clear objectives, frequent synchronisation and fast (or no) handovers.

Supportive Leadership

Managers play an important role as teachers and enablers in an agile environment. As leaders they serve the company and the employees and they do their best to support creation of value.

Set Objectives and Provide Support

Managers set goals and provide support. They remove bureaucratic hurdles, dissolve rigid structures and successively empower the employees. As a leader, you serve the company and the employees by doing the best to help create a successful product in a healthy, sustainable way.

Decentralize Control Structures

Self-organisation does not only take place within a development team, but also across the teams. Long decision-making processes consume valuable development time. Most of the decisions should hence be made by those carrying out the work. For the coordination of multiple teams hierarchical control authority is not necessary. Follow the principles of transparency, direct communication, inspection and adaption, and global optimisation instead.

Cultivate the Change and Change the Culture.

During an agile enterprise transition, all the parties involved should understand the values, the objectives and their own role in the change process. Senior management should lead the way and actively help to make the necessary changes.

Continuous Improvement

Continuous improvement – at all levels of the organisation – is an important agile practice. It is facilitated by repeated inspection and adaption. Inspection should be based on direct observation and communication; adaption should happen without any delays.

Inspect and Adapt the Product

Frequently inspecting the entire product and adapting any plans allows the creation of a product that does a great job at meeting the customer needs. This is particularly crucial in a scaled environment.

Inspect and Adapt the Development Process

Just as the process within a team should be owned by team members, the process involving several teams should be owned by those teams. The teams reflect together. They identify strengths and weaknesses, define appropriate improvements and implement them.

Inspect and Adapt the Organisation

Improvement in an agile organisation is not a straightforward change, but an iterative process: inspection and adaption steps take place regularly. The current organisation is investigated, new opportunities and challenges are identified, improvements are derived and prioritised.

Written by

Show

Supporter

If you think that the approach for scaling agile, considered above, is the right one, we would like to call you a supporter. Just make a record for yourself leaving a comment on this blog post.

Show

37 thoughts on “ScALeD Agile Lean Development – The Principles

  1. Mischa Ramseyer (pragmatic solutions)

    Je länger ich mich mit der Agilität und dessen Grundlagen auseinandersetze, desto überzeugter bin ich, dass Werte und Prinzipien wichtiger sind, als die effektiv eingesetzten Modelle und Praktiken. Daher ist das Vorgehen, mit den Prinzipien und dem WHY zu starten auf jeden Fall richtig! Lasst uns aufhören, über Methoden zu streiten und stattdessen Einigkeit bei den Prinzipien zu erzielen!

    Reply
  2. Stefan Meier

    Bin voll einverstanden mit den Prinzipien.
    Würde dennoch das Thema “Kultiviere den Wandel…” noch etwas prominenter darstellen. Dies ist meines Erachtens die Voraussetzung, dass überhaupt die anderen Prinzipien gelebt werden können. Wenn sich eine Unternehmung in diese Richtung wandelt, braucht es das volle commitment vom Management, ansonsten wird es irgendwann zum “culture clash” kommen…
    Freue mich zu sehen, wie sich die Prinzipien durchsetzen
    Gruss
    Stefan (agil infiziert ;-)

    Reply
  3. Malte Foegen

    Das sind gute Prinzipien. Mit gefällt die Kombination der agilen und Lean Prinzipien. Diese sind eine gute Richtschnur für die Skalierung von Agile und Lean.

    Reply
  4. Josef Scherer

    Hallo,

    ein super Ansatz, den ich gerne unterstützen würde.

    Das Thema unterstützende Führung würde ich an die erste Stelle setzen, denn ohne diese ist Skalierung (weder horizontal noch vertikal) langfristig erfolgreich.

    Ein paar zusätzliche Change Prinzipien, die an andere Stelle genannt werden, scheinen mir wichtig:
    – Jede Organisation ist anders, (context matters)
    – Skaliere nicht, wenn es keine Notwendigkeit dafür gibt
    – Finde die passende Balance aus Prinzipien und Praktiken

    Reply
  5. Nayan Hajratwala

    Very nicely summed up. I might suggest removing the funny casing from the title (ScALed, etc). I think it would be confusing to people who are truly coming to look for advise / guidance, and don’t understand the inside joke.

    Reply
  6. Andreas Geitner

    Die Prinzipien finde ich äußerst aussagekräftig!
    Ein klassisches Beispiel für mich:
    Ich sehe es tagtäglich im Projekt, dass es bei der Skalierung äußerst wichtig ist, erst INTEGRIERTE Inkremente als DONE zu bezeichnen um eine späte Integrationshölle zu vermeiden. Viele kleine Integrationen sind dabei beherrschbar und liefern, im besten Fall täglich, nutzbaren Mehrwert für den Kunden.

    Viele Grüße,
    Andreas

    Reply
  7. Sabine Canditt

    Ich finde die Zusammenstellung sehr gelungen: einfach, überschaubar und dennoch vollständig (zumindest fällt mir nichts Grundsätzliches auf, was fehlt). Praktiken (z.B. development skills, Team-basierte Ziele und Bewerungskriterien, Verwendung von Metriken…) ergeben sich implizit, wenn man die Prinzipien umsetzt.

    Grüße
    Sabine

    Reply
  8. Wolfgang Richter (JIPP.IT GmbH)

    Hallo Jungs, hallo Peter,

    ich schließe mich Ron Jeffries an: Eine absolut passende Sammlung an Prinzipen, ein guter Start. Was mir noch fehlt ist der Sales Pitch. Was würde das beste Konzept bringen, wenn es keiner haben will.
    Wie in Graz kurz andiskutiert würde ich empfehlen diese Sammlung auf die Organisationsaspekte und Systeme, die innerhalb von Organisationen werkeln zu erweitern. Das Viable Systems Model von Stafford Beer aus der Kybernetik passt ausgezeichnet dazu. Im Gegensatz zu SAFe würde das die Prinzipien nur ergänzen und für die unterschiedlichen Funktionen in Unternehmen verständlicher machen. Ein wenig Marketing darf ja schon sein ;) Nur Rationales verkauft sich schlecht, obwohl der RUP ja über den Umweg SAFe ganz gut im Geschäft ist … .

    Liebe Grüße, Wolfgang

    Reply
  9. Peter Stevens

    Very nice. I support these principles and practices. This resonates well with my own experience.

    If there is one thing missing, it is the concept of voluntary cooperation, aka buy-in. This is related to empowerment, but goes a step a further. You can’t tell people to do Scrum (well, you can, but they will find a way to make it fail, if you do). It is best to ask people to do Scrum and start with the volunteers.

    Peter Stevens
    Scrum Trainer, Stoosian and Entrepreneur

    Reply
  10. Roland Oehen-Kanzow

    Full support – volle Unterstützung!

    Ich denke, die genannten Punkte geben agilen, skalierenden Organisationen und den begleitenden Coaches gute Anhaltspunkte, auf welche Bereiche geschaut und im Sinne einer kontinuierlichen Verbesserung der Fokus gelegt werden kann.

    Weiter empfehle ich Organisationen, ob agil oder nicht, sich hier von diesen Punkten diejenigen herauszupicken, von denen sie denken, dass sie eine Unternehmenskultur des “Miteinander und Füreinander” schaffen. Ich bin überzeugt, dass dies ein “Must” ist für jedes zukunftsorientierte Unternehmen.

    Reply
  11. Ronald Jeffries

    These are very good principles, certainly. I would want to think a bit to decide if they are all the principles I’d like to see in a “scaled Agile”. It’s certainly a great start.

    Some issues:

    First, I’m not sure “Excited” customers is the word I’d use. Angry people are excited to. “Delighted” is a bit cliché. Perhaps “Happy, satisfied customers”.

    Second, I’m concerned that “Global Optimization” will turn into top down direction in the style of SAFe, trying to get everyone doing the same thing.

    Third, I’m concerned about how this idea will “sell” to the organizations who think they want scaling. Is it too idealistic with its talk of excited customers and happy workers?

    I fully support the ideas: they all seem right to me. I’m concerned about some of the words. Keep going!

    Reply
  12. Martin Heckmann

    Kann den Prinzipien aufgrund von Erfahrungswerten bei mehreren kleineren und größeren Unternehmen nur zustimmen. Das bietet einen hervorragenden Rahmen, um darüber zu diskutieren, wo das Unternehmen steht und mit welchen Mitteln die Prinzipien lebendig werden können und auch bleiben. Viele Ansätze und Methoden beziehen sich ausschließlich auf die IT, hier geht es aber um die Organisation als gesamtes.

    Martin Heckmann
    (ScrumMaster und Agile Process Master)

    Reply
  13. André Paffenholz (PENTASYS AG)

    Ich kann mich meinen Vorrednern nur anschließen: Eine super Zusammenfassung die es auf den Punkt bringt!

    Im Laufe der Zeit werden sich sicherlich noch einige Methoden und Praktiken als empfehlenswert herausstellen, um die globale Skalierung zu optimieren. Daher hoffe ich das diese Seite weiter “lebt” :-)

    Viele Grüße
    André

    Reply
  14. Bernhard Fischer

    Das was agile Produktentwicklung ausmacht sind Werte und Prinzipien. Der Versuch Entwicklungsvorhaben nur auf der Basis von etablierten Praktiken zu skalieren muss daher scheitern. Ich glaube, eure Prinzipien sind gut zur Skalierung von Agilität geeignet.

    Reply
  15. Ramon Anger (Capgemini)

    Viele gute Punkte. Neue agile Methoden im Kontext großer Entwicklungsvorhaben würden würden schnell zu eher schwergewichtigen Prozessen führen und schnell den Anspruch auf Allgemeingültigkeit verlieren.

    Der schwierigste Aspekt, den ihr beschreibt, ist die globale Optimierung. Hier kann es nur auf das konkrete Vorhaben individuell angepasste Lösungen geben.

    Reply
  16. Oliver Fischer

    Agilität lässt sich nicht verordnen, weder füreinander Team noch für eine Organisation. Ich glaube diese Prinzipien stellen einen guten Weg dar, um Agilität zu skalieren.

    Viele Grüße,
    Oliver Fischer, FIDUCIA IT AG, Center of Competence Agile

    Reply
  17. Holger Berndt

    Nach unserer SCM-Schulung und -zertifizierung sind wir in unserem noch jungem Unternehmen genau auf diesem Weg. Dieser Weg ist nicht ganz so einfach, weil man einfach noch in alten Bahnen steckt, aber wir sind davon überzeugt, dass dies langfrsitig der bessere Weg ist.

    Grüße, Holger

    Reply
  18. Fahd Al-Fatish

    1) Ich bin der Überzeugung, dass Techniken, nicht unbedingt und nicht in jedem Fall skalierbar sind, Prinzipen dagegen schon! Daher stimme ich dieser Initiative grundsätzlich zu.
    2)Es geht vor allem eine Umgebung zu schaffen, wo wir ständig unsere Prozesse und vorgehen optimieren und von den letzten Schritten zu lernen. Die gesamte Kunst besteht daran ein funktionierenden Continuous Improvement Process zu etablieren.
    3)Bemerkung zu: “Produziere kleine, lieferbare Inkremente”:
    Wenn das Ziel bei einem Team, ein” Done Inkremente” iterativ zu bauen, dann ist das Ziel bei der Skalierung ein “integrierte Done Inkremente” iterativ zu liefern. Dazu sind alle genannten Prinzipien und Skills nötig, besonders diejenigen, die in der Software Engineering sind.

    Reply
  19. Matthias Grund (Gründer andrena objects)

    Ich bin sehr einverstanden mit Euren Überlegungen.
    Eine kleine Marginalie: Die Basis für jede Skalierung ist die Fähigkeit, im Takt Inkremente von definierter Qualität zu liefern – also doch wieder Extreme Programming”.

    Gruß, Matthias

    Reply
    1. Peter Erne

      Tolle Zusammenfassung! Einverstanden, wenn wir die Essenz herausdestillieren wollen, sind es genau diese Prinzipien. Die Umsetzung bleibt auch so noch spannend und anspruchsvoll.
      Peter Erne, Leiter Methoden und Werkzeuge, SBB

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>