Feeds:
Posts
Comments

It is pretty incredible how often we complain about our best employees leaving, and we really do have something to complain about — few things are as costly and disruptive as good people walking out the door.

We tend to blame our turnover problems on everything under the sun while ignoring the crux of the matter: People do not leave jobs; they leave their managers.

Here manager does not mean only the boss or the owner. For a junior developer it can be his senior one. For a senior developer it can be lead developer. For a lead developer it can be development manager. For a development manager it can be scrum master or product owner.

The sad thing is that this can easily be avoided. All that is required is a new perspective and some extra effort on both ends.

Let us discuss few things that send good people packing:

Overwork: Nothing burns good employees out quite like overworking them. It is so tempting to work your best people hard that we frequently fall into this trap. Overworking good employees is perplexing; it makes them feel as if they are being punished for great performance. Overworking employees is also counterproductive.

New research from Stanford shows that productivity per hour declines sharply when the workweek exceeds 50 hours, and productivity drops off so much after 55 hours that you do not get anything out of working more.

If we must increase how much work our talented employees are doing, we better increase their status as well. Talented employees will take on a bigger workload, but they would not stay if their job suffocates them in the process. Raises, promotions, and title-changes are all acceptable ways to increase workload.

If we simply increase workload because people are talented, without changing a thing, they will seek another job that gives them what they deserve.

Not recognize contributions and not reward good work: It is easy to underestimate the power of a pat on the back, especially with top performers who are intrinsically motivated. Everyone likes kudos, none more so than those who work hard and give their all.

We need to communicate with our people to find out what makes them feel good (for some, it is a raise; for others, it is public recognition) and then to reward them for a job well done.

Not care about employees: Study shows that more than half of people who leave their jobs do so because of their relationship with their boss. We need to balance being professional with being human.

We should celebrate an employee’s success; empathize with those going through hard times, and challenge people, even when it hurts. If we fail to really care then we will always have high turnover rates. It is impossible to work for someone nine-plus hours a day, five days a week, fifty two weeks a year when we are not personally involved with each other and do not care about anything other than your production yield.

Not let people pursue their passions: Talented employees are passionate. Providing opportunities for them to pursue their passions improves their productivity and job satisfaction. But sometimes we want people to work within a little box. Sometimes we think that productivity will decline if we let people expand their focus and pursue their passions. This fear is unfounded. Studies show that people who are able to pursue their passions at work experience flow, a euphoric state of mind that is five times more productive than the norm.

Fail to develop people’s skill: Management may have a beginning, but it certainly has no end. When we have a talented employee, it is up to us to keep finding areas in which they can improve to expand their skill set. The most talented employees want feedback — more so than the less talented ones — and it is our job to keep it coming. If we do not, our best people will grow bored and complacent.

Finally, I want to use one line to summarize the whole discussion: We want to create such a team that everyone wants to join.

Advertisements

Theory of the perfect team

Google is known for being obsessed with studying their own performance and then adjust accordingly. At one time Larry Page decided to get rid of all the middle management but then quickly realized that the increased amount of direct reports slowed the company down immediately. So, they brought them back. With its Aristotle project Google wanted to figure out what are great teams made of. At the beginning, they focused all on the individual skills of the team members and their performance but the results were sobering. Having all superstars on the team did not necessarily made a great team. After hundreds of teams studied, a pattern emerged. In all the high performing teams the members felt psychological safety. That means they were not scared to admit an error and talk about their ideas. Furthermore, these teams had all empathy for each other (social sensitivity) and equal voices, which mean that everybody’s opinion is heard when a decision must be made. This does not mean democracy, still somebody can make the decision but people feel that their opinion is considered. For our Scrum teams that means, it is more a cultural challenge rather than a skill challenge and the culture should incorporate those values:

  • Psychological safety
  • Social sensitivity
  • Equal voices

A popular thought for hiring a new employee regarding this: Hire for fit not for skill.

Multifunctional teams

