How I Practiced Processes in Recent Agile Workshops
During the last 12 months, I participated in three inspiring workshops–I enjoyed all of them:
- The Product Owner Dojo by Catherine Louis and Stefan Haas
- The Lean Change Management Workshop by Jason Little and most recently…
- …the Certified ScrumMaster (CSM) training by Andrea Tomasini of agile42
All of those agile workshops used LEGO® more or less heavily as a training ground to build a “product”, for example, to practice basic Scrum techniques such as organizing and running a sprint.
So, I was building airports…
…and ski resorts:
The above picture is courtesy of agile42.com
I also built a duck — the most memorable artifact in my eyes:
The duck was an amazing experience, given that the six identical pieces provided to each participant never resulted in the same duck being built twice.
The Success of LEGO® Serious Play® as an Educational Tool
I guess this approach has something to do with the huge success surrounding the LEGO® Serious Play® concept, “an innovative process designed to enhance innovation and business performance. Based on research which shows that this kind of hands-on, minds-on learning produces a deeper, more meaningful understanding of the world and its possibilities…”.
LEGO® Serious Play® has gained a lot of traction. There is by now even a certification for facilitators available – the obvious sign that corporate customers are driving the demand.
Don’t get me wrong, I think LEGO® Serious Play® is a brilliant diversification move for a toy manufacturer, particularly given the service concept included. Not just selling a kit once, but renting it repeatedly to corporate clients instead is a much more favorable business. Additionally, it is a valuable touch-point to Christmas budgets decision-makers, aka moms and dads.
Why This Form of Gamification Is a Fad, Not a Trend
However, what is bothering me utilizing LEGO® to practice agile software development processes is the following:
- LEGO® is too abstract: Most of the participants of the agile workshops mentioned before are professionals from the software industry. Building a ski resort with LEGO® is only remotely related to the various challenges that product people–for example, engineers, UX/UI designers, or product managers–are facing.
- LEGO® is not being taken seriously by workshop attendees: Every product building simulation based on LEGO® I have been participating in so far ended up in a frantic race against the time-box. In the end, anything “created” was accepted, no sprint ever failed. Value? No one cared. Planning? Hey, there is none—as we all know—planning in Agile, right?
- LEGO® is not trust building: Imagine the following conversation happening after a 2-day-workshop: “Boss: What did you learn at the workshop? Participant: We build an airport with LEGO®. Boss: At $ 1,500 expenses—tell me, what’s in for the company?”.
If an organization starts venturing out into the Agile world, the biggest challenge is always trust. To my experience, very few stakeholders are willing to entrust their personal careers to other people for the benefit of the doubt, given the magnitude of their perceived loss of control. If an organization wants to be successful at the Agile transition, it all starts with the stakeholders’ belief that there will be a (also personal) return on investment for them.
And my gut feeling is that no matter what LEGO® artifact you’ll be building during a workshop, it will always generate less trust than any clickable prototype of a new app. (See also: Gamification Is Either Infantile Or Manipulative by Steve Fenton.)
Substituting LEGO® with Rapid Prototyping
All those issues are the reason, that the workshop Agile Software Development, my friend Martin Rothenberger and me will be organizing on October 22, 2015 in Berlin, will not use LEGO®. Instead, we will be building a simple, yet clickable and hence user-test ready prototype of an app with Marvel, one of the most advanced prototyping tools.
There is a good introductory video by Pablo Stanley on Marvel, that shows how easily you can build something meaningful while practicing Agile processes:
What is Your Take on Gamification of Agile Workshops with LEGO®
What is your opinion on LEGO®? Why would you choose it over building hands-on, clickable prototypes? Please let me know, I am curious to learn from your experience.
Trademark notice: LEGO®, the LEGO® logo, the Brick, DUPLO®, and MINDSTORMS® are trademarks of the LEGO® Group. ©2012 The LEGO® Group. (You can find further copyright information here.)
Related Posts
App Prototyping With Absolute Beginners – Agile Experiments
7 Best Practices On How To Build A Product Roadmap
Four Lessons Learned From Making Customer Value Your Priority
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
Hi Todd,
Great response. Would like to turn it into a post and publish is on Age of Product? You can reach me via: stefan at age-of-product.com
Lego worked for me. Over the past 3 years, I’ve used Legos to introduce agile to thousands. I have had the opportunity to watch them progress. Some have failed many have succeeded; but all started with Legos. The Legos introduced basic concepts and generated excitement. They broke resistance. The first hour of most workshops is a one hour scrum immersion. It is very fast and generates a lot of excitement. In the first 5 minutes everyone builds a lot without any thought of the product owner. They all fail at this point and we introduce the a helper. They lead scrum for two 20 minute sprints. Later, when everyone catches their breath, we tell them what they learned. The Legos are only used for an hour, so, not quite as expensive as two days. The remaining workshop varies hands on work, penny games, pizza Kanban, videos, and stories from similar teams. These workshops are 1/2 day to one day. All teams volunteer for the workshops as we have an opt-in transformation. The demand for Legos was slow at first; but gained as the reputation of success spread. After a year and a half, our CIO pulled us into her office to congratulate our four person team on transforming the organization. She was amused with the stories of Legos she heard about. The workshops were whole team and often involved senior leadership, the business, as well as all teams. Even our SVP’s played with Legos and loved it. Our CIO related that her leadership said good things about the Lego workshops. We’re on our last 10% of the org. That’s about 700 folks in a few areas that didn’t volunteer until this year. So, after nearly 6000 people have played with Legos and succeeded in changing mindset and behavior, I’d recommend Legos as a tool. They are not the only tool; but they do help. I wouldn’t recoomed more than an hour and a half of Legos; but I wouldn’t run a workshop without changing media and engagement modes every 30 to 90 minutes. We swap play and traditional learning modes constantly. Adults can’t play for too long and they can’t sit in front of PowerPoint too long. Perhaps the issue is not in the Legos; but in how they are used. For me, Legos are not a fad. They are a must and I can’t imagine not using them for many types of training. Cultures and companies may vary, so, perhaps they don’t work for every situation. Still, I think the issue is not likely to be Lego as a learning tool. Rather, the issue may be in the application of Legos.
@KoenV – I put my hypothesis, that you can build “software” using rapid prototyping tools in entry-level workshops, to the test last week at my current client. It was a 3 hour workshop and the half of the participants didn’t have any background in software design whatsoever.
I tasked them with designing the basics of an app to support with the organizing of team events. We started with approx. one hour spent on identifying a probably customer journey and its basic features using a light version of Jeff Patton’s user story mapping. Once we agreed on two “versions”, we split the group into two teams. We demoed Marvel and then started the first sprint, well we did not label it that way.
We were just using paper, colored pencils and wax crayons – and it worked: At the end, we had two different interpretations of the original user story map. And all four without a software background had:
a) something to show they participated in making and
b) a much better understanding how product management & engineering in an agile set-up actually works.
So, from my perspective, it is worth giving it a try.
Up to some extend I can agree with the fact that people question the added value of building airports… Software professionals can have a “binary” mindset and their management can have their doubts about the added value of paying 1500 USD for playing with LEGO during 2 days.
On the other hand, you do have a team dynamism going on: people working together making something. How will you achieve this team dynamism using a prototyping tool? Is it a matter of each participant preparing part of a flow and then integrating it as team?
Additionally, it is always better to learn in a safe environment. Building stuff with LEGO is definitely a safe environment. Isn’t it a potential pitfall that people will use their own case to work on (with too high expectations) and possibly be disappointed about the result, or focus more on the end result and less on the learning part?