The Lego4Scrum is an intensive simulation of Scrum, which starts with an empty backlog and ends with a city built of Lego. The team spends time with a Product Owner, building and estimating a backlog and then they have four sprints to deliver their city. I’m not going to cover the basics of the game here — that’s done very well elsewhere. In this post, I’ll talk about some of the customisations we made when we ran the game for one of our non-tech teams.
Here at ASOS, Joanne Whalley has already been working with our Brand Experience team to help them understand and adopt some of the Agile practices that we use so well to build, run and maintain our site. She introduced me to the team and we decided to collaborate on the game together — she’d play the Product Owner and I’d be the Scrum Master.
After we’d completed the game and a follow-up Q&A session with the BX Creative Managers, we were asked to run it again with their leadership team (which would include one of the ASOS Execs). The aim of this new session would be to foster a better understanding and get their blessing on using some of their learnings in some upcoming big campaigns. For this, they were interested in drawing out four key takeaways:
Out-of-the-box, the game doesn’t cover all of these takeaways, so we made some special customisations.
Short feedback loops
The BX team were keen to encourage faster and more regular feedback across the array of stakeholders they have involved in campaigns, while also placing greater emphasis on a ‘Product Owner’ to be accountable for the ultimate decision.
The benefits of getting feedback quickly is inherently built into the game and, in all the times I’ve facilitated the game (probably more than 20 times now), no team has failed to understand this by the start of the third sprint. Two sprints of failure really drive the point home. If you don’t know what your Product Owner wants, you won’t be able to deliver it. The best way to deliver what your Product Owner wants is to talk to them, ask questions, show them what you’ve built, get feedback and respond to it… and do it constantly!
What is an MVP?
Previously, the BX team had struggled with prioritising all the work involved in campaigns, working out what was critical and considering the concept of having more than one ‘release’ of value. The concept of an MVP can better help them to scrutinise the value of each ‘requirement’ and to give them a better chance of delivering what is needed by the inevitable campaign go-live deadline.
As part of the introduction, we talked to the teams about what an MVP is and how the concept could provide value to them and they could learn from using it. In our case, this was a few houses and roads — enough for people to start to move in to our city. In the backlog building stage, Joanne presented the MVP to the team and we used a Product Canvas to help them understand what they were building and why.
By including the MVP and prioritisation in the two-hour session we knew we were going to be limited on time. To free some up, we decided to shorten the backlog preparation stage by supplying some written requirements for building, which would provide some basic information on size, colour etc, but still allow the Product Owners some flexibility.
Estimating is another part of the game that new teams always struggle with, so we made this easier by providing a baseline of 5pts for the first two-storey house and including this on the requirements cards. We laminated the cards so the teams could move them around on their scrum boards and coloured the headers red or green to indicate whether they were part of the original MVP or not.
Iterative development & incremental delivery
Iterative development is incorporated into the game already. As teams build their city they’re able to get feedback from their Product Owner, respond to it and solicit further feedback, iterating until they have something that can be accepted. This often goes hand in hand with having short feedback loops. Without the fast feedback they’re not able to iterate over the buildings.
In order to help the team understand why incremental delivery was a good thing, we gave each building a monetary value. At the end of each sprint, if a building was on the map and accepted by Joanne, it would earn money. A two-storey house that was worth £50 would earn £200 in total, if it was on the map for each of the four sprints.
At the end of each sprint, we calculated the value of all the accepted buildings and updated a wall chart. Once the teams started to deliver, they could quickly see buildings generating money for them.
The BX team gained a better understanding of how iterative development cycles could help them better manage workloads for their campaigns. They also saw the value of getting stuff out the door early then incrementally delivering more to our customers and to ASOS.
Timeboxes and focus
The way that the team currently works is that each team member will work on a project for a certain amount of time, complete their tasks and then move on to another project, only to return to it later. Team members will juggle multiple projects at the same time and have different ‘priorities’ among the many people involved. The team were interested in showing the benefits of having a dedicated team that worked together and focused on getting specific items completed before moving on to the next — exactly like we do with sprints.
The BX team experienced how, as a result, there was a continuous flow of completed work and there was the ability for a lot of group problem-solving during the sprints. They appreciated that the lack of availability/time of an individual would have massively slowed them down and likely caused re-work.
Summary
This specially customised Lego4Scrum session allowed these four key takeaways to land and for a healthy final discussion and Q&A about what they could do to implement these principles and practices in their day-to-day work. Joanne talks about how the BX team have started to do this here.
At ASOS, we run the Lego4Scrum game roughly once a month as part of our Tech Develops and Academy initiatives. From these open sessions, we’ve had a lot of requests to run bespoke sessions for non-tech teams who work closely with parts of the tech organisation. Being able to work with and customise the game for the non-tech teams was a really useful insight into the way these teams work — it appears they have a completely different set of problems, but in reality they’re very similar!
The Brand Experience session was so successful that we’re running it again (three more times!) with our Retail team at the end of May.
This post was co-authored with by Joanne Whalley.
Doug Idle is a Principal Delivery Lead at Dunelm. When he’s not delivering awesomeness, he spends his time listening to Guns ’N’ Roses and rocking stages with his Velvet Revolver tribute band.