A frequent question I get is: Does multi-functional team mean everybody on the team has to be an expert in everything? This is probably due to 2 facts:

  • We want the team to be independent with a few dependencies as possible to the outside. Therefore, we need all skills inside the team.
  • We advertise that there are no more specialists rather everybody has to be able to help out with other tasks.

Now if there is for example a data base expert on the team, it does make sense that he helps with the database issues but if he has idle time he should help out other team members. On the other hand, when there are a lot of database related tasks and he becomes the bottle neck others should be able to help him out as well.

The approach of A-teams (small engagement units) from the Special Forces is this: Each team member is cross trained. That means he is usually an expert in 1 or 2 specialties e.g. medic, radio, etc. but is also able to do general tasks in other areas. They have what is called T shaped people, a person that is expert in 1 or 2 areas but has general knowledge about all the other topics. Furthermore, every specialty exists twice (in case you lose the medic, there is still another one).

How can we apply that to our Scrum teams? First, it is important that all necessary skills are on the team to be independent. Then, we want every expertise twice, for example 2 persons with highly developed database skills. But we want also T-shaped people that can work on other parts as well (not only their expertise).

Bringing it all together

In sum, it is not so important to have superstars on the team rather than how the team is operating. The number one indicator is psychological safety followed by social sensitivity and equal voices. Secondly, culture has a huge impact on team performance. Even though, culture is probably the most difficult thing to change, moving to a commitment culture is one the most performance improving steps. Lastly, when it comes to who is on the team it is important to have T-shaped people that do have the necessary skills to work independent from the outside. However, they do not have to be superstars.

Takeaways

  • Define team ground rules that lead to psychological safety, social sensitivity and equal voices.
  • Implement a commitment culture.
  • Create a team of T-shaped people covering the necessary skills.

We always feel like our teams could be organized better. How to organize teams in an optimal way is a common question in Agile organizations. A question we should always discuss and answer together with the people in the actual teams.

Here I will try to provide an overview of 5 possibilities for organizing teams and the main factors to take into account. Our main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Depending on our specific context one will suit our situation better than the other, or maybe we will come to the conclusion that we are so Agile we can leave the concept of team all together.

Component based teams: Component based teams focus on specific components in the product that do not deliver customer value in it. They are also sometimes called focus teams for that reason. The focus is usually necessary because of the use of very specific or exotic techniques. Learning the skills and expertise to work in these teams takes years so it is more logical to put experts together. We can compare this kind of teams with functionally specialized teams.

Feature based teams: Feature based teams focus on a specific customer feature or feature areas within a product. For example: search optimization in a web-shop, or payments and conversion. Feature teams are necessary if the product is too large for a single team to optimize or when a single larger base product is differentiated into various market segments in retrospect. For instance, the same web-shop product can be differentiated for selling kitchen appliances, or tailored for selling TV sets.

Product based teams: Product teams carry responsibility for the entire product or product/market combination. This means all of the skills and expertise necessary to develop and run the product reside within the team. Product teams are therefore suited for smaller products with a relatively small feature set. That is why we often see these types of teams in start-up settings. When developing our new product, we do not want it to be complex and we will have a limited feature set if not a single one we want to validate first. Once the product matures, team orientation eventually changes towards feature teams to excel in feature performance and fulfilling customer needs.

Other factors to take into account: There are a number of other things to take into account when discussing team organization with the teams. These are: responsibility, coordination and sustainability.

Responsibility does not decrease or increase given we work on a component or product as a whole. The person working on the component probably wants to do a good job just as well as the person working on ordering functionality. But the thing is, it is just easier to feel responsible for an end-result. The other question is, if we only have component teams, who feels responsible for the end-result?

Coordination is also something to take into account. The need for coordination increases from product towards component teams. Just think about all the planning, hand-overs and dependencies before a group of component teams manages to deliver the final product.

The final thing is sustainability. What if technology becomes end-of -life? Are we going to fire the entire component team? Do we want to split them up over other teams? Could they adopt a totally new technology, and would not this undermine the whole reason for forming the component team in the first place? Technological advance is moving faster than ever. We know that new tech will come and go so better stay as flexible as possible.

