Sunday, February 15, 2015

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.

Friday, January 23, 2015

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.