Agile has been part of LEGO for more than a decade, but it is still spreading seeds and finding applications in business areas outside digital and IT. Some of LEGO’s core values are play and learning which resonate very well with the agile principle of iterations, experimentation, and retrospectives.
Eik Thyrsted Brandsgård, director in LEGO’s internal marketing agency, spoke about some of the agile practices LEGO has experimented with at the Agile Summit Greece 2017. InfoQ is covering this conference with Q&As, summaries, and articles.
InfoQ interviewed Eik Thyrsted Brandsgård who has been part of LEGO’s agile journey to find out more about what they discovered on their way.
InfoQ: What made LEGO decide to start with agile?
Eik Thyrsted Brandsgård: When I started at LEGO back in 2005, agile was already present in small scale in terms of XP - we had developers who did paired programming. The knowledge of agile was slowly spreading and it really got traction around 2009 when the teams developing LEGO Universe (a Massively Multiplayer Online Game) were certified in Scrum by Ken Rubin. When LEGO Universe ended years later the agile practices were really embedded in the digital branch of LEGO. Coming from LEGO Universe felt a little like coming from Tour de France with really good legs. Some of the teams from back then are still pretty much intact and working really well.
We kept recruiting and training people in agile but as LEGO grew we got growth pains (aka increased complexity) and in 2014 we decided to use SAFe as the starting point for scaling agile. Over the next years we tweaked the method and continuously identified and removed interdependencies and eventually managed to reduce some of the complexity and constraints and scale down to a scrum based setup again.
InfoQ: What did you adapt to make SAFe work better for LEGO?
Thyrsted Brandsgård: The framework is very comprehensive, almost an all encompassing guide to agile. Since we had started with Scrum the obvious choice seemed to build the next layer on top of Scrum - the program layer. The portfolio management part at the highest level still ran as a cross-company yearly process following a regular financial planning cycle. We are still pursuing getting this more agile, but it is a very big change. And we found that we could make parts of SAFe work within a more traditional operating model.
On a "team of teams" level we stopped presenting all team plans for everybody and created a "plan fair" where teams could opt in on listening to other teams plans. Not all team plans are relevant to everybody so we let the teams choose what was relevant for them.
We removed themes and features from the program wall and changed it into a dependency board only. We found that teams are not super interested in every other team’s work, only the interdependencies between teams. So having themes in there created more clutter than contributing to transparency.
We also stopped the confidence vote, there was too much confusion on what the confidence was about - your own team? The whole thing? It is a super tool on a smaller scale, but the dynamics are different in such a big group with hundreds of people.
We pushed responsibility for the ROAM (Resolve, Own, Accept, Mitigate) risk management closer to the teams and asked them to come with mitigating suggestions on their own and empowered them to make their own actions, moving them up the responsibility ladder. This way only the really tough risks have to be discussed in the management review.
And we experimented with inspirational talks from the center stage since we had gathered so many people but found that it took too much focus away from planning. Eventually, we shaved off "waste" based on participant feedback and now we are able to do the whole planning in one day to everyone’s delight. Shu-Ha-Ri.
InfoQ: How is big room planning done at LEGO?
Thyrsted Brandsgård: The short answer: We get 150 people into a very big room and don’t let them out until they have created a plan for the next two months [laughing]. Well, that’s the pinnacle of it. The process is very much like Scrum, but at scale. We do some preliminary planning first. We identify the work we want to prioritize from a business perspective. This is estimated roughly and broken down a bit to identify the major technical elements. This is the backlog we enter big room planning with and the teams then pull work and break down and estimate in a scrum fashion. When the team is done with one item from the shared backlog, they pull the next until they have used their expected capacity.
At some point during the big room planning the teams present their preliminary plans and adjustments are made if needed - removing impediments, mitigating risk, reprioritizing, moving work to other teams to create flow.
InfoQ: Which benefits does LEGO get from doing it big room planning?
Thyrsted Brandsgård: These are some of the benefits that we got:
Fast decision making
All teams, deciders and major stakeholders involved in bringing the product to market are in the room. So it is quick to share information and make decisions.Transparency
It becomes pretty clear what is required to fulfil the business needs. Sometimes ideas that appear easy are quite hard to do and vice versa. As a stakeholder you can see this first hand - no one is trying to hide the complexity or add buffers; it is what it is.Empowerment
Teams are the only ones who can really plan and estimate how to accomplish the work and stakeholders can make immediate decisions. This creates a fast feedback loop that empowers both team and their stakeholders to make valuable business decisions.Identifying dependencies and complexity. The dependency board really uncovers where teams are depending on each other. It also visualises overall complexity and if a pattern emerges there is an opportunity to remove some of the complexity.
Socializing
With so many people gathered at once, it can seem as one big team building event. There is a lot of buzz going on and people will discuss both business as well as keeping connections.
InfoQ: What have you learned from the way that agile has been scaled at LEGO?
Thyrsted Brandsgård: A well described method as SAFe is an excellent starting point for scaling agile but as the organisation learns it is important to try and experiment and find its own path. Really use the agile methodologies built-in feedback loops and quickly do tweaks and changes. In a sense it is about reducing waste in the process, and it becomes very apparent were 150 people lose their energy and what excites them - what they find truly valuable. And it takes good facilitation to orchestrate 150 people. It is more big band and jazz than the symphonics, but it still requires good facilitation to run smoothly - both during big room planning as well as in between.
Agile is a hot topic right now, every company in the world wants to be fast and nimble and being prepared for "disruption". But agile is not always a silver bullet; it has its time and place. But when a lot of uncertainty and constant change is involved, when development and innovation go hand in hand, it really can shine. And I believe there are a few areas in LEGO we can still apply agile with good results so we will keep nudging and experimenting.
Also, I have learned to appreciate the term "don’t get ready, get started". I have previously been a little hesitant and wanting to prepare pretty well, but I truly believe that if the people in the organisation are curious enough about giving agile a try, just jump into it. Get help from some experienced people to get started, but trust that the built-in feedback loops and quick iterations will make you learn really fast. It’s a bit like when a kid pedals a bike for the first time - initially it will be a shaky ride but quickly the turning wheels will balance the bike and the kid feels in control, speeds up further and the journey begins.
