Brick By Brick: Lessons from Lego (Book Review)

There is no shortage of business books about companies that lose their way, and then do a dramatic turn around. Some are more relevant that others. Brick by Brick by David Robertson caught my attention because it is about an iconic toy that is, at the moment, popular with people of all ages. The book first came to my attention when we were stopping at a bookstore bookstore in Saratoga Springs, NY last summer. My then 7 year old, a big Lego fan, and avid reader handed the book to me suggesting that I might enjoy it. He was right; I enjoyed reading the book and also learned some useful things.

While I had heard stories about the reasons behind the recent surge in Lego’s popularity, I had not realized both the scope of the changes the company made, and the depth of the problems the company had. Lego’s story is one of a company losing track of it’s core vision while trying to diversify and create market opportunities. Robertson explains the rise and fall, and rise of Lego in an engaging style, while highlighting the key lessons are reader can apply to their orginization.
While much of the book was a great story, it was around the mid-way point that I found items that resonated with me as an Agile Software Development practitioner. One of the insights in the book was that more constraints can make for more creativity. In particular, Lego sets are constructed with many of the same bricks; new bricks are rare, so designers are encouraged to create new models with existing bricks. This isn’t necessarially surprising to someone used to working with constraints (or building with Legos), but it does contradict the sterotype that blank pages are best for creativity.

Also reminiscent of agile adoption is the idea that action that leads to forming new habits is essential to changing a culture. This is much like how agile practices, done well, can help the team form habits that further enable agility.

There were also some interesting lessons in the discussion of how Lego involved community members in the design of new toys. The community related acitivities were managed in a way where the final decisions rested with select people at Lego, rather than in concensus. Deciding how to make decisions is an important decision for every team to make, as Ellen Gottesdiener tells us, and concensus isn’t always best. The formerly top-down company also discovered the power of voluntary commitment. This is an example of how management skills that make sense in the context of volunteers (the community members) apply to workplace management as well. (Tom Demarco also discuses this in Slack ).

I enjoyed reading this book, mostly for the chance to hear the story of the company whose products appear to be even more popular than when I first encountered them as a child. It was an unexpected surprise to also learn a few things that I could apply to help the teams I work with be more innovatiove and productive.

Five Dysfunctions of a Team (Book Review)

I’ve often thought that the hardest part about building a software product was creating an environment where the people on the project can work together effectively. The Five Dysfunctions of a Team kept showing up on recommended book lists and I finally decided to get a copy. I’m glad I did. This quick to read book helped me to remember some simple, yet important, things about how great teams work.

Reminiscent of The Goal and The Deadline, The Five Dysfunctions of a Team spends most of its time teaching its lessons using the example of a fictionalized story of a new CEO joining company in trouble.

The CEO uses the model to help the executive “team” become a team in more than name. Even though the story itself isn’t great literature, since I’ve been in and around dynamics similar to those in the book, I really wanted to see what happened next. (Though a successful ending was never really in doubt.)

There is a brief summary of the 5 dysfunctions model at the end, but the story form really drives the point home better than the 37ish page summary of the model. You could just jump to the summary of the model, but the lessons might not stick, and the power of the simple model might be as clear. What the model description adds is the important point that the parts of the model work as a system, and can’t really be taken independently.

If you’re on an agile team you might want to think about how agile methods both rely on and encourage the elements of the model.

If you are on a team, (or even part of a family) you’ll find value in this book, either as a way to lead others to form a better team, or as a way to understand what’s happening around you so that you can do better on your own, and make the right choices to help you work on a good team.

Essential Scrum and Other Books to Help You be Agile

I’ve read a few books on Scrum over the years. I read Essential Scrum because others at my company who had not gone through Scrum training with Kenny Rubin, and I wanted to use the book aa a vehicle for refreshing my thinking and getting on the same page as everyone else in terms of terminology, best practice advice etc. The book helped with that and more.

Reading this book did more for me than give me a chance to synch up vocabulary. It helped me re-think some practices and consider ways to move beyond my current approach to Scrum and consider ways to do things better.

This book covers the whole spectrum of Scrum related issues from the usual Scrum mechanics, such as how to execute scrum meetings to questions that often leave those adopting Scrum for the first time puzzled such as how Scrum fits in the larger organization, the the role of Managers (yes, there is one), and how to deal with obstacles.

The book has an excellent discussion of the various Scrum roles, and how they work in real situations. (For example, what to do when you can’t have a dedicated Scrum Master). This is a book on process, but it does not let you forget that people and communication are at the core of Scrum.

This is a rather complete book on its own, as it covers the full spectrum and full lifecycle of Scrum from planning to retrospective, and from Portfolio to sprint. Rubin also provides a selection of good references throughout should you want to go deeper. In particular you might want to follow up by learning more about retrospectives by reading Agile Retrospectives or learn more about portfolio management by reading Johanna Rothman’s book.

What was especially interesting for me to see was the chapter on management. With the focus on self-organizing teams and mechanisms for team feedback and improvement, many people either neglect the role of managers, or overlay an approach that can stifle a scrum team. Rubin has an excellent chapter on this topic. You may also want to read Management 3.0 for a broader perspective on what a manager on an agile team is, and Behind Closed Doors: Secrets of Great Management for some excellent day to day advice on managing in any context, but especially an agile one.

This book is different from some other recent books on Scrum. Scrum: The Art of Doing Twice the Work in Half the Time is more about the principles of Scrum, and it’s a great book to inspire you to implement Scrum values, but a book like Essential Scrum is what you’ll need to actually execute. The Human Side of Agile adds to Essential Scrum by guiding you through the interplay between technical and people issues.

Essential Scrum is readable and useful by everyone on the team and in the business, and is a great book to read if you can read only one for now. Essential Scrum can help you adopt Scrum more effectively, or reenergize your Scrum thinking if you are Scrum veteran. There are other books that will want to read as you seek deeper knowledge, but you can’t go wrong with starting with Essential Scrum.