Scaling Agile @ Lego – our journey so far (slides from LeanTribe keynote)

UPDATE Dec 2016: Wrote an article about LEGO’s agile journey, see here. Includes all of the material below, plus explanations and updates.

Here are the slides for my Lean Tribe keynote Scaling Agile @ Lego – our journey so far.

Here’s also a more detailed version from a talk that Lars Roost and I did at GOTO conference in Copenhagen: is SAFe Evil (that talk was also recorded).

This is just a brief snapshot of a journey in progress, not a journey completed 🙂

Sample slides below.

This doesn't scale


Plan on a cadence, release on demand

Screen Shot 2015-10-28 at 12.55.42

SAFe Program Board (scaled agile framework)



6 responses on “Scaling Agile @ Lego – our journey so far (slides from LeanTribe keynote)

  1. Hi Chris,

    Thanks a lot for sharing 😉

    What differences do you make between:
    – Epic (from Portfolio, Business Case)
    – Feature (Program , Release)
    – and Story (Scrum team, Testable)

    Is it only a question of Story grooming (Epic > Feature > Story)?


  2. Great case study, thanks for sharing.
    I especially like the improvements on the classic PI Planning guidance – like running fair style plan reviews. Kind of aligns with some of the things I’ve been trying as well – see for example.

    One specific suggestion – I actually find the vote of confidence can be pretty useful. What I do is use a constellation-like exercise where I ask the entire group to spread in the room according to their confidence level (e.g. closer to the back low confidence, towards the front high confidence). Then can have some discussions around that, and maybe even go to a mini-open-space to discuss the main challenges. At a minimum, constellations exercise gets people moving a bit which is always good.

    Question – Any thoughts about the timebox for PI Planning? Did people feel 2 days was the right timebox? Any pressure/ability to shorten it? (Which is a typical concern I hear from teams, and some are able to go to 1-day PI planning if they work to reduce dependencies and do reasonable preparation up front).

  3. Hi Yuval (this is funny as I’m sitting less than 2m from you)

    There is regularly pressure to reduce PI Planning to 1 day. This train in fact briefly suggested exactly that first time around.

    The real world experience, even with short PIs and small programs, is that

    1) It’s hard to come to a sound consensus-based plan in 1 breakout

    2) Many ART members come back after a night’s sleep and subconscious working on it with profoundly better ideas and ability to work together.

    1. After 1.5 years of doing 2-day PI plannings, we tried a 1 day version a few months ago. Just about everyone involved agreed that this works much better, so we’ve been doing 1 day PI plannings since then. The 2nd day was always low energy, so we don’t miss it. But we think the 2 day version was necessary for a period, as a stepping stone until we could get good enough at it to get done in a day. The planning is still 2 “iterations”, but the iterations are half-day instead of full-day.

      Just wrote about it here:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.