Q&A with Andreas Schliep on ScALeD – Scaled Agile and Lean Development

| by Ben Linders Follow 25 Followers on Jan 02, 2015. Estimated reading time: 7 minutes |

The introduction and integration of agile approaches to an organization should be regarded and treated as an agile project itself says Andreas Schliep. ScALeD, Scaled Agile and Lean Development, provides a set of principles to test agile methodologies or frameworks against. Andreas calls ScALeD “a practitioner driven movement to help organizations to find a sound and balanced approach to agile transition and scaling questions”.

Andreas will talk about ScALeD at the Scaling Agile for the Enterprise 2015 congress on January 22 in Brussels, Belgium. This event is presented by the Agile Consortium Belgium and managed by UNICOM. InfoQ will cover the event with Q&As, write-ups and articles.

InfoQ interviewed Andreas about pitfalls when trying to scale agile, on ScALeD and how it compares to Agility Path, LeSS, SAFe and DaD, and on continuous improvement and scaling retrospectives.

InfoQ: Can you describe some of the pitfalls that can happen when organizations try to scale agile?

Andreas: Becoming more agile is a challenging and dangerous mission. Many organizations do not understand that. Someone heard about a tremendous success at another place, wants to introduce and apply the "success recipe" in her own context and wonders why it does not deliver the desired outcomes. This effect is comparable to the history of Lean adoption, when many companies tried to copy the Toyota Production System practices without understanding the principles and committing to the values. Lean and Agile are not the same, but they share some conceptual roots. The lack of understanding leads to a lack of adaptability to the own context, especially with frequently changing environmental conditions. The ability to adapt quickly to a changing context could be called agility. If you buy the buzzword, but don’t commit to its meaning, any destabilizing factor is sufficient to break your beautiful structure.

Some typical scaling pitfalls caused by lack of understanding and the reluctance to become agile are:

  • Role assignments for the sake of the process: The Product Owners are not really the owner of the product. The Scrum Master is not really supposed to help the self-organizing team become as successful as possible, but just a project manager with a new name.
  • Role "optimization": Scaling appears to be a great opportunity to save costs for "supportive" roles. Let us have one Scrum Master for four teams. Let us combine team lead and Product Owner responsibilities.
  • Remote Controls: Scaling often comes up within distributed work contexts. Instead of working with their teams at one place, several Scrum Masters and Product Owners are supposed to work with a team at a different location. While this might work for Product Owners, it is definitely no work constellation for Scrum Masters and agile coaches.
  • Sticky positions: Some agile approaches like Scrum demand a fundamental organizational change. This is not possible, or at least blocked by hierarchies and separate positions, like Enterprise Architect, Senior Business Analyst, Lead Security Expert or Project Manager.
  • Wrong focus: Scaling agile, or agile scaling is possible. And yet it might not be the solution to the real problem. Many companies would fare better, if they downscaled or re-collocated their development teams. Agile product development is about building the right product to delight the customer, not to produce more crappy output.

InfoQ: At the Scaling Agile for the Enterprise event you will talk about ScALeD. Can you briefly explain what it is?

Andreas: First of all, ScALeD – Scaled Agile and Lean Development – is not another scaling framework. We see ScALeD primarily as a practitioner driven movement to help organizations to find a sound and balanced approach to agile transition and scaling questions. Inspired by Lean and agile values, driven by principles and completed through various practices and frameworks. Our main mission is to create awareness about what agility can mean for an organization.

The core of ScALeD is a set of 13 principles, structured into 5 pillars. The pillars or outline of ScALeD resemble the main lean values:

  • Excited Customers
  • Happy and Productive Employees
  • Global Optimization
  • Supportive Leadership
  • Continuous Improvement

The principles are derived from Lean, the Manifesto for Agile Software Development, Scrum, and Systems Thinking. No matter what your organization is producing, how big it is, the principles should be valid above the given context. If you read them, they do not even talk much about scaling. So, ScALeD alone won’t tell you how to work on a product with 20 teams. But it can help you to determine if your approach will support or violate the fundamental principles.

InfoQ: What can teams and organizations do to ensure continuous improvement when they are attempting to scale agile?

Andreas: Agile processes depend on short feedback cycles. Even if you do not want or need product development iterations, a regular rhythm of inspection and adaptation is highly recommendable. This is typically implemented through retrospectives. According to ScALeD – and several of the scaling frameworks mentioned below – this improvement cycles cannot be limited to the team level. Instead of rolling out a framework based on a blueprint, the introduction and integration of agile approaches to an organization should be regarded and treated as an agile project itself! Agile organizational development assumes that there is always an opportunity to do something better the next time. Agile organizational development needs a person in charge, a Product Owner who takes care and responsibility for pace and intensity of the change. It requires a constantly maintained, prioritized and ordered backlog of improvement options. And an organizational development team, that self-organizes to address the improvement options, issues, incidents and creates product increments of a better organization.

InfoQ: There are several frameworks for scaling agile, like Agility Path, LeSS, SAFe and DaD. Can you give advice on how organizations can select which ones they can use to adopt and scale agile?