One good conclusion so far can thus be to avoid component teams as much as possible and move from product to feature teams when product scope and/or maturity increase.

Customer journey teams: Customer journeys are becoming more and more important in differentiating our digital product or services from the competition. It is not just the core product that matters, but more and more how customers can experience added value from that digital offering; from problem recognition, to orientation, to acquiring, to aftercare, to discarding or switching to a new offering. Teams aimed towards optimizing the customer journey, can therefore be very effective. Pretty much the same goes for a customer journey teams than for product teams though; if complexity increases we can have multiple teams, but eventually we will need team specialized in certain parts of the journey, specific actors, or channels to differentiate further.

No teams: But wait, there is more! Yes, people, because real Agility would be to self-organize in shapes and forms that simply work. Should not we let go of the whole concept of “team”? Should not we trust people to form groups that just tackle the challenges at hand, no matter what form or shape? Like a swarm of bees or a flock of birds. I sure hope to see this sometime! I would expect to see it in an organization operating in a highly volatile and competitive market where constant change is necessary to keep up.

To recap, our main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Do we want to push the boundary towards customer journey teams or maybe even dare to let go of teams? Whatever we decide, we should decide it together.

Agile Mindset

“Attitude to accept change is the foremost change that needs to be brought in for any change to survive.”

When you are trying to introduce Agile Project Development into your company or to a new team, it is important that you know how to make it work. More than the terms, practices, meetings and user stories, the Agile Mindset keeps the team on point and helps them self-manage even if they are not too familiar with the terms used in Agile.

During one of my recent conversations with few teams who were going through agile transition, I asked them what they understood by “Agile is about mindset change” which is a highly spoken tag line in the agile world. To my surprise, their faces looked blank.

We discuss and debate a lot on this. What behavioral and procedural changes will get us to a different mindset change? Do not we have a right mindset today? What is a Mindset? Why is this more important than the terms and practices of Agile on the habitual and personal level? Essentially a mindset is a culture that you implement with the incentive to accept or adopt the cultural norms. If you want to truly implement Agile, it has to become a part of your company’s culture. There could be many changes that need to be brought in at the team level, management level and overall organization level.

Let me mention here some of the mindset changes need to be achieved both in personal and team level:

Team looks at failure as a learning opportunity: One of the main concepts of Agile is that your working product evolves, improves and develops as time goes on. This means when a sprint fails, this simply means that there are more improvements to be made.

Team welcomes different perspectives and diversity of thought: The reason why you want a cross-functional team made up of senior developers and other experts is because you want them to have intense Daily Scrum Meeting discussions and self-manage. If they are all coders, all they will know is how to code. Putting in QA testers, analysts and other experts can produce wonderful results and add value to everything in the project. The industry is moving towards a T-shaped model. Developing T-shaped skilled engineers does not only mean technical skills but also soft skills and domain skills. Bringing the attitude to broaden an individual’s capability takes some effort.

Test First attitude: Test Driven Development is one of those difficult practices for developers to pick up. Adoption of TDD or ATDD is easier said than done.  Traditionally developers have written unit test cases that will comply with the code. How many times have they written unit test cases after the code was shipped? If you go by their words, there was never enough time for writing unit test cases. Asking them to think about different test scenarios (something that they can find very difficult to do), write test cases, then write code, keep refactoring (not just the code but the test cases as well) simply does not go well with them. ‘Am I now also supposed to do QA too?’ is the question they have on their minds. Who is going to give me that additional time to write those many test cases? Change is never easy.

People are having fun: Now, the definition of fun can be subjective but it is easy to measure and observe. When energy is high, people are motivated and they spend time with each other outside the Scrum or the office, you know that they are having fun with each other. If you chose a good team, the learning experience should also give them a lot to be happy about.

Collective ownership: Collective ownership not only in terms of code but for the overall quality is to be owned by the entire team. A developer should be ready to look beyond his code, and, when required, be able to contribute to other parts of the code base. He should be fearless in making changes in any part of the code. Similarly, QA should not be looked as only tester’s responsibility but as a team responsibility. QA is not to be left for later part of the release but needs to be integrated in the lifecycle right from the beginning. Such mindset sets the team to a perfect software delivery.

