Methodology must be adapted, every developer must understand their part in the whole and architecture issues are key – these are three conclusions that Ericsson have reached from their experience of running large-scale Lean & Agile projects.

For Åke Sundelin quality issues have always been absolutely central. It began in his student days, when he decided to study engineering at Linköping University, initially with a focus on manufacturing. While his fellow students chose to be educated in saving the environment or making money, his focus was on quality. Åke Sundelin’s own description of quality is, in addition to responding to customers’ expectations, “to create a design that is robust enough to continue working, despite any problems and errors that may arise.”

“Whatever technical system you’re using, you cannot eliminate all errors. The important thing is not to let the errors take over so that they affect the entire architecture,” he says at the beginning of our conversation. It soon becomes clear that he is already touching on one of the key issues in what we are really here to talk about: Lean & Agile projects, size XXL.

Large and complex projects

Methods based on Lean & Agile principles in some form or other have been used within the Ericsson Group for just under a decade. Ulf Hansson, Ph.D. in Communication Theory at Chalmers University of Technology, says the company’s “Lean & Agile story” provides a number of lessons and insights that are becoming increasingly clear – especially when we talk about scale. Here we are referring to huge systems with millions of lines of custom code that have to work reliably for 5 to 10 years and sometimes even longer than that.

These development projects are not only large but also multifaceted. Today the group works with hundreds of customers, typically telecom companies with widely differing needs and requirements. These include everything from experienced operators with large technology departments to “greenfielders” in the form of new players with no heavy engineering staff and with completely different expectations of the systems.

“We must have a system for product development that can respond to both types of customer,” says Ulf Hansson. Åke Sundelin also underlines the technical diversity between assignments – everything from infrastructure to applications. It is a broad playing field, where different rules apply in different zones. Some of these rules are formulated not by the customer or supplier, but by international standards organizations.

“It is a huge challenge to manage such breadth. An implementation of Lean & Agile methods that works at one end of the spectrum does not necessarily work at the other,” says Åke Sundelin.

Developing a Lean & Agile structure

Lean & Agile is widely used at Ericsson to increase competitiveness. Ulf Hansson recalls a comment from a happy developer: “Nowadays, we use all our brains.”

But how do you create a sustainable Lean & Agile philosophy in a company of Ericsson’s size? First of all you have to understand the size difference that exists between their own projects and those undertaken by other companies in the Lean & Agile community. When Jeff Sutherland writes about “Scrum for the Big Ones” in Lean Magazine (# 1, June 2007), these are medium-sized projects by Ericsson’s standards.

“Agile methods were born in a small-scale context,” says Ulf Hansson. “It is a simplification to think that you can take a carbon copy of The Agile Manifesto and apply it to a large organization such as ours.”

The starting point of the Lean & Agile-based methodology at Ericsson is – as you would expect – out in the field, among the developers. It starts with small teams with shared responsibility for the backlog, clear “ready” criteria, short feedback loops, continuous system growth, and so on. Nothing unexpected, in other words, and so far, so good.

Upscaling is the challenge

The challenge is to upscale to a large and complex task without increasing the actual volume of the project; rather, finding the right methods to divide the task into smaller parts that together make up the whole. Of course this opens up a conflict between large scale and basic Lean & Agile principles. The challenge for method developers is to reconcile bottom-up and top-down perspectives.

There are two approaches. In the traditional model the task is divided into subsystems or components that are eventually pieced together into a functioning system. Experience shows that this integration step takes a long time and can cause more difficulties than the entire initial work on the components. Instead the aim is to slice the task into parts that are each testable on their own at system level. These parts are developed in parallel by crossfunctional teams and are integrated continuously during the development process. This avoids a long integration phase at the end. Furthermore, testability of components at the system level gives the teams the opportunity to take full responsibility for ensuring that their solution really works. No one outside the team “fixes” the quality retrospectively

Good architecture is everything

Good architecture and continuous work on the architecture is central to managing and minimizing the dependencies which in practice always exist between the teams’ tasks. The teams must understand and take responsibility for how they affect the whole. A simple and well documented system architecture is critical for success; it is based on modularity, it is easy to add and subtract features, and errors “do not rattle through and affect the whole system.”

“It’s easy for developers to embrace Agile practices, but if we do not create the right conditions for them, their chances of success will be very limited,” says Åke Sundelin. “The key enabler we can create for them is to work seriously with architecture and to reduce dependencies.”

“The consequence of inadequate system care leads to the teams unwittingly ‘colliding’ and getting in each other’s way, which you simply cannot hide when you’re using Agile methods,” adds Ulf Hansson.

At Ericsson they use the traditional tool of dependency mapping. The more you can understand dependencies, the more control you have over your system and can minimize the risk that teams collide during development.

“The person who successfully analyses dependencies gets no negative surprises. It creates space for solving problems, and attacks them proactively,” says Åke Sundelin.

Part of a community

These two colleagues both think it is important that Ericsson has a generous exchange of knowledge and experience with the rest of the Lean & Agile community. They see it as healthy to allow themselves to be influenced and inspired by other companies. They give as an example the Swedish vehicle manufacturer Scania, which is recognized as an excellent Lean enterprise and whose knowledge and experience of modularisation is valuable, even for Ericsson’s software developers.

“We must be part of the mutual learning process – and then smart enough to apply the lessons to our own development work,” says Ulf Hansson. As one of the biggest players in the industry Ericsson has unique knowledge and experience to offer.

“The large-scale application of Lean & Agile places special demands on our understanding; it’s really, really hard!” says Åke Sundelin.

“The transformation to large-scale Lean & Agile is difficult and disruptive, but it is something that is far too good to be dismissed simply because of the obstacles we often encounter. If we do not share our experiences, chances are that the concepts are watered down to ‘water-scrum-fall’, confidence dissipates, and in a few years people will turn up with a new set of buzz words,” says Ulf Hansson.