Product Development – How we use Lego at ELEMENT Insurance to learn more about how we work
One of the questions I love asking people during job interviews is what they consider to be the best thing about their current working process? What is something they are proud of doing and would share with ELEMENT once they join? There are also a number of practices at ELEMENT Insurance that I would take with me one day. The following practice is using Lego bricks to visualise our workstream, getting a reliable and valuable source of data about how we perform as a team.
A bit of backstory. Once I was commuting home reflecting on how that day had gone. I easily recalled all the boring stuff, and urgent ad-hoc requests that had come in. I was frustrated and questioning my existence. This type of day may sound familiar to you. Next morning, during the retro I found out that I was not the only person frustrated about this. One of the developers brought up having a feeling that this sprint we had spent too much time fixing bugs and doing (and redoing) what we had been approached with ad-hoc. Also worth mentioning that another widely held belief in our team during that time was that we were spending too much time in meetings. These facts became a sufficient reinforcement for us to acknowledge that there might be a productivity issue. And fixing it first required getting more objective data about where we were standing and where we wanted to go. Unfortunately, “having a feeling” is not the best category and is pretty tricky to measure, so we needed to come up with a viable framework of collecting and visualising our workstream to uncover the source of the problem and target it effectively.
But there is one thing about it. Measuring how much time we were spending doing different types of work smelled a lot like micro managing. And this smell is not of the kind, you know, they use to lure people into good stuff with. Besides, avoiding this is one of the reasons we are doing no-estimate estimates, OKRs, theme-based roadmaps and other awesome hype working goodness.
Our agile coach, being part of the discussion, did research and suggested using Lego bricks for this purpose. The idea is based on Joe Wright’s experience as well as the earlier practice of Michael Hunger, vintage 2008 .
So how is this supposed to work? Each Lego brick represents an hour of work of one person. A shiny golden person-hour. The colour-coding we are using is:
- Green for planned work
- Orange for ad-hoc demand
- Blue for meetings (yay!)
- Red for failure demand
- Black for maintenance
- Grey for administrative stuff.
Let’s get into more details.
Planned work is something you actually planned to work on. It’s aligned with your goals, refined, planned, went into the sprint (we’re doing Scrum at ELEMENT), and is being worked at. Perfect.
Ad-hoc is almost like the planned work, but without actually planning it. It occurs when someone approaches you and asks to do this as soon as possible, just this tiny thingy, and “it is not going to take you long”. Except for off-boarding from what you are doing now, on-boarding with the new task, doing the actual work, testing, deployment, and then back in a reversed order. It mostly is even aligned with your goals, and you see value in it. But the whole way of handling it may be disturbing and demotivating.
Meetings. Self-descriptive. We all love them.
Failure demand is the type of work that occurs in two cases:
- When the team failed to do things right. As a result, the tests are failing, monitoring dashboard goes red, a bug is filed in JIRA and so on.
- When the team failed to do the right things. In this case, the feature is there, but it is not what was requested or expected in the first place. So, it has to be redone. Side note: this has nothing to do with product experiments, A/B testing and normal iterative product development.
Maintenance is targeting tech debt, refactoring, and getting the systems up-to-date.
Admin tasks are everything else: recruiting, onboarding, offboarding, organisational stuff, pre-planned learning, compliance (we are an insurance company in the end!).
And here is what we do with it. Twice a day, before lunch and before the end of the working day each team member puts their hands into the Lego box and fishes out the bricks that represent how they have spent the last few hours. Our experience suggests that twice a day is optimal. If you do it rarer, then people tend to forget and fall into the fallacy of remembering things with a more significant emotional impact (i.e. failure, meetings and ad-hoc becomes overrepresented).
At the end of the day each of the team would usually get something like this:
Next day during the daily stand-up, while sharing what was done the day before, each team member shows their Lego bricks, and puts them on the team’s sprint board (we run two-week sprints), according to the colour-coded categories. Each row on a board across all categories is a day of work. Full board — one full sprint.
We start every retrospective, which in our case happens biweekly, with taking a look at the Lego board and discussing the perceived and actual distribution of the time spent. Afterwards, the data is digitised in a format, convenient for further longer-term analysis—a smart reference for “we put it in a spreadsheet”. This analysis is yet to be done, though. One of the assumptions we want to test is whether a correlation between different categories of work exists. E.g. fewer meetings or maintenance causes more failure demand.
After the retro, the bricks go back into the Lego box until the next sprint starts.
We began visualising our workstream with Lego bricks about a year ago. And it took no more than a couple of sprints for it to start providing us with valuable insights on the distribution of the team’s work. Having been following the process since then, we learned that:
- More than 60% of the work we do is planned. We are good.
- About 25% of the time is spent in meetings. Which seems a lot. But actually, is it? And what would be a “good” proportion of meetings? These are the questions we asked ourselves and have not found the answer yet. We also had a chance to try several approaches to limit the number of meetings, and Lego bricks provided us with benchmark data to evaluate the effect they had.
- Some team members have and cause more meetings than others. And when the product owner goes on vacation — the number of meetings goes down. Being a product owner myself, I assume and hope that it is a short-term effect. I am of course ready to sacrifice my time into testing this idea by going on an extended paid vacation. Just out of scientific curiosity, of course.
- The amount of the ad-hoc tasks in our case is not that high—slightly over 2%. Although the perceived impact is still significant, we now have credible, objective data to refer to, which has improved the team morale. Data is king!
Apart from the direct learning, we have also proved that building the Lego towers is a viable and easy way to monitor our workstream distribution over time. It also helps us to facilitate and structure standups and provides graphic visual cues for the retros and plannings. Besides, being fun, it became a part of our daily routine, and I would say, a part of our team culture without any friction.
Author: Anton Kovnir, Product Owner, ELEMENT Insurance