How Agile Practices address the Five Dysfunctions of a Team


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How Agile Practices address the Five Dysfunctions of a Team

  1. 1. How Agile Practices address the Five Dysfunctions of a Team Tathagat Varma, 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 forming 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, mundane 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
  2. 2. on12345678. 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 the team dysfunction model proposed by Patrick Lencioni in his wonderful book, written in the form of a fable in a business setting, 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 interrelated to each other, and build on top of one another as illustrated in the model below: 1 Why Teams Fail, 2 Why Teams Fail, 3 Why Dream Teams Fail, 4 The Top 5 Reasons Business Teams Fail And What You Can Do About It, 5 Why Teams Fail, 6 Why Projects Fail…and what can you do about it, 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, projects-fail.html
  3. 3. 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 the 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’, and what really is the statistics of project failures, we all know that 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 as9 (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.” 9 Agile Software Development,
  4. 4. They bring the highest levels of empowerment to teams and individuals that we have seen in the software industry so far. I see them as another important step in process improvement that has taken the decision- making away from managers to empowered and self-directed teams, 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, but 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 a random collection of individuals, how so much competent they individually might be. 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 teams11 admit their weaknesses and mistakes, ask for help, accept questions and inputs about their areas of responsibilities, give one another benefit of the 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. 10 The Five Dysfunctions of a Team, Page 188 11 Page 197
  5. 5. Agile encourages adaptive software development that relies heavily on feedback from the past performance to improve future performance. Agile encourages face-to-face conversation and interactions among all stakeholders – developers, business people, sponsors and customer. It also encourages frequent (often 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 skillset 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. Team commitments are owned by the team, and with small teams located in a single location, it serves as a conducive atmosphere for team members to lean on each other for meeting team commitments. Specific practices like Pair Programming help develop the trust even further, because the fundamental idea is to detect bugs in the software as early as possible, and not focus on such data to judge the performance of an individual team member. To that end, the notion of team’s productivity, ‘velocity’ is not attributed to an individual, but rather to the team. 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 the team in productive conflict. In Patrick’s view teams that engage in productive conflict13 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. 12 Page 188 13 Page 204
  6. 6. Agile requires involving all team members in estimation and planning, status updates and retrospectives. Daily standup meetings in Scrum 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 the team’s commitment), and next step is not 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 commits15 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 it is a team-oriented approach where everything is driven and owned by the team – right from agreeing on sprint backlog, estimates, measuring and tracking progress to the eventual delivery. There are no individual commitments in an Agile team – the progress and success of an Agile team is solely measured by the 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. The process of retrospectives is institutionalized to ensure that such feedback is take from the team at every sprint and finally at the end of each project. Agile also mind of emboldens the team members to embrace uncertainty. Traditional software process has serious limitations to handle highly uncertain or rapidly changing / evolving 14 Page 188-189 15 Page 209
  7. 7. problems, and most people might see participation in such risky projects as a professional grave. However, it is also true that most such projects are career-building assignments with tremendous learning opportunities, even if they fail. Agile practices help a team make the best out of such uncertain conditions by giving opportunity to do short-term planning, and take problem one by one, thereby reducing the risk of failure or a major rework. Thus, the team certainly feels much more confident to undertake such risky endeavors, and whenever there are mid-course corrections, as they eventually will, Agile readily embraces such changes. 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 Team that doesn’t own commitment might do poorly on accountability. When there is absence of trust, team members often will work towards their own goals as opposed to the 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, and externalizing the faults. 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 accountable17 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 the planning and tracking aspects of a project. Additionally, Agile teams are small, and hence every team members’ performance is known 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 an Agile team will offer all types of help, but the idea is not to chastise (nor tolerate) the poor performer, but make sure the team 16 Page 189 17 Page 214
  8. 8. is working on its commitments and doing everything that is required and possible to meet it. Additionally, even though Agile is a team approach, it doesn’t undermine the importance of key performers. Like in any team setting, respect easily comes to the key performers, who are looked up to by peers and such respect helps set role models in a team (which is easily noticed in a small Agile team). 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’s skills at the cost of holding back on one’s pride and prejudices in order to deliver on team commitments. Further, short and frequent delivery of working software helps minimize chances of grand failures, and every iteration that helps the team get closer to its goal is cause of joy. 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. 18 Page 189 19 Page 208
  9. 9. 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 productive20. 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. Tathagat Varma, PMP®, 6σ Black Belt, Certified Scrum Master, Lean Certified, Kaizen Certified, is General Manager with NetScout’s Bangalore Engineering operations. He has been experimenting and learning from IID since 1998. He is currently working on understanding and cross-pollinating the principles of Supply- chain Management, Lean and Six Sigma in software development. He hosts a blog Manage Well, where he writes about his views on simplifying management in everyday software development. He can be contacted at 20 Agile’s Impact on Team Performance,