{"id":581,"date":"2012-01-12T11:20:32","date_gmt":"2012-01-12T10:20:32","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=581"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"size-xxl-lean-and-agile-projects-within-ericsson","status":"publish","type":"post","link":"http:\/\/leanmagazine.net\/lean\/size-xxl-lean-and-agile-projects-within-ericsson\/","title":{"rendered":"Size XXL – Lean and Agile projects within Ericsson"},"content":{"rendered":"

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

For \u00c5ke Sundelin quality issues have always been absolutely central. It began in his student days, when he decided to study engineering at Link\u00f6ping 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. \u00c5ke Sundelin\u2019s own description of quality is, in addition to responding to customers\u2019 expectations, \u201cto create a design that is robust enough to continue working, despite any problems and errors that may arise.\u201d<\/p>\n

\"\"<\/a><\/p>\n

\u201cWhatever technical system you\u2019re using, you cannot eliminate all errors. The important thing is not to let the errors take over so that they affect the entire architecture,\u201d 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.<\/p>\n

Large and complex projects<\/h2>\n

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\u2019s \u201cLean & Agile story\u201d provides a number of lessons and insights that are becoming increasingly clear \u2013 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.<\/p>\n

\"\"<\/a>
\u00c5ke Sundelin works at Group Function Technology & Portfolio Management, (~ CTO Office). He is the driver for Product Development Strategy work within Ericsson as well as a change agent and facilitator\/teacher for Ericsson\u2019s internal SW leadership training<\/figcaption><\/figure>\n

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 \u201cgreenfielders\u201d in the form of new players with no heavy engineering staff and with completely different expectations of the systems.<\/p>\n

\u201cWe must have a system for product development that can respond to both types of customer,\u201d says Ulf Hansson. \u00c5ke Sundelin also underlines the technical diversity between assignments \u2013 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.<\/p>\n

\u201cIt 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,\u201d says \u00c5ke Sundelin.<\/p>\n

Developing a Lean & Agile structure<\/h2>\n

Lean & Agile is widely used at Ericsson to increase competitiveness. Ulf Hansson recalls a comment from a happy developer: \u201cNowadays, we use all our brains.\u201d<\/p>\n

\"\"<\/a>
Dr. Ulf Hansson, Business Unit Networks, is the Deputy Head of R\u00a0&\u00a0D Operations and overall driver for deployment of Lean & Agile ways of working within Business Unit Networks.<\/figcaption><\/figure>\n

But how do you create a sustainable Lean & Agile philosophy in a company of Ericsson\u2019s 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 \u201cScrum for the Big Ones\u201d in Lean Magazine (# 1, June 2007)<\/a>, these are medium-sized projects by Ericsson\u2019s standards.<\/p>\n

\u201cAgile methods were born in a small-scale context,\u201d says Ulf Hansson. \u201cIt 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.\u201d<\/p>\n

The starting point of the Lean & Agile-based methodology at Ericsson is \u2013 as you would expect \u2013 out in the field, among the developers. It starts with small teams with shared responsibility for the backlog, clear \u201cready\u201d criteria, short feedback loops, continuous system growth, and so on. Nothing unexpected, in other words, and so far, so good.<\/p>\n

Upscaling is the challenge<\/h2>\n

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.<\/p>\n

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 \u201cfixes\u201d the quality retrospectively<\/p>\n

\"\"<\/a><\/p>\n

Good architecture is everything<\/h2>\n

Good architecture and continuous work on the architecture is central to managing and minimizing the dependencies which in practice always exist between the teams\u2019 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 \u201cdo not rattle through and affect the whole system.\u201d<\/p>\n

\u201cIt\u2019s 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,\u201d says \u00c5ke Sundelin. \u201cThe key enabler we can create for them is to work seriously with architecture and to reduce dependencies.\u201d<\/p>\n

\u201cThe consequence of inadequate system care leads to the teams unwittingly \u2018colliding\u2019 and getting in each other\u2019s way, which you simply cannot hide when you\u2019re using Agile methods,\u201d adds Ulf Hansson.<\/p>\n

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.<\/p>\n

\u201cThe person who successfully analyses dependencies gets no negative surprises. It creates space for solving problems, and attacks them proactively,\u201d says \u00c5ke Sundelin.<\/p>\n

Part of a community<\/h2>\n

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\u2019s software developers.<\/p>\n

\u201cWe must be part of the mutual learning process \u2013 and then smart enough to apply the lessons to our own development work,\u201d says Ulf Hansson. As one of the biggest players in the industry Ericsson has unique knowledge and experience to offer.<\/p>\n

\u201cThe large-scale application of Lean & Agile places special demands on our understanding; it\u2019s really, really hard!\u201d says \u00c5ke Sundelin.<\/p>\n

\u201cThe 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 \u2018water-scrum-fall\u2019, confidence dissipates, and in a few years people will turn up with a new set of buzz words,\u201d says Ulf Hansson.<\/p>\n","protected":false},"excerpt":{"rendered":"

Methodology must be adapted, every developer must understand their part in the whole and architecture issues are key \u2013 these are three conclusions that Ericsson have reached from their experience of running large-scale Lean & Agile projects.<\/p>\n","protected":false},"author":21,"featured_media":586,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,48,59,5,83],"tags":[49,6,29,30,16],"_links":{"self":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/581"}],"collection":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=581"}],"version-history":[{"count":19,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/581\/revisions"}],"predecessor-version":[{"id":1447,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/581\/revisions\/1447"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/586"}],"wp:attachment":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=581"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=581"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=581"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}