Teamwork, no matter the intentions at the start of any agile project, can be derailed by even the smallest factors. Learn how to identify the five dysfunctions of a team so that your team can address them and avoid letting them grind your production to a halt.
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 [1][2][3][4][5][6][7][8]. 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 industry on what exactly constitutes ‘failure', we all know failure rates are higher than they ought be! Given all the bright people employed by software industry, I would be surprised if technical incompetence, carelessness, stupidity or deliberate sabotage would rate very high on the list of reasons behind project failures, sporadic exceptions notwithstanding. So, why do so many software teams still fail to achieve their set objectives? I believe, everything else being equal, team dysfunctions are a significant, and under-recognized, reason why software projects fail.
Team process determines the ‘way of working' and has a big impact on team's effectiveness. In the last decade, Agile methodologies have gained significant popularity and have become mainstream. Wikipedia defines them as [9](relevant text highlighted by me):
"... Agile methodologies generally promote: A project management process that encourages frequent inspection and adaptation; a leadership philosophy that encourages team work, self-organization and accountability; a set of engineering best practices that allow for rapid delivery of high-quality software; and a business approach that aligns development with customer needs and company goals."
They bring the highest levels of empowerment to teams we have seen in software industry so far, thus rendering the role of teamwork even more important than it ever was. However, Agile is not a sociological process. It is a team-oriented philosophy for software development, and though it has traces of team sociology, if viewed too dogmatically, it is very easy to overlook them.
Considering Agile Principles are gradually becoming industry's de-facto development process, I have analyzed how Agile Practices address the Five Dysfunctions of a Software Team. Let's take them one by one, starting from the bottom of the pyramid.
Absence of Trust
"The first dysfunction is an absence of trust among team members. Essentially, this stems from their unwillingness to be vulnerable within the group. Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust." [10]
A team is much more than just a random collection of individual team members. Each team member brings distinct and often complementary skills to the table, and collectively this superset of all skills helps a team achieve its goals. In a conventional team created along the lines of ‘division of labor' approach, there is strong peer pressure among team members that doesn't allow ‘vulnerability-based trust' to develop. Team members are ‘trusted' based on their past performance to repeat the same. However, in modern business, no one can be assumed or expected to have all the required skills to succeed under all conditions. As per Patrick, members of trusting teams [11] admit their weaknesses and mistakes, ask for help, accept questions and inputs about their areas of responsibilities, give one another benefit of doubt before arriving at a negative conclusion, take risks in offering feedback and assistance, appreciate and tap into one another's skills and experiences, focus time and energy on important issues and not politics, offer and accept apologies without hesitation and look forward to meetings and other opportunities to work as a group.
Agile favors face-to-face conversation and interactions among all stakeholders. It also encourages daily updates on its progress, and reflects back at the end of iterations on how things went and what can be done to improve them in future. Such open communication and feedback on a periodic basis can be a very effective trust-building exercise.
Often, Agile teams are small and instead of having multiple people with competing skill-sets and assignments, team members have complementary skills and assignments. They are also highly self-directed and allow team decisions to be taken in a democratic manner, instead of being imposed from customer or management without any sound rationale, or logical debate. Commitments are owned by the team, and with small co-located teams, it serves as a conducive atmosphere for team members to lean on each other for meeting team commitments. Practices like Pair Programming help develop the trust even further, because the fundamental idea is to detect bugs as early as possible, and not focus on such data to judge the performance of an individual team member. All these actions are highly likely to build trust among team members.
Fear of Conflict
"This failure to build trust is damaging because it sets the tone for the second dysfunction: fear of conflict. Teams that lack trust are incapable of engaging in unfiltered and passionate debate of ideas. Instead, they resort to veiled discussion and guarded comments." [12]
Lack of mutual trust lowers the ability to engage in productive conflict, lest a differing opinion be seen as anti-team. This eventually becomes a self-defeating problem, for a fear of conflict not only damages team's decision-making ability and progress, it further deepens the already existing absence of trust. The need is to engage team in productive conflict. In Patrick's view teams that engage in productive conflict [13] have lively, interesting meetings, extract and exploit the ideas of all team members, solve real problems quickly, minimize politics and put critical topics on the table for discussion.
Agile requires involving all team members in estimation and planning, status updates and retrospectives. Daily standup meetings are aimed at addressing the team and not any manager. There is transparency on team's progress, and it is very easy to identify if a team member is falling behind (that could jeopardize team's commitment), and next step is not to chide him for slow progress, but rather a helping hand, and if required, a constructive debate on how to solve his problems. Because the ‘vulnerability-based trust' has already been established by this time, team members value healthy conflicts without any fear of a reprimand.
Lack of Commitment
"A lack of healthy conflict is a problem because it ensures the third dysfunction of a team: lack of commitment. Without having aired their opinions in the course of passionate and open debate, team members rarely, if ever, buy in and commit to decisions, though they may feign argument during meetings."[14]
It is not difficult to imagine that team members who don't trust each other are not going to agree to work together, or share common commitments. Patrick views that a team that commits[15] creates clarity around direction and priorities, aligns the entire team around common objectives, develops an ability to learn from mistakes, takes advantage of opportunities before competitors do, moves forward without hesitation and changes direction without hesitation or guilt.
Agile's strongest point is that everything is driven and owned by the team - right from committing on sprint backlog, estimates, measuring and tracking progress to the eventual delivery.The progress and success is solely measured by team commitments that have been met. Agile also focuses strongly on learning from its past experiences, especially mistakes, and taking specific steps to improve upon them that are collectively committed to by the team. Unlike the traditional teams, each one of these involves a team commitment.
Avoidance of Accountability
"Because of this lack of real commitment and buy-in, team members develop an avoidance of accountability, the fourth dysfunction. Without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team."[16]
Teams where there is no collective ownership of commitments might do poorly on accountability. When there is absence of trust, team members often will work towards their individual goals as opposed to team objectives. And often, there will be tendency to just be accountable for one's own piece of work. One can expect a lot of finger pointing. However, responsibility and accountability go hand in hand, and as much as we require teams to be self-directed and empowered, we also require them to own their accountability. As per Patrick, a team that holds one another accountable[17] ensures that poor performers feel pressure to improve, identify potential problems quickly by questioning one another's approaches without hesitation, establish respect among team members who are held to the same high standards and avoid excessive bureaucracy around performance management and correction action.
Agile focuses on involving all team members in planning and tracking aspects of a project. Additionally, Agile teams are small, and hence every team members' performance is visible to the entire team on an almost daily basis. While the idea is not to put negative pressure on an individual, it won't be wrong to say that a poor performer in such a setting would be under enormous peer pressure to pull up his performance. Of course, other members of Agile team will offer help, but the idea is not to chastise (nor tolerate) the poor performer, but make sure the team is working on its commitments and doing everything that is required and possible to meet them.
Inattention to Results
"Failure to hold one another accountable creates an environment where the fifth dysfunction can thrive. Inattention to results occurs when team members put their individual needs (such as ego career development, or recognition) or even the needs of their divisions above the collective goals of the team."[18]
A team where no one trusts each other and where people are only bothered about their own progress in silos will often have problem achieving team commitments. However, it is impossible to deliver great software without staying focused on ‘collective results'. Patrick describes a team that focuses on collective results[19] retains achievement-oriented employees, minimizes individualistic behavior, enjoys success and suffers failure acutely, benefits from individuals who subjugate their own goals / interests for the good of the team and avoids distractions.
Agile promotes individuals with cross-functional knowledge working in close cooperation with business people to ‘satisfy the customer through early and continuous delivery of valuable software'. Agile Principles seek to build projects around motivated individuals operating in self-organizing teams. Such intents favor interdependence of team members on each other to deliver on team commitments. Further, short and frequent delivery of working software helps minimize chances of grand failures, and each iteration helps the team get closer to its goal. Finally, the practice of team retrospectives helps the team to ‘reflect on how to become more effective, then tune and adjust its behavior accordingly'. When lower-level team dysfunctions have been eliminated, there is a strong foundation of mutual trust and an ownership and accountability of team commitments that helps the team stay focused on collective results without people promoting their personal agenda in the game.
Conclusions
Agile methods are helping software organizations improve their performance. In a recent survey presented at Agile 2008, Agile teams were found 37% faster to market and 16% more productive[20]. While Agile practices are explicitly aimed at ‘uncovering better ways of developing software', it also addresses the aspect of team dysfunctions subtly. Without directly asking people to change their behavior, Agile practices help overcome some of the most common team dysfunctions thereby creating a strong foundation for a team to perform upon.
[1] Why Teams Fail, http://www.kenblanchard.com/img/pub/ignite_volume11_2006.pdf
[2] Why Teams Fail, http://www.asq.org/learn-about-quality/teams/overview/tutorial.html
[3] Why Dream Teams Fail, http://money.cnn.com/magazines/fortune/fortune_archive/2006/06/12/8379219/index.htm
[4] The Top 5 Reasons Business Teams Fail And What You Can Do About It
[5] Why Teams Fail, http://www.7stepsahead.com/articles/WhyTeamsFail.pdf
[6] Why Projects Fail...and what can you do about it, http://www.stellman-greene.com/blog/wp-content/uploads/2007/06/why-projects-fail.pdf
[7] Why Computer / Software Projects Fail
[8] Why Software Projects Fail and How to Make Them Succeed, http://www.projectsmart.co.uk/why-software-projects-fail.html
[9] Agile Software Development, http://en.wikipedia.org/wiki/Agile_software_development
[10] The Five Dysfunctions of a Team, Page 188
[11] Page 197
[12] Page 188
[13] Page 204
[14] Page 188-189
[15] Page 209
[16] Page 189
[17] Page 214
[18] Page 189
[19] Page 208
[20] Agile's Impact on Team Performance, http://www.projectsatwork.com/content/articles/244255.cfm
