How Lego used agile principles to accelerate innovation

Source:  https://www.youtube.com/watch?v=zCXMx7RcZ5I

Agile methods – in which work is done in parallel by cross-functionally staffed teams – has been the subject of a lot of hype. How refreshing, then, to discover examples of firms making it work in real life. One of the protagonists of the Lego story, Lars Roost, will be partnering with me in person at the World Agility Forum September 23-24. 

In traditional structures, things can only move as fast as the slowest party to the transaction.  Instead, imagine creating teams that have all the needed capabilities and clear processes for getting help from outside the team – such as support from compliance, legal and HR. Now, instead of customer issues being splintered among different work groups, everybody can get focused on identifying, developing, and implementing the best solution.

Leaving bureaucracy behind at LEGO

The LEGO Group dug itself out of a near-death experience in 2003 by, among many other things, creating an Enterprise Platform which created a culture of continuous improvement in all its key management processes.  Digitization was a huge part of this transformation, which took the better part of a decade and was widely credited with helping the company’s transformation. An example of how it used digital technologies in a clever way was its “Legos Ideas” initiative which allowed fans to submit ideas for new products, shortening the product development time and effectively pre-testing concepts for market acceptance.

But by 2016, LEGO’s leadership began to consider the limitations of its traditional enterprise platform from the perspective of digital customer engagement. Its “products” had become increasingly digital, and unlike a durable Lego brick, digital offerings can change (and go obsolete) very quickly. The company concluded that it needed to add an “engagement” platform to facilitate the continuous improvement of its digital products.

The mandate for this platform was to facilitate:

• Continuous delivery of functionality, with a turnaround time of days or weeks rather than months or years;
• 24/7 uptime so that unpredictable events, such as surges in demand for movies on the website, didn’t derail the customer experience; and
• Scalability, so that changes could be rapidly implemented across the company’s platforms.

To do this, they created a new way of working, inspired by the world of agile software development but with the twist that at heart, Lego still involved physical products.  A companywide email from the CIO explained the core differences in how operations would change, basically going from a structure based on functions and a matrix to a structure based on products and services:

We are going to organize ourselves around the products or services that we provide to our LEGO colleagues…IT – as the primary technology enabler – has unprecedented opportunities to create value by become an agile change agent to accelerate the rest of the LEGO Group on the digital journey.

The process was kicked off with a two-day onboarding for leaders from around the world at headquarters, in which they attended a workshop, tried out the approach and gained an understanding of the potential benefits to LEGO of the new way of working.  The change was substantial.  The company moved from functional organization to cross-functional, product based teams.  So-called “waterfall” sequential processes were moved to short-cycle continuous delivery models.  Accountability went to the teams to deliver complete solutions to the market in rapid cycles. Funding also changed, from an annual budget approach to an approach that sought to match funds to project-based work.

How the work gets done

An example of what this looked like in the digital solutions group might be helpful to understand how the work changed.  As Lars Roost (a program manager within LEGO) and Henrik Krisberg explain, work was restructured to reflect three levels of activity. Tasks originate with groups of program managers and product managers who outline the high-level outcomes the organization would like to achieve, roughly in what timeframe, to meet the company’s strategic portfolio objectives.  This work is done before the planning cycles commence, consistent with our discussion of creating a context, above.  This creates what is called a ‘project backlog.’

The basic building block of the system (no pun intended!) is a working team with all needed functional areas of expertise, working full time on the backlog on a schedule of two-week “sprints.”  The backlog might consist of new features, updates, bug fixes or user stories that the product manager would like to see implemented. The goal is to have a testable result in a two-week timeframe.

At a level above the team level is what LEGO called the “program” level in which the outputs of all the different teams are coordinated into what the company called an “agile release train” which operates on an 8-12 week release cycle. These are for larger changes to functionality or for shifts that require a coordinated response across teams.

