At Table XI playing with LEGO is nothing new. In fact, many of us spent the better part of our childhood honing our LEGO craft. As adults our tendency to tinker has led us to build with code, not plastic, but there’s still something satisfying in the familiar click associated with creating something from nothing.
Maybe that’s why LEGO is such a big part of our office culture. Our team has carefully assembled masterpieces over various work retreats and kitchen tables, and we display them in the office.
But for Table XI playing with LEGO bricks has come to represent more than a way to blow off steam or to get to know our colleagues better. As it turns out, building in LEGO is a metaphor for the way we do business. It’s become a valuable teaching tool, and helps to demystify much of what we do.
Case in point: If I tell you that we’re a Ruby on Rails development shop that practices agile methodologies, would that mean anything to you? It may, and that’s great (consider yourself among the 1%), but for the overwhelming majority of our clients and partners it does not. What does agile really mean? And what are the implications?
In software development the only constant is change itself: Clients will change their mind, technology will become outdated, business requirements are re-prioritized. In previous development methods engineers were removed from customers, reliant on documentation, and forced to make many assumptions about the product. This top-down, sequential approach makes it difficult (and expensive) to react to change.
Find a new product in 5 days? Learn how with our free Google Design Sprint ebook.
By contrast, the agile approach was developed as a response to volatility: It plans for change rather than attempt to prevent it. Agile software development depends on short, time-boxed iterations. Small builds and continuous testing ensure that if something doesn’t work properly, or doesn’t meet client requirements, it is easy to course-correct before more time and resources are invested.
Unlike other methodologies, the agile process require close collaboration and constant feedback from the client to be successful. Client input ensures that development decisions are based on business priorities, and that acceptance criteria is met during the development stage, rather than at the end. This feedback ultimately helps get an MVP (Minimum Viable Product) to market faster.
At Table XI we’ve found that the best way to demonstrate the agile process and the complex relationship between the client, the software developer, and the project manager, is to roll up our sleeves and have some fun. We designed a hands-on, collaborative LEGO game that allows participants to experience an agile development project in a short, two hour window.
It goes something like this
Imagine I’m a client in need of your help. I’ve put a box of LEGO bricks in front of you and handed you series of cards. These cards represent “stories” (or feature sets) for my product. It’s up to you and your team of LEGO “developers” to prioritize these features, manage my expectations, and build a product that meets my requirements. You’ll have a short interval of time to deliver the final product.
Inception: Client Briefing
Before we begin you’ll be told all about my business (hint: it involves hover pods, a planet called Alpha, and exists in 2214), and have time to ask questions about my needs and motivations.
IPM
Once you think you understand the project at hand you’ll have an Iteration Planning Meeting (IPM) with your team to review the stories, estimate the amount of effort needed, and tell me what you plan to deliver.
Development
Next you and your team will start the development phase in a short, time-boxed iterations.
Showcase
When time is up we’ll have a showcase in which you can demonstrate the LEGO product and answer questions. As your client I will determine whether or not you’ve met my acceptance criteria, or if it’s time to get back to work.
Retrospective
Following the first iteration we’ll have a brief retrospective. During this phase we will have time as a group to assess what’s going well, what could be improved, and think about how the teams can adjust going forward.
Development (Iteration Two)
Next we begin the process all over again. In the second iteration you will build out the remaining features, and apply the learnings from the first iteration along the way.
We’ve now had the opportunity run the LEGO game as part of Chicago Ideas Week, as a training with teams of developers from Chicago-based Enova, and with more than 150 communications professionals at a Chicago-based PR agency. We’ve learned that no matter what industry, or level of technical proficiency, the agile LEGO game has something to teach any audience.
Participants leave the session with a better understanding of how to work in teams and with clients. Most importantly, they leave having internalized the importance of failing quickly.
Assumptions are costly, and time is of the essence. The Agile Lego Game teaches the importance of building in LEGO, not brick.
