Large-Scale Scrum simulation with LEGO Bricks #lego4scrum #less

This simulation is a scaled variant of the famous #lego4scrum that is well-described in the recently self-published book:

Below is my attempt of describing the way I teach and demonstrate the principles behind the Large-Scale Scrum with lego4scrum - that is the most fun, playful and interactive way of teaching Scrum that I've found.

This year (2017) I'm planning to run this workshop at plenty of conferences (like Agile Eastern Europe, Agile Riga, Agile Prague, XP Days Benelux - so catch me, if you can!)

This is Serious Stuff!

Though it all looks like plain fun, we get to discuss some serious topics. Majority of which the participants are also able to experience.

On small-scale lego4scrum workshops (15-25 people) that I do a lot one can dive into details like user story mapping, magical team estimates, splitting user stories and things like this. (Check out the newest facilitators guide, if interested).

This scaled workshop is different. We are letting participants experience the power of Scrum at the organizational level. So we are discussing some relatively high system-level concepts.

Scaling #lego4scrum

So far I've been running this simulation with groups of 70-120 people at conferences and also in-house. With this many people you get 12 to 22 development teams. This is a lot of people for a workshop.

And all of them are working together on a common product vision, within a single sprint, shipping one integrated Product Increment based on the overall Product Backlog.

That's impressive, isn't it?

Well, the only limit is how much LEGO one can bring. Well, in fact I've seemed to figure out a way how to remove this constraint. I've made the teams "buy" the materials with LEGO money - and you won't believe it - when people have to buy something they (surprise! surprise!) tend to be much more thoughtful and careful with the resources.

So the only real limit is how many people are coming to the workshop! That's why I'm writing this post as I'd like to experience it with 200 people and more! It will scale with the same principles that are already in.

But wait! How do I facilitate it? How big is the army of my facilitators? How many people need to be LeSS-trained beforehand?

- Zero!

And what's the trick then?

- The trick is in applying the LeSS principles and letting the system contain and manage its complexity. Simple as that.

So first, it is important to explain the underlying principles of the organizational design. This is the hardest part of the workshop as it has to be short and sweet.

Yes, LeSS is about simplifying the system rather than managing it. It is about doing more with less.

Chaos, Complexity and Self-Management

The system (our organization) will still be overloaded with its inherent complexity (markets, user needs, technology, people, compliance requirements and so on) but at least the added complexity will be minimized (process roles, hierarchical layers, procedures and policies, dependencies, etc.).

So in fact no matter how hard we try simplifying our systems - in the domain of product development we will still be dealing with tons of complexity that can't be really "managed out" but need to be "respected and dealt with".

But that's OK:

As long as we are not trying to manage the system, complexity is not a problem.

That's worth teaching on the workshop.

Mentioning the shades of complexity by Dave Snowden helps too.

As you can see from the photos below, the workshop looks quite chaotic. In fact I warn people that it will be like this!

Chaos is a good sign. It allows self-management to take over.

If you don't believe chaos is a twin-brother of self-management, think of a counter example: a marching army on the road with a sergeant shouting "left!", "left!", "right!"...

How self-managing is that?

Not every kind of chaos is a sign of self-management, though. Some chaos is ... just pure chaos. But here we're talking about controlled chaos. And it is being controlled by the people doing the work. And for this to happen they need to be given several ingredients:

1. Guidance on the direction (or "alignment")
2. Initial working structures (or "containers and constraints")
3. Initial minimalistic process framework to start with (or "power and tools")

The Product and a Product Owner

The participants are given a challenge - they are to build a profitable company with a working product that is satisfying its customers who are apparently interested in travelling:

We have also "done" some market research, so we know how much the customers are roughly willing to pay us for the trips:

The company gets an initial seeding fund of 60 Million LEGO bucks.

Whole Product Focus

Now, these are very important questions. Based on the answers the organizational structure will be formed. And if the structure is suboptimal (i.e. not optimized to deliver the product the customers want) another product Frankenstein will be born. A child of local optimization.

That's why "whole product focus" is a key principle of LeSS.

Product Owner and Area Product Owners

A Product Owner gets selected and is given the business case with more details. If we had 3-7 teams, we would be ready to rock.

But since we are eager to start with "all-in" - meaning all 100+ participants will soon form teams and start working altogether on the single product - we need to find a way to scale product ownership.

[Caution: this is probably not a good idea in the real life to start with too many teams from the very beginning. If I have a choice, I start with just few. Or maybe even one. Later on, once some uncertainty is removed I'd add several teams. Then later few more.

Such a step-by-step incremental adoption is much less risky and is also wiser in many aspects.

But it is worth giving it a try as a simulation and debriefing the "all-in" approach later. This is cheap and fun experiment after all].

So because we are talking about 10 and more teams working together, a single Product Owner will likely need to delegate parts of his work. This is achieved by splitting the product into Requirement Areas and having individual Area Product Owners (APOs) taking care of those. This is known as the LeSS Huge framework.

In the simulation the APOs are given colorful cheap Chinese-made plastic hats to be distinguishable when chaos of building the product rises in the war room. And very soon it will.

Now the Product Owner and his team are coming up with a product strategy and Requirement Area split. They are pitching their ideas to everyone in our entire organization:

Beyond Self-Managing Teams - Self-Designing Teams!

Once the Product Owner Team (the Product Owner with several Area Product Owners) are done with their part (the product strategy and the vision are clear to all), the crowd gets to self-organize to form cross-functional long-living product-focused feature teams.

And this is a big thing! This is done with a self-designing team approach where people get to:

1. Agree on what a great team for this organization is (criteria)
2. Form teams (based on certain criteria)
3. Choose their ScrumMasters
4. Choose their mentors, people managers, line managers, etc (if needed)

Consider the following classification of management/self-management cultures by Richard Hackman from his "Leading Teams" book (I've added my interpretation on top: "pre-agile", "most Scrum teams", "some LeSS adoptions", etc):

Pay attention to "self-managing teams" - formed by managers, and only then are empowered to choose the way they work.

And the "self-designing teams" - when people have freedom to form teams the way they prefer to work with who they like.

As you see, the self-designing teams setup is one step more "extreme" than self-managing teams. That's where we are trying to get with the team self-design workshop.

As my friend Viktor Grgic puts it:

With self-designing teams ownership of setup and therefore process is noticeably higher. This has obvious effect on motivation of the whole group.

One can also claim that the "IKEA Effects" kicks in here - as people tend to feel more ownership and care more for the things they've created themselves. LeSS is a more of DIY-kind-of-framework. That's what I love about it.

Team formation can be facilitated with a method similar to the one described in an article by Craig and Ahmad "How to Form Teams in Large-Scale Scrum? A Story of Self-Designing Teams". So I won't dive into the details here. There is no magic there. Just agree on the constraints (team size, team skills, etc.) and let the people do it.

This is a lot of fun and surprisingly doesn't take a lot of time. Though it is worth noting that this is an iterative process as it might take several inspect-and-adapt loops to make the teams shine.

This way of thinking of team formation is very new to most of the workshop participants. So if for some reason the workshop need to end now - doing this exercise alone teaches a lot.

But wait, there's more!

Managers and LeSS

One key principle that LeSS inherited from Lean is this one:

Job safety, but no role safety.

So we need to consider what to do with the project managers. We might not need this role anymore. But we might definitely benefit from those folks' expertise.

Managers are skilled people forced to do overhead work because the added complexity of the organizations need to be managed (Or so we think of the complexity.) And systems with their inertia disallow people to challenge the status quo. So we stuck in a positive (but frustrating) feedback loop: we always need more managers.

Is there a better way?

Yes, I believe so. And LeSS gives thinking tools for dealing with this:

So at the workshop sometimes I first hire the managers by asking for volunteers with some PMI degrees (I know it is evil). Then we let them go to figure out how to add value without actually doing project management. Remember: no role safety.

We help some of them become Area Product Owners (partially good skill-set), some become general managers to be helping from the outside of the product work (in real organizations we still need someone to sign the bills), but others are allowed to get back to where the most fun of it is - building products! Remember: guaranteed job safety.

No matter where the managers decide to go: nobody should remain as a project manager - as we don't need this role anymore.

That role is obsolete. It is so 20th century.

Initial Backlog Refinement

Now it is the time to do the real work - delight our customers.

The teams group around their Area Product Owners and engage in refining items from the Area Product Backlog. In this simulation a Requirement Area is a specific city (like Paris or Berlin) with all the needed transportation lines and vehicles.

Sprinting

Don't ask me how the participants do this...

At this stage of the simulation I'm out of their way (to make photos for the blog):

Mid-sprint:

Sprint Review

.. to inspect the integrated Product Increment.

On the photo below there is a bus going from London to Paris, hooray! Customers are delighted and pay.

Overall Sprint Retrospective

... to improve the overall system.

Lessons Learned

... for the workshop debrief and "please help me pack the LEGO!" part.

Hey, this is more or less how to run this workshop. Interested to know more?

• Talk to me
• Buy the book
• And invite me to co-facilitate it at your conference or company.

Workshop Slides