Individual heroism vs. team collaboration: Agile is a team game and there is no place for individual heroism. Team collaborates on all aspects of software development. Pair programming, cross functional teams, frequent communication between stakeholders encourages team collaboration. It is the team that succeeds or fails and not an individual. Know it all and letting the secrets go away kind of mindset is expected to be exhibited by an agile team.

Work pace is sustainable: The Scrum Burndown Chart is a great way to see if the pace you have set for your Sprints is right for the team. Late turnovers and unfinished items are indications that the pace is too fast or there are too many items. Early finishes means the pace is too slow or people are capable of more and are not challenged. The sustainable pace keeps people on their toes but at healthy stress levels.

Team members can accept change and adapt quickly: It is easy to spot the members who are going to have trouble keeping an Agile Mindset. These are the people who do not like changes or cannot handle evolving conditions well.

Team is brutally transparent: The Agile Mindset calls for team members to be transparent with their work—including failures. When a member is struggling, they have to admit it. Mistakes should be brought up in Daily Scrums to learn lessons and avoid it in the future.

People want and need to collaborate and communicate: Scrum Masters are simply facilitators. The members who have an Agile Mindset have the urge to interact with the team and self-manage.

Knowledge sharing is done willingly and freely: A truly Agile team wants everyone equipped to deal with problems and tasks. This is why knowledge sharing is a great indicator that the Agile Mindset is alive and well in the team.

Manager to Servant leadership transition: This is one of the toughest changes to achieve. I believe the culture of a region plays vital role in how smoothly this transition can be achieved. Traditionally, in our part of the world, there is some sort of social status attached while identifying oneself as a Project Manager as against Scrum Master. People feel more comfortable and less risky while they try to manage situations than letting it done by team members. Putting trust on team is a major deterrence towards achieving servant leadership role, not to forget that there are many team members who feel more comfortable in taking orders than exhibiting courage to take decisions.

Agile Retrospective is one of the best ways to convert a good team in to a great one. When we say retrospective, here is what we have in mind: A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole team learning, act as catalysts for change, and generate action. Retrospectives go beyond checklist project audits or perfunctory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so.

Suppose you are a member of a software development team. You are doing good work, but not great work. You are starting to see signs of interpersonal friction on the team, and some people you would like to retain on the team are dusting off their resumes. You know you need to adapt your practices and ease the interpersonal tension before things get worse. You want to introduce retrospectives to your team.

In internet you will find lots of new ways and new twists of old ways to lead a successful retrospective. But we should always return to the basic structure which we will discuss today. This structure can fit into an hour or expand to three days. You can add variety by adding new activities, but stick to this basic outline—this structure does what a retrospective needs to do. There are five steps which belongs to this structure.

  1. Set the stage.
  2. Gather data.
  3. Generate insights.
  4. Decide what to do.
  5. Close the retrospective.

Here is the timing for each step for a two hours long retrospective:

Action

Percentage (%)

Time (Minutes)

Set The Stage

5%

6 Minutes

Gather Data

30 – 50%

40 Minutes

Generate Insights

20 – 30%

25 Minutes

Decide What To Do

15 – 20%

20 Minutes

Close The Retrospective

10%

12 Minutes

Shuffle Time

10 – 15%

17 Minutes

Total

100%

120 Minutes

Set The Stage

Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective. And, it contributes to creating an atmosphere where people feel comfortable discussing issues. You can start with a simple welcome and appreciation for people’s investment of time. Restate the purpose of the retrospective and the goal for the session. Remind people of how long you will meet. Then ask everyone in the room to speak. When someone does not speak at the beginning of the retrospective, that person has tacit permission to remain silent for the rest of the session. Since the point of the retrospective is to help the group thinks and learns together, you need everyone’s participation. Next, outline the approach for the session. Time is precious, and people want to know that their time will be well spent. Knowing the approach helps establish that this would not be another aimless meeting.

Gather Data

