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.

The Importance of the Invisibles (Book Review)

When I read Tom DeMarco’s classic I book Peopleware some time ago, one small part of the book stuck with me. He briefly discusses the idea that some people on teams are Catalysts, people who seem to help a team but who didn’t stand out. As an example, DeMarco describes one person:

“ During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around.”

This brief acknowledgement of the contribution of someone who wasn’t a star can make to a team stuck with me as something that made sense, but which I never thought about before. David Zweig’s book Invisibles: The Power of Anonymous Work in an Age of Relentless Self-Promotion is an entire book that describes the role of people like this, and thus made a big impression as well. It’s not that some of the people Zweig describes are not incredibly talented and skilled; they are. It’s just that they aren’t the people you think about when you consider what went into a successful concert, perfume, building, or diplomatic discussion.

Invisibles helps you to understand the importance of people you don’t normally think of in our lives, and also explains how their under the radar existence both helps them be effective, but also is enjoyable for them. In addition to learning about what invisibles are and what makes them tick, you also learn a bit about how the traits of invisibles are useful, even if you are someone who enjoys roles in the spotlight.

Invisibles is a surprisingly entertaining and engaging book that not only made its point, but also taught me quite a bit about some professions I knew little about. This book starts with the premise that “invisibles” all share 3 traits, and then introduces you to a few people who illustrate those ideas. I got a review copy of the book because I was intrigued by the premise. As I started the book I thought that it was mis-titled. It seemed less about invisibles themselves, than the jobs they do. But it is through a deeper understanding of the work, and how the people perform their work that you understand what makes invisibles tick. Along the way you also learn a bit about leadership, management, and motivation. At one point, Zweig explains how the desire of some invisibles to help others leads both to very effective groups and projects, and (sometimes) poor individual performance and I was the connection the “Catalyst” role Tom DeMarco describes in Peopleware, and the relevance of this book to people who work in or with teams of any kind, but espectially agile teams.
It’s important to note that not all of the invisibles are all that invisible. One example was a Director of Photography, a role that often is quiet visible on movie credits. But for the most part, you probably didn’t know that many of these people existed, and yet they are essential. (The structural engineer who worked on Falling Water, was responsible for the structure not falling down, in spite of Frank Lloyd Wrights’s design, for example). The book ends by illustrating how we often notice these invisible roles only when the persons performing them fail, or when we don’t engage them to do their jobs.

Having read this book, I’m realizing that I sometimes took the importance of invisibles for granted. Sometimes inwardly focused star performers are more effective when being helped by someone who can help keep the team focused on the goal. This isn’t the message that we are often told. The usual message is that it’s a star performer who saves the day. One recent exception is the Lego Movie (which I won’t claim to be anything more than a fun, self-aware film, but I have seem it a few times with my 7 year old). It is reassuring to see real stories of the value of people who are not in the spotlight.

In software development much of the useful work happens among teams of skilled professionals, all of whom need the work of the others to produce really great products. As an advocate for agile practices, and a Scrum Master, I realized that the importance of individual enablers. While I get to facilitate meetings and play some central roles, I also know that at the core, a good Scrum Master is a servant leaders, for whom the best praise is praise directed at the team.
Invisibles doesn’t torment you with its message that there are 3 traits that invisibles have. It tells stories and examples to makes its point, and even if you don’t fully buy it’s message, you end up having learned some things you didn't know and with some things to think about.
I was surprised at how much I enjoyed this book, and how much it helped me to learn and made me think. If you like books about work style, motivation, or are just a curious person, this book is worth a look.

Books and other media I mentioned above

Gulp! (Book Review)

It could be that I'm the parent of a 7 1/2 year old boy. It could also be that the book has such great footnotes ( when I was in grad school working on a paper for a group project, one of my fellow students commented that I wrote great footnotes), but I found Mary Roach's book Gulp: Adventures on the Alimentary Canal to be very engaging and entertaining, as well as educational.

Gulp is a very approachable "top-to-bottom" tour through the human digestive system. Combining fact, history, some editorial commentary, and much humor you can't help but get pulled into this book, and even pull in those around you. At various points I found myself laughing out loud, leading my wife to comment that I,  have a lot more in common with our 7 year old, or at least that there is a certain timelessness to that sort of humor among certain demographics. The chapter on flatulence was particularly amusing, and was a great example of how Roach uses humor to help us learn about socially awkward topics, and to make details memorable.

One of the charms of this, and the other books of her's that I have read, is that she is adept at staying on the correct side of the boundary between humor that makes us comfortable (and makes facts memorable), and humor that is just awkward. She did a similarly good job with Stiff: The Curious Lives of Human Cadavers.

While this isn't the book to read for serious research, it is a good place to learn some fun facts about a subject that is not often discussed in polite company. With footnotes and references, you also have a good starting point in case you want to learn more. The only down side of reading the book is that you may find yourself laughing out loud or at least finding it hard to share a particularly amusing storing with whoever is sitting next to you while you are reading.

Gulp is a great example of how you can be entertained, informed and educated at the same time.

Gulp: Adventures on the Alimentary Canal

 

Book Review of Java Performance: The Definitive Guide

While tools and technologies change rapidly, and looking up information online is sometimes the best way to get the information you need, I can be useful to occasionally read a book to get oriented in a subject and discover what you didn't know that you didn't know. For me a good technical book sets the context for the problem and gives you enough information to apply what you learned to harder problems that the book covers, but which also gives you information you can apply immediately.  Java Performance: The Definitive Guide does a good job of both.

Not just about JVM params, the book covers application and algorithm issues, database connectivity, as well as JVM issues such as garbage collection algorithms. What is useful, and sadly rare,  is  that this book not only tells you things you can do,  it also tells you things that you can skip, since not every thing you do has a good cost/ benefit payoff.

With an emphasis  on standard tools, including open source and those that come with the JDK,  you can apply what you learned immediately. The book does not cover every tool, and may not include your favorite, but the discussion has enough  tools to get you started.

This book will be useful for both those new to programming in Java (since performance and resource use area rarely emphasized who you are learning to program) and those who have been programming a while but have not spent as much time thinking about performance as one might like.

I got my copy of this book through the Amazon Vine program.

Estimation as a requirements Exercise

I explored the role of estimation in a couple of articles on Techwell recently.

In the first article I discussed how teams balance the cost of estimation (in terms of time it takes) with the value it brings to the project. Some argue that estimation isn't very useful at all, where other's say that it can be useful, but that all stakeholders may not have the same vision of the value estimation brings.

In a follow up article I explore the debate about whether to estimate in hours, which reflects effort, and time, or  points, which reflect complexity. This is a common debate, since many articles on agile advocate points, to step away from the concepts of estimate, and focus on the complexity of a feature, and also to help teams move towards the model of the estimate being valid for the team and not just a particular person. And stakeholders are often concerned about schedule and deadlines, so tend to prefer hours initially.

Different teams will come to different decisions about what works best for them. To me the most important part of the estimation discussion is the part many teams don't have, namely asking (and answering) the question of why they are estimating, and what value the estimates bring to the project given that they are now working with an agile process.

As I think more about what value estimation has brought to teams that I have worked on, I realize that the biggest value is that of having a a discussion of scope. When you have an planning meeting, a few questions come up:

• Why people have different estimates
• Why the estimate is larger, or smaller, than the product owner expected
• Whether the team really understands what the story means.

Give this I'm leaning towards thinking of estimation as being more about requirements definition rather velocity, effort, or even complexity.  To that end, maybe the approach to use is one where you spend all of your planning effort defining stories in terms of small, fixed size units, and your velocity is about how many stories you finish off of a prioritized backlog. I link to a description of what this means in the points and hours article.

I'm  interested in hearing about creative approaches your teams have used for estimation. Please comment on  the Techwell articles, or here if you want to share lessons you have learned.