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
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