I just finished reading two books, The Checklist Manifesto by Atul Gawande and The Five Dysfunctions of a Team by Patrick Lencioni. I started reading the Five Dysfunctions first, got through the fable and picked upped the Checklist Manifesto. I then resumed with the Dysfunctions, and I just finished reading it a few minutes ago. Considering that the books are about seemingly different things, they are, in the core, about the importance of communication in teams and the value of teamwork in general. The idea that a team is larger than the individuals put together, something that I'm perhaps only now starting to comprehend.

While I'm critical about the team-building exercises, epitomized as carrying logs and rowing large boats, it is clear that the dysfunctions are and have been present in the teams I've worked in, and something needs to be done. Lack of trust towards team-members, which ultimately results in trying to hide mistakes and using guarded language, is a sympton. To build trust, I'd be willing to try the exercises presented in the book, or even use an outside consultant as help. In Checklist Manifesto, the checklist was not only about using checklists to avoid stupid mistakes, but it was used to initiate team communication and making sure everybody knew what is being done and commit to it. That, in my mind, is the biggest takeaway from the manifesto, that teamwork and the whole team is required for success.

In Checklist Manifesto, there was also discussion about increasing complexity in various professions. Chronologically, the first example was the destruction of a Boeing Corporations Model-299, crashing in October 10th 1935. The aircraft was deemed as "unflyable" because of its complexity, until the introduction of a checklist for the takeoff. The aircraft became later known as the B-17 bomber.

It looks like the time for a single person to handle all aspects of a trade, or a master builder, is over. The team is the hero, not the individual. The analysis by the surgeon writing the book is that the whole team needs to perform, not just the head surgeon. This is in contrast with the idea of the surgical team, where there is the head surgeon or architect, with the rest of the team facilitating him or her. This idea was put forth by Fred Brooks in the Mythical Man Month, and I think it is a failed paradigm, for various reasons, but mostly because I've witnessed it fail enough times.

How to apply the learnings from these books in my chosen profession, software engineering? We already use checklists — lists of cases that need to be completed in a sprint, lists of tasks that need to be performed before a merge request is accepted or a release is signed off, and others. We just need to persuade people to use them, contribute in making them better, and generally become more involved. People need to be able to point out if things are not progressing acceptably, and for that we probably need better metrics. I also think many members in my team are not voicing their objections should somebody not perform up to par, which stems from yet another dysfunction, the fear of conflict. People need to be comfortable in expressing their honest opinion, something which probably does not happen right now.

I've been a stalwart opponent of open-space offices, maintaining that they cause performance to degrade. This is probably true for the individual, but it might be that built-in communication advantage would more than overcome the defiency. Mob-programming takes this to another level, by having the team work over the same keyboard and display. Woody Zuill held a nice presentation to us at the SSH offices a couple of months back, and I am becoming more and more confident that we need to try it out. It would be probably help in creating a more functional team.