Building innovative software with Lego®

“If you’re not failing every now and again, it’s a sign you’re not doing anything very innovative.”
- Woody Allen

A lot of teams in the IT suffer from not being able to be creative, innovative and/or being allowed to fail. Certainly, there are different approaches on how to deal with these kinds of situations. Also some people might say “Why do you need extra time slots to be creative or innovative?” OR “Be creative and innovative when working on User Stories and delivering value!”
Both statements are totally valid, but are often not reflected in real life. This sucks. I know that.

This article shows how the car2go app development team manages to be creative and innovative by using actual Lego® stones. Therefore, we will explore the starting point and the needs of the team. Also we will look at a past experiment on how to make innovation possible and what the current approach is.

Starting point and needs

The team works with Scrum and has two-week Sprints.
In the past, the scope of the Sprints was pretty much maxed out and left little to no room for experiments and creative headspace. This resulted in so-called “ninja-ing”, which basically meant: developing features, fixing bugs or improving the system in the dark, invisible to others and sneaking them into the Sprint. Like a ninja.

Obviously, the team had the desire and the energy to further the product and their daily work, but felt that this was nowhere to be represented in the planned scope of the Sprint. 
This working mode may be functional for some time, but in the end it caused discontent within the entire Scrum Team.

Clearly, the team needed a setup to let out their creative energy and also have the “official allowance” to work on topic outside of the Sprint scope including researches and other not directly “result-oriented” topics. These topics would then either better the product, themselves and therefore in the end again the product.

Also, the developers wanted to be allowed to try things and find out if something works or not. And they wanted to be sure that it would be okay if things did not work out.

Past experiment

In order to meet the needs presented above the team started the experiment of the “Innovation Friday”. The policies of the Innovation Friday are listed below.

  1. The topic worked on this day had to be product related.
  2. Pair programming was mandatory for the time working on the Innovation Friday topic.
  3. At the end of the day the results created had to be presented to the rest of the team.
  4. The running Sprint must not be endangered. It had to be ensured that scope was still met.
  5. A fixed day of the Sprint was set were developers could make use of the Innovation Friday or not.

There are several reasons why the Innovation Friday experiment did not work out in our context. 
First of all, not every developer feels the need to spend effort on topics that aren’t directly Sprint related. Some developers felt pressured by the fact that it is “Innovation Friday” since they would have preferred to fix bugs or continue the work on a User Story.

Second, the constraints/policies given in this experiment were perceived as too tight. Being product related, doing pair programming and having something presentable after one day seemed a lot to consider and suffocated ideas the developers had and would have wanted to work on. May it be experimenting with a new language, researching about technological developments or testing new features/technologies.

Lastly, the emphasis of not endangering the scope of the Sprint placed a feeling guilt on the developers when they requested to make use of the Innovation Friday. The smell of mistrust was in the air.
Clearly, the needs presented above were not met just yet. The team moved on to the next experiment.

Preconditions for using the Lego® stones

Before diving into details of the Lego® stone experiment, I would want to clearly state what the preconditions are to make the Lego® stones work and use their full potential.

As simple as this may sound, but trust is the most crucial point when it comes to the application of the Lego® stones. I, as the Agile Coach of the team, fully trust the developers to make the best use of the given time. Also, I encourage everybody else within car2go to fully trust the developers that they will make responsible decisions.

By taking the Lego® stones the developers are fully responsible of their usage. They are responsible to make sure they can use the stones if they want. Nobody else will ask them to use or not use the stones. How and when they use the stones is totally up to them. Obviously, the developers are then also responsible to not add too much scope to the Sprint in order to be able to use the Lego® stones.
As a coach, my job is to create an environment that fosters both preconditions and thereby supports the developers to make use of the potential given by the Lego® stones.

How do the Lego® stones work?

  1. At the beginning of every new Sprint each developer is provided with two Lego® stones. Each Lego® stone represents 4 hours of working time. So, two stones equal 8 hours/one working day of the Sprint.
  2. The number of stones a developer can collect are limited to 6 stones = three days. This cap was implemented due to a lack of stones. ;-)
  3. Every developer is fully responsible for the usage of the stones. Being used, not used and what they are used for.
  4. If a developer wants to spend a Lego® stone, he/she will announce the topic in the Daily Stand up.
  5. The topic is written on a sticky note and placed visible for everyone on the Challenges board. Any progress is then also visible.
  6. Depending on how the time was spent, the outcome is presented in whatever format seems appropriate for each case.

In general, the adoption of the Lego® stones works fine since it meets the needs mentioned above. The developers who really want this form of an outlet make good use of it. Some developers do not use Lego® stones regularly or at all, which is fine too.
For some people the given responsibility is a bit of a challenge as they simply forget to use stones. This is something which we need to figure out individually.

Since everything is continuously evolving I am curious to see on where the journey of the Lego® stones is going. I will keep you posted. :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.