Allocating work and setting priorities is done in a bi-monthly meetings called “product increment planning” (PI) meetings. Everybody who needs to be involved in the planning turns up – so it could be over one hundred people over a one-or-two day period. The meeting, which LEGO describes as “planning as a social event” includes video highlights of accomplishments from the last meeting, and lightning talks about matters such as new child safety requirements. After that, the teams break out into working groups, to discuss which features from the backlog will be taken on by the different teams over the next series of sprints.

A picture from a description of the first PI meeting, offered by Lars!

The teams are loosely specialized, around topics such as ID authentication, cloud technology or search, but all have sufficient functional expertise to complete the backlog elements each team accepts. Each team circulates around the room with a rolling board which is populated as tasks are allocated across the teams.  The role of product managers and the program manager who coordinates the PI meeting is of coordinators, and making sure important tasks aren’t overlooked. Notice, however, that the teams “pull” tasks into their teams rather than these being assigned by a middle manager.

Two other artifacts are used by the teams in the planning session. One is a “risk board” on which teams identify issues that could cause their commitments to fail, potential problems like “the new licenses won’t be delivered on time.”  In many cases, the teams can resolve the risks themselves, right there in the room.  It further reduces the need for management involvement. As an observer remarked, “In the past, risks tended to be either ignored or all-too-quickly delegated to management (turning them into a bottleneck). By visualizing risks in a bottom-up fashion, teams have gotten a lot better at taking ownership themselves and only escalating risks they really need help with. Sometimes the cost of mitigating the risk is huge and out of proportion to the impact, so it’s better to just accept the risk. Acknowledging and accepting the risk removes frustration and gives the team peace of mind, so they can focus on delivering instead of worrying.”

Another large board is called the “dependency board” or “program board.” Each team has a column across the top of the board, and the 4 two-week sprints that occur in between the planning meetings form the rows. What the teams do then as tasks are accepted by each team is put sticky notes on the board, indicating dependencies.  As in “in order to deliver this (a blue sticky), we need that (a pink sticky) from you.”  Each of the dependencies are connected visually with strips of red yarn. Teams then self-organize around a discussion of how the dependencies will be resolved so that they can accomplish what’s needed without having to wait for inputs from other teams.

The breakouts wrap up with a “draft plan fair” which consists of people walking around the room for 4 7.5 minute sessions looking at other teams’ plan boards. One representative from each team remains to explain their team’s goals; the rest wander around. While it might seem as though this should be handled in large plenary, the folks at LEGO learned that it was more efficient to have people just go to the teams they had the greatest interdependence with or cared the most about.

Where does management get involved?

All of this is now followed by the management review of the whole plan, in which more senior leaders look at the outputs from the day and engage in a discussion of tradeoffs and risks.  Conclusions such as “we don’t have enough resources to do both A and B within this next planning cycle” are discussed in a facilitated conversation.    The managers are also required to go through the risk boards, as the only risks left are ones the teams can’t resolve themselves.  The goal is to meet the goal of ROAM – the risk is Resolved, Owned, Accepted or Mitigated.

An example of a pernicious problem solved by the team approach is of a finance product that was estimated to require 8,000 hours of development time. The business case for it was never approved in the context of larger LEGO portfolio priorities. After the shift to the new way of working, the finance team’s product owner was able to make it a top priority, and the team was able to develop and demonstrate a pilot version of the product in just two sprints – 4 weeks and less than 800 hours, one tenth of the original time estimate.

Permissionless innovations

The innovations created through LEGO’s process have been so successful that the company has been called “The Apple of Toys” and consistently landed on any number of most innovative company lists.

Other innovations include wooden LEGO accessories for the home; “Build to Launch,” an offering to get kids excited about science and space travel;  a partnership with Target to offer ‘highly giftable’ products for the 2021 holiday season; an ambitious “rebuild the world” brand campaign and others too numerous to mention!

If you’d like to hear about the journey for yourself, consider joining us at the World Agility Forum!

Meanwhile, at Valize

We’re launching our fall cohort of learners for our Discovery Driven Planning / Creating Customer Insight program.  In just 8 weeks, you can learn the fundamentals of creating product-market fit, that all-important starting point for value-creating innovation.  There are 6 mini-courses included, plus 6 live office hour sessions with me.  Find out more at this link.