Introduction
My organization wanted to help employees understand the value of the IDesign Method(both the System Design, aka architecture, and the Project Design). To that end we ran a team-building exercise involving Legos.
We broke into small groups (3-4 people each) and assigned each group a Lego kit. The twist: no instructions, not even the box. The only advantage people had is that Legos come in bags, and by looking at each bag’s contents, you may get some hint as to what you’re building.
In the Beginning, There was Chaos, aka Emergent Design
At this point we told the teams to “perform your day-to-day activities–build a mode of transportation. The customer is not exactly sure what it will look like–but they will know it when they see it.” In our case we used Lego City sets, but you could use anything. Our sets were about 200 pieces each, except for a larger 300-piece “Mega Kit” set given to me.
Imagine for a moment how bad this could look:
Now I imagine you’re in one of two camps:
The “you gotta be kidding me” camp
The “let’s do this” camp
And yes, I’m aware of concerns that instructions kill creativity. In fact, Lego shares those concerns and created Architecture Studio. No instructions, pure creativity. I’ll touch on creativity later. For now let’s focus on delivering value.
The teams began assembling Legos, but without any idea what they were building, they floundered. And this is exactly what happens when you expect “emergent design”–people flounder for awhile, thinking of all kinds of ways they can put the pieces together, and making lots of mistakes.
Enter The Architecture
At this point many people voiced some frustration, and we moved to the next stage: “We have held a series of meetings with the customer, revised the requirements, and designed the architecture of the system.” We allowed each team to see the Lego box for their project at this stage, but only the box, not the instructions within.
Good news: Now we could tell the difference between this:
And this:
But still. An architecture only takes you so far, as we’ll see.
Now the teams were able to move faster, and make some progress, but it was limited. It’s not easy to assemble Legos with just a few photos.
The Mythical Man-Month and Context Switching: Two Productivity Killers
We didn’t give them long before the next stage: “per upper management direction, the Mega Kit project–which the company’s future depends upon–needs your assistance. Everyone please report to that project and be prepared to assist.” At which point everyone came over to my table, and it was impossible to put everyone to useful work (though I tried).
This very nicely demonstrated the fallacy of the Mythical Man-Month, aka the Nine Women One Month One Baby problem, aka the Too Many Cooks In The Kitchen problem. Everyone could see that we could only use a certain number of people. Yet this same fallacy is exactly what you get in a typical Agile team based around capacity-driven planning. You force the team to figure out dependencies and attempt to parallelize in inefficient ways.
Having easily proved our point, we moved on: “Progress on the daily activities has stopped, and the customers are not happy.” Here we had most of the people return to their projects, though I was able to keep a few people; I selected those who were already getting underway, despite having no instructions. Everyone else went back to their original projects.
By the way, the above swapping of resources in and out affects both effectiveness and morale. Organizations need to be cognizant of these facts, and make sure people understand why they are being reassigned. Put another way, context switching is costly!
My Kingdom for a Set of Instructions, aka Project Design
Shortly after, we moved to the next stage: “A project plan has been developed. Each team may open their boxes and use the instructions contained within.” This obviously is where people really accelerated, and this is what proved to many people the value of project design. You can’t simply throw a project, even with a good architecture, at a development team and expect them to build it. The different activities must be considered and the dependencies teased out, which is what project design is all about. What Agile team is going to figure out all of this in the short iteration/sprint/PSI/PI planning they do?
From there, I got some more assistance, so that I could pipeline my own part of the project, while the others continued on theirs. Legos are nice in that you can sort pieces, have one person read instructions and ready pieces while another actually assembles them, etc.
Kind of like Kanban, BTW, though you must be careful within an activity: you can have an architect or senior developer write docs for another to implement, or have one write unit tests for another’s implementation, and of course QA testing follows implementation, but when you get into two people sharing implementation in the same area, efficiency diminishes.
A Quick Agile vs. Waterfall vs. IDesign Method Aside
BTW for you folks who think that Waterfall is everything that doesn’t smell like the Agile you were taught: did you realize that a specific Agile User Story, Activity, or Task, if it can be considered complete (includes docs, integration, and testing), is a mini-Waterfall? Waterfall is good on a small scale. I would add that Agile is good on a bit larger scale, and that a disciplined engineering approach like the IDesign Method is good to wrap things up at a still larger scale.
Interrupts and Blocking: Life Intrudes
We also did some things to interrupt people–such as giving each team a little side Lego project to do, because real life includes interrupts. We also blocked up a few ways, either because a parallel path of the project got stuck waiting on another part, or because our “helpful” project manager stole handfuls of Legos until teams put out Post-It notes to indicate they were blocked.
Professionals Persevere
Before too much longer, we all finished our projects. We ran through a round of QA to make sure everything was in order (and fixing a few issues found during the inspections), and completed the exercise.
But Software Isn’t Like Legos: Plans Change
Agile folks are prone to mentioning that software is different. Requirements change, and therefore plans are useless. They quote “No Battle Plan Survives Contact With the Enemy.” (The quoted web site is terrific in that it contains this follow-up, BTW.) And I’ll admit, we didn’t perfectly capture this in the activity, though the theft of Legos came close.
The thing to realize is that plans must have options. They must be adaptable. And in fact this is what we do with project design. We create options, and we can readily switch, say from one with n developers to n+1 or n-1. So if a developer is lost or added (note that you must be careful about adding developers, as already mentioned!), you can account for that. If a requirements change comes in, you can plan for it. Every change that comes in actually strengthens your project design (up to a point; team morale can only absorb a few changes in a given project).
Reflections
The Lego exercise was simple, yet profoundly visceral–when we reflected on it later, people could readily understand the value of architecture and project design, and relate it back to Legos. The metaphor is simple, but quite powerful, and gave everyone a common ground for discussion as we moved into talking about the System Design and Project Design aspects of the IDesign Method. More impressively, all this was possible in about an hour and a half.
Here are a few more reasons why we believe this was a good idea:
- People in the organization keep referring to the exercise. It was that relatable, even for people who might otherwise believe they aren’t impacted by any of this.
- See the photo above? Folks dedicated two shelves to the outcome of this project!
- I wouldn’t have written this blog posting if I didn’t believe it myself.
A Place for Creativity
Now about creativity, as promised. This is important because it’s easy to assume that all design responsibility has been centralized in the architect and project designer, and this is false.
As an organization, you don’t want to discourage creativity. At the same time you value cohesiveness and delivery over most everything else. So consider that the architects and project designers must employ a certain amount of creativity to design a system and the set of plans that could build it. But also consider that the developers and testers still need creativity. In fact, now instead of having the burden of the entire project on them, they are freed to think creatively in their own areas and domains, where their expertise is. In the Lego metaphor, they are figuring out some of the details like color of pieces, differently shaped pieces, etc., while still adhering to a high-level plan. In other words, they’re doing detailed design, to the degree applicable (typically, more for senior and lead developers than for juniors). And they’re free to question the architecture and project design if and where they don’t make sense, because nobody is perfect.
Conclusion
I wanted to share this story in the hopes that it would help others. Some of you may want to try this for team-building purposes. Others of you may want to see if you can get management to try this exercise, or else to explain the IDesign concepts using this metaphor.