Andreas: Well, some of these frameworks have really nice looking big pictures! Seriously, there is a reason why the ScALeD Big Picture is actually a blank page. We advise everybody to understand the values and principles first, and then take a look at frameworks and processes. There is much knowledge and wisdom in these frameworks, but they are not "ready to install" off-the-shelf products you can simply buy and apply. As George Box said, "all models are wrong but some are useful." All of these models are useful. DaD has a strong emphasis on software quality. SAFe is appealing to traditional organizations, as it helps to align different organizational models. Agility Path is very principle-driven, and strong in terms of the continuous improvement aspect. LeSS is pretty close to our ScALeD ideas, Bas Vodde and Craig Larman inspired much of the ScALeD foundations.

Yet, all these models are to living agile organizations just like the plastinated bodies from "Körperwelten" compared to a real life human being. They can inspire you, they can teach you a lot about structure and anatomy, but if you do not have a clue about the living organism, you will not be able to act beneficially for it. On the other hand, you can derive a lot of material for practical experiments and initial organizational setups from SAFe and co. We have worked on a gradual comparison of scaling frameworks according to their realization of ScALeD principles, that can give you a first impression about the strength and weaknesses of each framework. This comparison would rank Agility Path higher in terms of continuous improvement than DaD, for instance, because Agility Path is build on continuous improvement as the main agile transition development cycle, while DaD mainly contains retrospectives on team level and relies on managers and metrics.

InfoQ: Do you have suggestions on how to use retrospectives in scaled agile environments?

Andreas: Retrospectives are one of the core elements for successful team and organization wide continuous improvement. In order to use this instrument well, we need to ensure that we have skillful, trained facilitators at every level. It is not enough to have an Enterprise Agile Coach, CSC or whatever, who performs nice retrospectives with the whole product organization once in a while. Jimdo is a good example for institutionalized retrospective facilitator education. Regardless of the specific process, each team has at least one person who is capable of running decent retrospectives. The team retrospectives provide the fundament for the organizational change backlog. Ideally, they result in well formulated improvement stories, with "organizational acceptance tests". The transition or change team can use them directly and rank them to achieve the best possible positive effect on the organization.

My vision is to establish "Behavior Driven Organizational Development" as a basic PDCA loop. The teams come up with improvement suggestions. The suggestions are discussed between team representatives, stakeholders and transition team members. They are distilled into actionable items with clear acceptance tests. The changes are "developed" by the transition team and demoed to the organization, to identify new improvement opportunities. This cycle could take two to four weeks not longer. After the demonstration of implemented organizational changes, the transition team would hold their own retrospective, of course. This is important to ensure that the work model does not become static but remains agile. Able to respond to unexpected changes in the organizational context.

Andreas suggested several reading links for people who want to learn more about scaling agile and lean:

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

More Principles by Bob G


We have been tracking Agile and Lean principles in a consolidated list of principles (see link below). Although I welcome your initiative, I am not sure how this list (and new wording) will help moving forward the discussion on Agile transformation.

Although principles are at the core of an Agile transformation, what I see as missing in the Agile-at-Scale landscape is clear guidelines and good practices on how to perform an large Agile Transformation (without simply listing Kotter's 8 steps).


PS: I had an error message (reCatcha API) when leaving comments at

Re: More Principles by Andreas Schliep


Your poster about Lean principles is well done. And it illustrates how maybe the idea of a long-term-philospohy in expense of short-term goals got lost along the way. The ScALeD headlines and principles are not new, we regard them as a kind of aggregation or focal point for the further discussion. In fact, we would not need all of these principles if the majority of people just understood and applied PDCA. That turns 100 in a couple of years, by the way.

As you can see pretty well in Agility Path and Jeff Sutherland's modular framework, there is no clear, ideal and generally applicable scaling path. You cannot roll out Scrum and agile. The transition path is unique and special for each company, regarding order, depth and pace of the single steps. Jeff Sutherland talks about patterns that might apply to a given context. This is exactly in line of thought with our understanding of complexity. Agile product development is cycling around the complex area, with innovative visits into the chaotic realm and merely complicated iterative or one-piece-flow development. It would be highly suspicious to see a well-defined process or organization architecture here. Instead, we need to find guidance in principles and patterns.

Following that, the next step for ScALeD could be to collect patterns, typically in the form of practices. You can find some examples at the ScALeD author's websites - or in my talk, which will be published after the ACB event. Yet, most of the actual practices can be found in the various scaling frameworks, like LeSS or SAFe. It is not difficult any longer to create a nice picture about how a scaled agile organization looks like. And it is still hard work to get there.

Re: More Principles by Andreas Schliep


Nice list. It illustrates, how the Lean principles became simplified and decomposed. ScALeD can't be so new, as PDCA is almost 100 years old. We would not need all the principles, if everybody just understood and applied PDCA correctly.

Agile is an approach to address issues and challenges in the complex domain. As such, it will not come with clear processes and blueprints. Instead, we need principles and patterns as guidance. The ScALeD principles are supposed to be a focal point to approach the known patterns in a different way. This is one of the parts of my presentation at ACB.

Best regards

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you