It may seem silly to gather data for an iteration that lasted a week or two. But when someone misses one day in a weeklong iteration, they have missed 20% of the events and interactions. Even when people are present, they do not see everything, and different people have different perspectives on the same event. Gathering data creates a shared picture of what happened. Without a common picture, individuals tend to verify their own opinions and beliefs. Gathering data expands everyone’s perspective. You can start with the hard data: events, metrics, features or stories completed, and so forth. Events can include meetings, decision points, changes in team membership, milestones, celebrations, adopting new technologies—any event that had meaning to someone on the team. Metrics include burndown charts, velocity, defect counts, number of stories completed, amount of code refactored, effort data, and so forth. Encourage people to refer to team calendars and other artifacts—documents, emails, charts—to add to the picture.

Generate Insights

Now is the time to ask “Why?” and begin thinking about what to do differently. When generating insights, the team considers the data to identify strengths and issues from the previous iteration. Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deficiencies. Look for risks and unexpected events or outcomes. It is easy for people to jump to solutions once problems emerge. First solutions may be correct, but often they are not. The work of this phase is to consider additional possibilities, look at causes and effects, and think about them analytically. It is also a time for the team to think together. These insights help the team see how to work more effectively—which is the ultimate goal of any retrospective. Generating insights allows the team to step back, see the big picture, and delve into root causes. When you skip generating insights, your team may not understand how events, behaviors, and circumstances affect their ability to develop software. Time spent generating insights helps ensure that when your team plans an improvement, it is one that will make a positive difference.

Decide What To Do

At this point, the team has a list of potential experiments and improvements. Now is the time to pick the top items (usually no more than one or two for an iteration) and plan what to do. Your primary job is to provide structure and guidance for your team to plan experiments and actions. Sometimes teams come up with long lists of candidate improvements; but too many initiatives can overwhelm your ability to change. Pick one or two experiments for the next iteration. Help your team choose items that they can commit to and that will have a positive effect. If your team is recovering from a change that was stressful, help them choose something less complex this time. Taking action during the retrospective builds momentum. Whether you finish planning in the retrospective or incorporate actions into iteration plans, be sure that people sign up and commit to tasks. Without individual commitment, people assume that “the team” will do the task, and no one does it.

Close The Retrospective

All good things come to an end, even retrospectives. End the retrospective decisively: do not let people (and their energy) dribble away. Decide how to document the experience and plan for follow-up. Help your team decide how they will retain what they have learned from the retrospective. Track new practices with posters or big visible charts. Use a digital camera or hit the Print button on that printing white board to create a visual record. The learning belongs to the team, and team members: not the coach, not the team lead, and not you as the retrospective leader. The team needs to own them. Close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective. Before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective. “Inspect and adapt” applies to retrospectives, too.

Though I described five steps here but there is another sixth step which is the most important one. That is called “Follow-up”. You did the retrospective on Friday. Then you went home for the weekend. You came back on Monday and your boss is like we must build the product and deliver by this week. And you forget everything you discussed in the retrospective. Your only focus is to get the job done. So everything goes for a toss. So you must follow-up the decisions taken in the retrospective.

Retrospectives can be a powerful catalyst for change. A major transformation can start from a single retrospective. Incremental improvement is important, too. Celebrate it. It is more than many teams ever achieve.

DevOps is one of the hottest topics in the technical world for some time now. When I tried to dig out the real reason behind it, I came to know that it is because it hurts the most. I always believe that the thing you should fix first is what hurts you the most. Historically, the inability to produce code that our users wanted within budget and in a timely manner was the biggest pain.  Development took months, if not years, and at the end of all that time and effort, what we delivered was not what our users expected. Our development process had to be fixed first because that was what hurt most then. Because the process of software development was so bad, the quality of the code was also in question. So the need for innovation on the system side of technology work was increasing. And then a giant was born: DevOps.

When I tried to search and find out the real definition of DevOps, I found out hundreds of different ones. Some of them are really long. But if you ask me personally, I would go for one of the simplest ones to define DevOps.

DevOps is the union of People, Process, and Products to enable Continuous Delivery of Value to our End Users.”

