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:
