The Lego Test: An unscientific scientific experiment
At Nordnet we have noticed that when we work on a problem with everyone that is needed to solve the problem (engineers, research, design, business and more) at the same time then great things start to happen almost immedietaly. We get a sense that:
- We solve problems quicker
- We are happier at work
- We produce results with a higher quality (fewer bugs)
Some people call this way of working mob programming, some call it eXtreme programming, some agile, and others call it just work.
But whatever you choose to call it is not important, what’s important is to let design, new ideas, requirements, quality assurance emerge as we are actively trying to solve the problem. In contrast to trying to approach the problem in a deterministic way by writing detailed plans, conducting design phases, and handing off the work to the QA team in the end.
Making a plan vs. no plan
We have a gut feeling that we are quicker and happier when work happens as we go, but we have never really been able to figure out what the differences are to the more planned approach. Is it less stressful, if so why? Is the quality really better? Are we happier?
To find this out we decided to conduct an experiment. Our idea was to split into two different teams (a real life A/B test), both of which would be tasked with building a tower made out of Lego. One group had to write a detailed plan while the other group could build as they go. The experience from building, designing, and of course how the towers would look like would then be able to help us see what the differences are.
Both teams had the same task (to build a tower) but they had to approach it differently:
The traditional-project-team:
- Specify the requirements for the Lego tower for the next team
- Build the tower according to the requirements from the other team
- Conduct a quality assurance phase
The build-as-you-go-team:
- Design, build, and test at the same time
Now we knew what to test and how, we were just missing the participants.
The bricks started to fly
On one chilly Stockholm afternoon we had invited Woody Zuill[1] to come and talk with us about mob programming. About 50 eager engineers and practictioners showed up, all from other companies around Stockholm.
This was the perfect setting for trying out our experiment! First Woody Zuill held a presentation on communication and collaboration, and after that everyone that wanted to got the chance to participate in the Lego building.
After we had divided them into teams and given them the instructions then they were all eager to start. The bricks started to fly into place from left and right for the build-as-you-go-team team.
In contrast, the traditional-project-team, that much like the decision makers do at a company gathered in a dimly lit conference room, where they isolated themselves from the rest of the world. There they sharpened their pencils, and started to write down the requirements for their ultimate Lego tower.
The team that had to write the requirements knew that they were going to have to hand over requirements to another team that then would have to do the building. It was noticeable that this was a fun phase, everyone’s plans of a dream tower came to light and they were allowed to write down any design that they would want.
The only problem was that another team would have to make the dream come to life. This is an insight from one of the team members when writing the requirements:
You start off trying to be nice to the builders, but quite quickly we all just went screw it: lets make the tower as impressive as possible!
In a way it’s only natural, you only get this one shot at designing the perfect solution so you’d better make it count. If it is trivial or challenging to build is something that you don’t know, that is up to the next team to figure out.
While the traditional-project-team was busy writing requirements the build-as-you-go-team had already started to build their tower.
Now it was time to pass off the requirements to the team that were going to build and also to receive the requirements from the other team. Now the team that once were the decision makers had to start building. Time was short and expectations were high.
Instantly they tried to make sense of the requirements from the other team, quickly questions started to rise: It says 5 windows here, but where should they be placed? One pond, how does a Lego pond look like? 50 bricks for a bed, that’s a lot.
But there was no time to try to make sense of it it all, instead they just had to start building and try to follow the instructions to the best of their abilities. Plus the team that had written the requirements were now busy with other things.
One thing that they quickly found out was that it was a stressful and challenging experience to try to achieve what was specified in the requirements. While at the same time the build-as-you-go-team could just continue to carefully place one brick at a time.
How the towers turned out
As you might imagine the tower made by the emergent team was undoubtedly better. But not only was the tower better but also their experience.
The team had managed to build the tower without feeling any pressure or stress, the team members were happier, and they were able to be creative in the moment, tweaking and adjusting as they went along.
As you can see in the image above the difference is definitely visible. However the traditional-project-team managed to deliver what was expected of them in the requirements, there was a “tower” made out of 25 bricks, there was a big yellow bed, and there was a pond although a very tiny one (one blue brick).
While the build-as-you-go-team managed to also build a tower but it was much bigger. There was not only a pond, but a pool with a trampoline, a fish statue, a balcony, trees, and so much more.
What did we learn?
So what learnings can we take with us into creating software from building Lego? Well in all honesty the two of them does not have that much in common, but one thing that they do share are that they are both creative processes.
In creative processes, creativity usually happens when you are actually performing the work. So it was difficult for the traditional-project-team to be creative when building from a requirements list because someone had already tried to be creative for them in the design phase. Much like it was difficult for them in the design phase to understand what would be trivial or challening to build.
The build-as-you-go-team never faced these challenges because creativity could happen for them in the moment. They could build, test, and discuss what the best solution would be with basically no waiting time at all.
Therefore, let’s embrace the build-as-you-go-team’s tactic and just start building things together, that way we will: solve problems quicker, be happier at work, and produce better results.
