Using Lego to show the advantages of an Agile approach to software development
Zone’s client production director, Toby Dykes, demonstrates the benefits of Agile using two teams of wannabe designers, a village lacking infrastructure and a whole bunch of Lego…
Introduction
There are many reasons to adopt an Agile approach to a software development project, but perhaps the most fundamental of these is the extent to which the risk of the initiative can be reduced. Ironically, within agencies, this is often a factor which is overlooked during the sales process. I assume this is because it feels inherently safer to agree upfront precisely what will (in theory) be delivered at the end of the project. And it is assumed that clients will take comfort in the fact that they are promised a document detailing exactly what they want. Except the inconvenient truths are that:
a) what they want might not be what they need
b) what they want might not be the most efficient nor cost-effective solution to meet their need
c) what they want might not be achievable within the available time and budget.
I took the opportunity to attempt to practically demonstrate this during this year’s Zone agency day, part of which consists of a series of masterclasses on a range of topics. I split my class into two teams of seven and informed them that I would be adopting the role of mayor of a village which had plenty of citizens, but no infrastructure. The teams’ job was to design and build a village for my people over the next 90 minutes. We would build the village twice — first via a Waterfall approach and then by adopting Agile principles.
Waterfall
I volunteered a member of each team to be their business analyst, who would ask me for my requirements. These were fairly straightforward solutions to my village’s lack of infrastructure:
· Red houses with pitched roofs
· A playground with a slide and a swing
· A school
· A shop
· A road network for my people to use to get between the facilities
I then asked each team to spend five minutes designing the village and I would award the contract to the team who produced my favourite design. As they knew there was a competitive element to the exercise, they tried to wow me with the detail and complexity of their creative visions.
Once I’d chosen my favourite I informed the teams that they had both been awarded the contract and would set to work immediately to deliver against this winning design. They would have 20 minutes to build the village, followed by five minutes of user acceptance testing and mayoral feedback, with a further five minutes to resolve any issues which cropped up during the testing process. Only then did I let the teams know the material my village would be built from, as I tipped a pile of Lego on to each of their desks. The teams set to work and built some reasonably impressive structures, albeit the wrong colour and without the requisite pitched roofs.
After 20 minutes when it came to the user testing period I introduced the teams to their users… Duplo people, who — to the uninitiated — are about twice the size of Lego people. This meant they couldn’t fit inside the houses. I also gave the teams some constructive feedback highlighting where they had failed to meet my requirements and wasn’t interested in their excuses (“But we haven’t got enough red bricks!” “You can’t build a swing out of Lego!”).
What followed was a frantic five minutes where the teams attempted to rebuild the (larger) houses from scratch and widen the roads to allow the cars to fit on them, while generally start arguing with each other and me.
It was exactly what I wanted to happen. In fact, better than that, I heard one of the team members mutter to herself: “I’m just so angry…” I asked her to elaborate and she said that the brief was wrong and that they would have designed things completely differently if they’d known the materials they’d be required to build with.
Many of you will by now have recognised that the Lego bricks represented the technologists’ knowledge in the world of software engineering. And this process had demonstrated that, unless we (at the very least) get the developers and testers involved from the outset in shaping the solution, the build process can only be incredibly inefficient.
Agile
I then gave a very brief introduction to Agile and told the teams we would start again, but with three crucial differences. First, I would state my requirements as objectives rather than solutions; second, I wouldn’t ask them to create an elaborate design, but trust them to design the solution as it was being built; and finally, we would split the building of the village into five short ‘sprints’ with user acceptance testing and mayoral feedback occurring briefly at the end of each sprint.
My objectives were:
· I want my villagers to have somewhere where they can be safe, dry and have an element of privacy
· I want somewhere for the children to play
· I want somewhere for the children to learn
· I want somewhere for my villagers to buy things
· I want a network for my villagers to use to get between the facilities
This time I gave the team Duplo bricks and after five minutes they had again built some impressive structures. Team A had built a reasonably large house, whereas the objective-based requirements appeared to have encouraged Team B to be less constrained by convention as they had opted for a large communal space. I then introduced the teams to their users who were (relatively smaller) Lego figures. Team A realised that they no longer needed to create such large houses. Team B also realised they didn’t require such a significant building, but I informed them that there was a more significant problem — my villagers were safe and dry, but had no privacy whatsoever. They had failed. But… they had failed early and still had four sprints of five minutes to rectify the situation.
Team A spent the next sprint confidently creating smaller houses, which they now knew were fit for purpose, and these stood proudly next to the initial larger house which was also fit for purpose, if a little roomy (but perhaps ideal for a mayor?). Team B, however, immediately demolished their commune and started building smaller houses for the villagers.
The next demonstration was much more successful, with the teams taking the opportunity to ask me about potential features (“We can make doors if you need them?”) rather than verifying the dwellings’ legitimacy. During the subsequent sprint they were able to move on to my other objectives, again adopting an approach of delivering something they thought might be viable, in the knowledge that they could check this with me in a few minutes’ time.
Perhaps the best example here was the children’s play area. Instead of building the technically complex slide, they simply put a pile of bricks in a designated area and asked me if that would meet my objective of ‘somewhere for the children to play’. As a dad I knew that my kids would be just as happy chucking themselves off things, as sliding gracefully down things, so I readily approved this concept. The team had saved themselves a considerable amount of time here. Equally, I had allowed them to do so, by not prescribing the solution, but instead trusting them to efficiently provide a solution to my objective based on their knowledge of the materials to be used.
Now, I know that sounds like I’m attributing far too much significance to a team putting a pile of plastic bricks on a desk. But, in software engineering, when we work towards prescribed requirements, we encounter the three fundamental problems I highlighted in my introduction. The first is that the prescribed solution might not meet the wider objective (would the kids even like the slide? Or would it merely represent an adult’s interpretation of what fun looked like?); the second is that the prescribed solution is unlikely to be the most efficient approach to delivering against the underlying objective (compared with blocks, swings and slides are difficult to build and not much more fun than blocks); and finally, we set an expectation that the prescribed solutions will (and indeed can) be delivered in their entirety, when that might not be the case (just because a swing could be drawn during the design phase, did that mean it could be built with Lego in the time allowed? In truth this no longer mattered, as my mayoral expectation had been set and only a swing would do, regardless of whether the children would like it).
Focusing on the objectives
If we release ourselves from the burden of delivering against precise requirements and instead focus on the underlying objectives, we can deliver a first viable iteration of a solution (say 20% of the intended solution) and check to see the extent to which is meets the objective. If this 20% of a solution meets, say, 90% of the objective, then the remaining 80% of the solution (which reaps merely the remaining 10% of the objective) is likely to become a lower priority and we can move on to something else more important. And if the 20% of the solution meets 0% of the objective, then we have got an extremely valuable early indication that the intended solution might be based on a false premise and we either need to revisit this premise or move on to something else.
It’s also important to note that a by-product of this approach is that we are encouraged to question why particular features and functionality are requested. All too often functionality is requested because it exists within the legacy solution (have we checked if customers actually like and use it? If they do, can we improve on it?), or as vanity projects because it is something someone is personally fond of, but doesn’t meet a user need.
In Team A’s case — in my mayoral opinion — they had reaped about 90% of the objective with their pile of bricks, as I know that when a slide is available in a playground my kids go down it twice before going back to chucking themselves off things. So they then moved on to building the school and drawing a road network, which was wide enough for the Lego cars they now had regular access to for testing purposes. They even built a cycle track out of chop-sticks (lunch had arrived) and felt comfortable asking me if their slightly leftfield solution was suitable. In fact, the demonstrations became relaxed, enjoyable sessions where we all exchanged ideas and opinions. And Team B weren’t far behind, building a village which, while not complete, was habitable and therefore delivering value to me from the second sprint onwards.
The whole process went pretty much as I had hoped. OK, during the Waterfall phase I had purposely stated requirements that I knew the teams would struggle to deliver with Lego, including distinctly un-bricky concepts such as pitched roofs, a slide and the technically impossible swing. But what I hadn’t anticipated was that the final Agile village would look much more like the Waterfall village’s creative design than the final Waterfall village itself, which, frankly, was a shambles.
Conclusion
At the outset I wasn’t quite sure what lessons we would learn from the exercise, but the most important distinctions between the two approaches were the length of iterations and the difference between prescribing requirements and setting objectives.
The iterations involved in the Agile approach were clearly an improvement, but mainly because of the shortened feedback loops from the users and mayor, which allowed the team to validate their solution (or fail and adapt/pivot) early. Short iterations seem like such on obvious improvement that many software engineering projects are adopting this approach. Some even call themselves ‘Agile’ simply because they work in iterations. But, without contractually providing the team with the relative freedom of working against objectives rather than prescriptive requirements, the feedback provided will be based upon the extent to which the team have met a prescribed solution. This is of course unlikely to be a technically efficient solution and we will only find out if it’s a success right at the end, which sounds pretty risky to me.