The writer is very deliberate in the terms used in this definition. He chooses value over software. DevOps is not just automating a pipeline so we can quickly deliver software. Our goal is to deliver value. The term “End Users” was also very carefully chosen. The value we produce must reach our end users. If the value only reaches the Development and QA environments but is held up before reaching production where it can be realized by our end users, we are still failing.

It is very important to realize that DevOps is not a product. You cannot buy DevOps and install it. DevOps is not just automation or infrastructure as code. DevOps is people following a process enabled by products to deliver value to our end users.

The best way to define DevOps in depth is to use a parallel method to the definition of a similarly complex term, agile development.  Agile development, according to the agile manifesto, consists of four different “levels” of concern.

Agile Values: Top level philosophy, usually agreed to be embodied in the Agile Manifesto. These are the core values that inform agile.

Agile Principles: Generally agreed upon strategic approaches that support these values.  The Agile Manifesto cites a dozen of these more specific principles. You do not have to buy into all of them to be Agile, but if you do not subscribe to many of them, you are probably doing something else.

Agile Methods: More specific process implementations of the principles.  XP, Scrum, your own home-brew process – this is where the philosophy gives way to operational playbooks of “how we intend to do this in real life.” None of them are mandatory, just possible implementations.

Agile Practices: Highly specific tactical techniques that tend to be used in conjunction with agile implementations.  None are required to be agile but many agile implementations have seen value from adopting them. Stand-ups, planning poker, backlogs, CI, all the specific artifacts a developer uses to perform their work.

DevOps Values: I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service or software fully delivered to the customer instead of simply “working software.”

DevOps Principles: There is not a single agreed upon list, but there are several widely accepted attempts. “Infrastructure as code” is a commonly cited DevOps principle. I personally believe that DevOps at the conceptual level is mainly just the widening of Agile’s principles to include systems and operations instead of stopping its concerns at code check-in.

DevOps Methods: Some of the methods here are the same; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident response. The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies have not been well defined, for example.

DevOps Practices: Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a tool chain approach to tooling. Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.

In the end, DevOps is a little tricky to define, just like its older brother Agile. But it is worth doing. “I do what Scrum book says so I am doing Agile” is as erroneous as “I am using Chef so I am DevOps”. To be a successful Agile or DevOps practitioner it is really important to understand all the layers that go into it, and what a given DevOps implementation might contain or not contain. In the end, what DevOps hopes to bring to Agile is the understanding and practice that software is not done until it is successfully delivered to a user and meets their expectations around availability, performance, and pace of change.

In the course of my experience working with several teams in multiple complex projects, two critical truths have become clear to me. First, genuine teamwork in most organizations remains as elusive as it has ever been. Second, organizations fail to achieve teamwork because they unknowingly fall prey to five natural but dangerous pitfalls, which I call the five dysfunctions of a team.

These dysfunctions can be mistakenly interpreted as five distinct issues that can be addressed in isolation of the others. But in reality they form an interrelated model, making susceptibility to even one of them potentially lethal for the success of a team. A cursory overview of each dysfunction, and the model they comprise, should make this clearer.

FiveDysfunction

  1. 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.
  2. 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 discussions and guarded comments.
  3. 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 agreement during meetings.
  4. 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.
  5. Failure to hold one another accountable creates an environment where the fifth dysfunction can thrive. Inattention to Results occur 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.

And so, like a chain with just one link broken, teamwork deteriorates if even a single dysfunction is allowed to flourish.

Another way to understand this model is to take the opposite approach—a positive one—and imagine how members of truly cohesive teams behave:

  1. They trust one another.
  2. They engage in unfiltered conflict around ideas.
  3. They commit to decisions and plans of action.
  4. They hold one another accountable for delivering against those plans.
  5. They focus on the achievement of collective results.

If this sounds simple, it’s because it is simple, at least in theory. In practice, however, it is extremely difficult because it requires levels of discipline and persistence that few teams can muster.

Before diving into each of the dysfunctions and exploring ways to overcome them, it might be helpful to assess your team and identify where the opportunities for improvement lie in your organization.