Since times immemorial, ideas, objects and experiences of grand stature and lasting economic, social and emotional value have been created by men and women working together in teams. Granted that some extraordinary work in the fields of arts, philosophy and sciences was done by truly exceptional individuals, apparently working alone, I suspect that they too were ably supported by other selfless and unsung individuals (in the backoffice, perhaps) who all worked together as a team. Right from the great wars, social upheavals, political resistance, empire building, freedom struggles and formation of nations and protecting its borders to the creation of majestic wonders such as Pyramids, Taj Mahal, Eiffel Tower, Statue of Liberty, Sydney Harbor Bridge or the London Eye and many more, each one of them owes its creation and existence to teamwork. Of course, the scope of teamwork doesn't exclude simple and everyday things that are extremely important even though they never make a headline: an activity as routine as tilling the fields, or planning a picnic or even a family function, all involve a team.
With such profound impact teamwork having on our everyday lives, it is only natural to expect that output of a team is directly impacted by the quality of its teamwork. Unfortunately, this doesn't happen by having right intentions alone, or by leaving it to chance. Quite often, it doesn't even happen! Quality of teamwork is impacted by various factors such as motivation levels of individual team members, levels of trust among team members, clarity of purpose, uniform understanding of the goals, lack of resources, poor communication among the team members, and so on . Thus, it comes as no surprise that appropriate investments must be made to make the team click. However, most often, team dysfunctions affect a team's performance seriously jeopardizing its ability to perform effectively, any state of art processes or tools notwithstanding. Most software managers lack the ability to detect such deeper sociological smells, thus are unable to deal with its impact. Any superficial response to such problem only makes the task harder to deal with.
In this article, I have analyzed team dysfunction model proposed by Patrick Lencioni in his wonderful book, written in the form of a business fable, The Five Dysfunctions of a Team - A Leadership Fable . In his model, called The Model in the book, he has identified five dysfunctions of a team that affect team performance. These five dysfunctions are not really independent, but build on top of one another as illustrated in the model below:
So, Absence of Trust leads to Fear of Conflict , which in turn leads to Lack of Commitment , and so on. Though Patrick has discussed The Model in context of a business team not performing to its fullest potential, I find the ideas universal and applicable in the context of a software development team as well. Perhaps the purpose and importance of teamwork is nowhere more evident than in software development.
Software development is a team sport with its own fair play policy ("professional ethics"), set of rules ("process") and a very high premium on teamwork. The reason a software development process exists, or the management overheads (in whatever flavor and portion size as deemed reasonable by the process or the organization), or more simple things like having a uniform IDE, common coding guidelines, configuration management tools, ...practically everything exists for the sole reason of making the whole of a team greater than its parts. However, we also know that failure rate among software projects is alarmingly high, and even though there is no consensus in