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.

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.

This is an excellent take on why would you do agile at all. And it also steers away from the “use method X” and you will have a scaled agile organization” trend. It is human to search for a simple pattern to follow, but as you scale the number of variables grow so that no model can be effective for all organizations. (At Scrum-team level, that’s maybe possible as a starting point…)

I agree with Ron Jefferies that the wording “Global Optimization” might lead thoughts to a standardisation that is non-optimal. Maybe “See the Whole”, borrowed from Lean, is a better term.

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.

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.