A good Scrum Master is far more than just a servant leader and agile expert

After years of being a Scrum Master and watching other Scrum Masters at work, there are a number of traits that the best Scrum Masters share. These traits make the Scrum Master effective at serving the team and organization in their agile journey.

First, let’s set some basic assumptions. I assume every Scrum Master is familiar with the Scrum Guide. They should be able to facilitate the Scrum events, though to be a good Scrum Master, they should be able to facilitate any type of meeting (with some preparation). A Scrum Master should also be able to explain the reason behind why things are done in Scrum, in order to coach reluctant team members. The Scrum Master should know enough of Scrum to mentor the team on it.

Servant Leader

Servant Leadership has almost devolved into the cliche management terminology world, like ‘strategize’. Servant Leadership looks different to many people, but I prefer to return to the root of the concept, which was inspired from the short novel “Journey to the East”. In this novel, one person ‘serves’ a large group as they embark on a spiritual journey. One day, that person vanishes and the group falls apart. Only later does the protagonist of the story realize that subtle leadership that the ‘servant’ provided. Futurama captured this sentiment when they ended an episode with the quote “When you do things right, people won’t be sure you’ve done anything at all.”

A servant leader combines elements of both words. As aservant, they help the team by being available and helping when asked. But they are also a leader, and specifically help their team by serving them in things that fulfill their vision. A Scrum Master, as a servant leader, will help a team schedule and facilitate a design meeting if asked. A good Scrum Master will place boundaries on these asks. For instance, if asked to facilitate a discussion that would violate one of the core tenants of agile, they should instead coach the team on the importance of those ideas.

Coachable

A good Scrum Master is a coach. But to be a good coach, they first must be someone who can be coached. Not every person is open to being coached. Some become set in their ways. Others become so sure of themselves that they shut themselves off to learning. Still others will listen to books, videos, or blogs, but will resist in person coaching. In each situation, a person shuts themselves off from vital resources and potentials for growth.

Growth Mindset

A Scrum Master must have a growth mindset - the belief that they and those around them can grow and learn - that things can be better tomorrow than they are today. A Scrum Master with the opposite view, fixed mindset will struggle to help their team continuously improve, and may see an end to the team’s agile journey.

Observant

To counter resistance to change, I look for a Scrum Master to be observant. They should be able to pick up on subtle hints that things aren’t right and when the timing is appropriate, shine a light on the problem. Observational skills come in many forms - using metrics, reading body language, conversations with the team, and chatting with stakeholders. A good Scrum Master is always collecting data, data that they can later use to coach the team to improve further.

Drives relentless improvement

A good Scrum Master knows that a team’s growth never ends. They will always find ways to improve, even if the team has been together for a long time. They balance their own observations and those that the team identifies. A great Scrum Master may be so subtle in their sharing of their own observations that the team isn’t even aware that the observations came from the Scrum Master.

Emotionally Intelligent

A great Scrum Master is emotionally intelligent, knowing how to regulate their own emotions while observing the emotions of others. They use these skills to note when things are left unsaid. They help the team understand their own emotions and help them express those emotions and thoughts to stakeholders and leaders in constructive ways.

Agile Expert

A good Scrum Master will know Scrum inside and out, but will also know when to apply it and when it won’t work. They are aware of other agile frameworks, techniques, and tools and know when best to apply them. For instance, they know that Kanban works better for a production support team than Scrum.

Specialist

A Scrum Master beyond an entry level position should have their own area of mastery. This is an area where they possess more skills and knowledge than their peers. This may be based on their natural talents, like building teams or facilitating meetings. It could be from a skill in their previous job, such as software engineering, quality assurance, product ownership, or project management. Having a speciality can help the immediate team, but also the larger agile organization by bringing insight to share with other Scrum Masters.

Adaptable

Finally, a great Scrum Master should be adaptable. They should hone their style to the team, not force the team to work within the Scrum Master’s style. A great Scrum Master will also vary the level of their coaching and the type of coaching based on where the team is. An anti-pattern in Scrum Masters is the so- called ‘Scrum Mom”, a Scrum Master who does many things for the team so they don’t have to. This may be useful for a team brand new to Scrum, as it shows the team how to do Scrum. To a well-seasoned team, a Scrum Mom is a bottle neck and has become the lid on the team’s performance - they can’t do any more work than what the Scrum Master can do. A good Scrum Master must embody the very thing they are coaching their teams to do - agility itself.

Conclusion

In short, a good Scrum Master is a servant leader, can be coached, possesses a growth mindset, is observant, is relentless in their pursuit of improvement for the team, is Emotionally Intelligent, knows not just Scrum inside and out but also other agile frameworks and tools, they have their own area of competency, and are themselves adaptable.

If you’re looking to improve your own skills as a Scrum Master, consider how you rank on each of these attributes. Consider how well each of the areas describes you. Beyond that, how likely are you to act according to those descriptions? What’s the percentage of time you exhibit a growth mindset vs. a fixed mindset?

To show up as an expert, know your process and exude confidence in your skills

There’s a story of a carpenter who was called to fix a squeeky floor. Entering the room, he made a quick inspection, pulled out a hammer, and struck the timbers in a single stroke. He stood, tested the spot, and proved the squeek fixed. After short work, he charged $100 for his efforts. When pressed why it cost so much for such short work, the carpenter replied he charged $5 for swinging the hammer and $95 for knowing where to swing.

A YouTube channel called Druneo has a series of videos where they put drum experts to a daunting test. The setup is simple. Take a drum expert, a full drum set, and a song the drummer is unfimilar with and given them a few minutes to listen to the song once. Then they ask the expert to play the drums to the song.

One of my favorite videos is this video where Larnell Lewis, who is known for his work with Jazz and Jazz fusion bands, plays Metallica’s “Enter Sandman” after listening to it for the first time. Watching the video, he explains his process as he listens, working to understand the form of the song, the pacing, the rhythm, and the elements of the drum kit he needs to use, when to use them, and how. What just sounds like banging and clashing to me, an expert picks up on the nuances of drums or cymbals used and any flourishes used on the original track.

Watching a master of their craft at work is a special sight. Through years of experience, an expert has learned how to do their craft well and fast.

The drum experts on Drumeo aren’t flawless and would change their approach given a second or third run-through of the song. No one expects an expert to flawlessly execute, but an expert does have to exude confidence they can tackle any situation. The drum experts on Drumeo also exude confidence. They don’t fret about the situation they find themselves in, Instead, they approach the challeng with their skills and a practiced list of steps to prepare.

Are you an expert in your craft? How would you fare if you were placed into an unknown situation and tasked with executing your craft? Are you able to enter the situation and with disciplined, practiced preparation, exercise your skills and produce? If not, what do you need to practice in order to reach that level? Here you outlined foryourself the steps would you follow in order to prepare like a drum expert?

Experts dazzle us with their skills. If you aspire to be an expert, keep honing your skills until one day you dazzle someone else. Perhaps one day, someone will look at you the way you look at an expert today.

Follow a 2 to 1 ratio to prepare for successful Meetings

When in college, time management is crucial. For many students, college is a culture shock. It is the first time they are on their own. One has to learn how to manage their own time amongst the complexity of their classes.

To guide students through this, a common rule of thumb is to plan to study for a class 2 or 3 times the number of credit hours it’s worth each week. So a student taking a 3 credit hour class should study 6 to 9 hours a week on that class in addition to the class time.

This handy rubrick has stuck with me over the years. I apply this to any classes I take as an adult. As a meeting facilitator, I’ve taken the novel approach of applying this to meeting preparation. I’ve found a 2 to 1 ratio to be a useful guide to manage my time in preparing and summarizing meetings.

Applying the rule is simple. Take any meeting and consider how long the meeting itself is. Then I double the time and that is how long I should spend up front to prep for the meeting. So if I have an hour long meeting, I spend 2 hours preparing for it.

This preparation time includes

• solidifiying and recalling the meeting purpose
• finalizing the agenda
• considering how I want to show up for the meeting
• facilition methods I need to prepare
• consider any landmines I may face in the meeting
• setting up the physical or virtual space
• reserving time for follow up after the meeting

We can’t apply this role to every meeting we facilitate. If we did, we’d be limited to about 12 hourss of facilitated meetings a week if we did nothing else. If you are struggling in your facilitation, consider if more preparation would help and apply the 2 to 1 rule for your crucial meetings.

Being a Servant Leader is not about being a servant

Servant Leadership is a common strategy employed in software engineering departments. Popularized by the agile movement and the establishment of Scrum Masters and Agile Coach’s as servant leaders for a team or the organization, servant leadership aims to empower teams and aid them in service to the team’s goal. Originally coined by Robert Greenleaf in the 60’s and 70’s, many thought leaders such as Ken Blanchard and John C. Maxwell expanded on the concept. One of my favorite books on the subject, edited by Ken Blanchard and Renee Broadwell is Servant Leadership in Action which includes essays from dozens of leaders on different aspects of servant leadership.

One concept that is overlooked on the subject is the duality of servant leadership. Too often I see people dismiss or poorly implement servant leadership because they focus on the servant part and forget about the leadership piece. Being a servant is about taking orders, doing what is asked of you, and being a support to those around you. These individuals miss the aspects of leadership of having a vision, leading from out front, and being proactive. A servant leader. must serve, but they must also serve according to a vision. A servant leader must posses both sides to be a true, effective servant leader.

Another new name for an old idea

In recent weeks, a new term has surfaced to describe a trend taking place in corporate America - Resenteeism. Just as with Quiet Quitting, workers who exhibit Resenteeism are putting in less effort than they once did, meaning they aren’t as productive and effective as they once were. The trend resenteeism takes its name from the resentment at the underlying core of the behavior that is observed.

What separates Resenteeism from Quiet Quitting is that the latter focuses on the end result - doing less work - while the former calls out the cause - resentment for how one is treated at work or as a reaction to one or a series of events.

In my previous post on Quiet Quitting, I outlined three causes: poor work environment, poor return on investment (ROI) for one’s effort given, and one’s purpose lies outside of work. Resenteeism can arrive from either a poor work environment or a low ROI on extra effort expended.

Poor working environments, which often arises from a lack of respect for people, will often lead to feelings of resentment. While some can suffer from a poor working environment stoicly, others will let months or years of disrespect build into resentment.

Workers putting in less effort due to a perceived poor ROI may do so for a variety of reasons. It might be due to an emotional response. It could also be a calculated, logical response after working hard for little reward. From the outside, one might attribute the behavior to resentment.

Resenteeism sounds like a new trend, but it’s just a new interpretation of the ‘Quiet Quitting trend we’ve seen over the past few years. Yet, as I shared in my original post on Quiet quitting, this trend is not new, though is more widespread. Understanding the underlying cause can help go a long way to overcoming this trend, but overcoming it will require concerted effort from leadership.

One skill separates successful leaders from the rest

People are promoted based on their ability to wow leaders. Their skills at an individual contributor level is impressive enough to lead to a promotion. But success as an individual contributor does not guarantee success at the next level.

Within a hierarchy, people tend to be ‘promoted to their level of incompetence’. This is known as the ‘Peter principle’, a concept popularized in the late ‘60s and ‘70s by Laurence Peter. In my experience, those who struggle with leadership responsibilities may have the IQ it takes to do the role and their previous role, but lack the EQ, or Emotional Intelligence, that it takes to lead others.

Make no mistake, stepping into a leadership role requires intelligence and skill. But that’s just the entry fee one is expected to pay to be a leader. But EQ is the one skill that makes the most successful leaders stand out from the others.

Unsuccessful leaders may appear successful for a time. Being promoted based on their skills may mean that they are adept at managing expections of one’s leaders. This is not a bad skill to have. We should all strive to keep our leaders informed of our movements. But when this is the only skill one brings to the table, that will not lead to long term success.

It’s been said that we model the behaviors that we observe. Leaders tend to mimic the patterns of communication they themselves observe. If a leader is surrounded by positive examples, then they may make do with the skills they have, for a time.

A leader with high emotional intelligence, and specifically, high self-awareness, can sense the patterns they are following and can choose to follow a different path. Self-awarenss is crucial in understanding where one’s strengths and weaknesses truly lie. As one leads others, self-awareness is key in gauging one’s progress and improving. The world around you is giving you feedback on your performance and a person with high EQ and self-awareness can leverage that feedback to improve themselves much faster than any manager-lead feedback cycle.

Let a little SPIDR help you break down User Stories

In modern Software Development, User Stories are ubiquotous. They are the core building block of anything that we build. User Stories are the fundamental item upon our entire backlog is built from. It’s for this reason that a team needs to have the best user stories possible. If teams have poor user stories, everything else they build on top of the user stories will tend to be poor too.

The first step to crafting the best user stories is to ensure they meet our own definition of a user story. Common industry practice is to ensure that user stories meet the ‘INVEST’ criteria.

• Independent
• Negotiable
• Valuable
• Estimatable
• Sized Appropriately
• Testable

The second key step is creating user stories that are sized appropriately. This can be challenging, especially since we’re aiming to make them Indpendent and Valuable at the same time. There are many different ways in which we can divide a user story down into smaller parts. Mike Cohn introduced a handy acronym SPIDR that captures the 5 main patterns for splitting a User Story. Any method of dividing a user story that I’ve encountered could be described by the SPIDR acronym, making not only a simple reminder, but also an exhaustive one.

Spikes

A Spike is a user story where the output of the work is research. The outcome is increased understanding and reduced risk for further work to come. Teams cannot know every aspect of the system they are building, and so they may decide to take some time to research the system in question.

Other times, teams understand the system and the problem space, but may have a few different ideas on a solution. Here a Spike to create a Proof of Concept (PoC) can be valuable use of time and help the team to select a path for their solution.

A good practice that I suggest teams follow is to time box their Spikes. Estimating how long it will take to research a system can be difficult. Research tends to follow many deep rabbit holes. Having a time box for the spike can provide just enough time pressure to ensure the research is valuable.

Spikes provide a different kind of business value than user stories. They are more about reducing risk and making decisions then they are about delivering a product to a user. As such, they should be used sparingly. Despite Spikes being the first letter in the acronym, I suggest it be the last resort a team reach for when they split out stories.

Paths

In many software systems, there are many paths a user can take to complete a given task. When the work is large or complex, it can be useful to split user stories up by these paths, delivering the most common path first and then adding the functionality to other paths in the system later.

Interfaces

In complex systems, we often have many different tools that provide the same or similar functionality. Companies may support a website and a mobile application at the same time while having an internal tool that displays the same information or provides the same functionality. Splitting the work by each of these user interfaces can be an effective way at dividing the work into small, actionable chunks of work.

One can also split user stories by persona, or the user who is doing the work and is impacted by the change. Different personas may use different interfaces to do their portion of work. You may choose to split the work down based on the personas, allowing the team to deliver a solution per persona in an iterative fashion.

When thinking of interfaces, teams should still strive to craft vertically sliced user stories. This guidance does not suggest that teams split user stories up by the architectural layer of the system that the work needs to touch. Each story that builds out a unique interface should still contain any backend changes that are necessary to deliver the functionality to the user. That said, the first interface will often be larger as it will create some of the common backend functionality that subsequent user stories will leverage.

Data

User stories operate on data elements. When we have multiple data elements, creating a user story for each different data element can be an effective way to slice the work into small managelable chunks.

Leveraging a Data split can be prone to “throw-away” work, as the team will need to progressively build out APIs and other backend systems to deliver each of the data elements. If it is not too much effort, teams could attempt to fetch all of the data elements in the first user story, but care must be taken to keep the initial story small and focused, else teams will fall back into one giant user story with all of the data points.

Rules

We have to implement business rules into our system in order for the system to have proper constraints on what the user can and cannot do. When we have many business rules to implement, dividing the work by these business rules can be an effective and simple way to divide a large body of work into small chunks.

Conclusion

SPIDR (Spikes, Paths, Interfaces, Data, and Rules) is a simple way to think about dividing work into smaller user stories. Small user stories allow us to iterate faster, deliver faster, and get feedback sooner. Any user story we create is a hypothesis of what the user wants and is only proven valuable until delivered to the user and measured. By crafting small stories and prioritizing based on what we think is most valuable or by what allows us to receive feedback sooner, we can ensure rapid, valuable delivery to the client. All the while, we must remember to keep our stories vertically sliced, so that each story on its own is Independent and Valuable.

As John C. Maxwell says, everything rises and falls on leadership.

We are in the middle of an epidemic, as business news reports. In 2022, “Quiet Quitting” became a hot topic as workers on social media discussed the new trend in the workplace. Then, news media picked it up and spread to most of the major news reporting sites as the big trend impacting labor.

Quiet quitting, if you are unfamiliar with the term, refers to a worker choosing to put in less effort today then they did yesterday. This can take many forms, such as working fewer hours, doing the bare minimum, or simply no longer going “the extra mile.”

“Hopefully, it [the Pandemic] will force us to focus on what is trule important to each of us,”

I wrote that in my journal on March 14, 2020, the day after I was sent to work from home in an effort to “flatten the curve” of Covid cases.

I see signs around me that many of us did indeed find or rediscover what is truly important to us. Many people picked up new hobbies. I, like many others, rediscovered Bob Ross and the Joy of Pointing. My wife returned to her passion of reading.

In 2022, we saw 2 trends that continue this theme of pursuing what is important to us: the great resignation and quiet quitting. The great resignation dominated the headlines in the first half of the year and represented a massive shift of people in roles, companies, and industries.

But my main curiosity is the other major career trend of 2022, Quiet Quitting” - the term used to describe individuals who were putting in less effort at works within their some role. What causes quiet quitting? I See 3 Candidates: work sucks, one’s ‘return on investment’ for their extra effort, and key to my original hypothesis, the pursuit of one’s passions outside of work.

Work Sucks

Social media and Subreddit, like r/antiwork are an outlet for those encountering poor leadership. Bosses who demand remote employees have their cameras on all day while they work, others who require the use of a 1⁄2 PTO day if one works from home. Leaders who state that “we’re like a family” but don’t hesitate to part with family during an economic downturn. Companies that revert pay to minimum wage for workers who quit without a two week’s notice. Governments working to strip unions the right to strike. Bosses who report employees to HR because they did not respond to texts while on vacation. A boss who rewarded hard work with an extra 10 minute break - that has to be Coordinated 24 hours in advance, that can’t be added to a regular break and that expires in 30 days. And all of this on the homepage of the subreddit on one day.

As a leader and an agilist, I see a common thread in all of this: the lack of respect for people. We all deserve respect as fellow human beings. Of these who have been disrespected by a leader, quiet quitting can be an emotional response to the situation. We each strive to have some balance in our lives. To exert some sense of control. And when we feel slighted, human nature responds with a ‘balancing of the scales’. “You interrupt my personal time, I’ll slack off at work to make up for the time lost.” “You disrespect me, then I’ll give you the same level of respect in return.”

With those who ‘quietly quit’ because ‘work sucks’ we have a leadership problem and that starts at the top and filters all the way into the front line managers. To combat ‘work sucks’ we need to raise the level of leadership, and that starts with a simple respect for people.

Return on Investment

Every day, people go to work and “go the extra mile”. For some, they are driven by an internal fire. They’re found their calling. For others, they are extrinsically motivated, hoping to get to the next level. But is that next level worth it? For some who choose to go the ‘Quiet Quitting’ route, it may be a very logical decision instead of an emotional one.

Time is a precious resource, one we only have so much of. Is ‘giving 110%’ in hopes of a potential reward a smart investment? For those who put in the effort, it may be a good use of their time. Others may have done the math and decided their time is better spent else where, with family, with a hobby, or with their own passions.

Passion

‘Ryan Daniels was an account executive for a major adentising agency. “and by the time he was forty, he had a very high- paying job that demanded seventy-hour weeks with a bonus of unrelenting stress. […] He moved to a much smaller company where he could, in his own words, “coast” and still excel.” Ryan used this freed up time to explore his passions and spend time with his family.’ And Ryan did all of this before the internet.

Ryan’s story comes to us from Bob Bufford’s 1994 book “Halftime”. In it, the author spoke of taking our mid-life and heading into halftime to plan and uncover the one thing we decide to “put in the box” and hang our personal passions on for the 2nd half of our life. It speaks of finding our calling, either in our work, through a career change, charity work, or through pursuits outside of work.

In this last example, he offered the “half speed option”, where one intentionally works less, either by switching to a less demanding and stressful job or by cutting back on one’s efforts at work by volunteering for less, being more efficient with one’s time, or by lowering one’s standards on the work they do, striving for doing acceptable instead of outstanding work.

I share this because while “quiet quitting” is a new term, it is not a new concept. Inherent in all of us is a choice of what is significant for us. Many choose work as this item of significance. But drastic life changes, like a pandemic, causes one to reasses what is important in life. Among the top regrets of the dying, no one said they wish they worked more. In fact, the number three regret is that they wished they worked less!

Conclusion

Quiet quitting is not a new concept, but it may be gaining in popularity. I believe there are many cases of this trend and the pandemic served as a catalyst. American culture is shifting, as it always has. Hard work is not valued as highly as it used to be, from my vantage point. And factors such as poor leadership, low ROI on putting in extra effort, and people choosing to follow their passions, have all led us here.

What can we do about this trend? It starts and ends in enlightened leadership. It starts with leaders who can connect people’s passions to their work and who offer people respect. To punish, bemoan, or micromanage employees because one suspects their people are “quiet quitting’ will only fan the flames.

To quote John C. Maxwell, ‘everything rises and falls on leadership’. If this problem exists in corporate America, then it was caused by the leaders in corporate America. Yet here too is where the problem can be reversed.

If a leader makes a decision but does not communicate it, did they really make a decision?

The above question may bring up images of buddhists monks asking questions like “What is the sound of one hand clapping” or “If a tree falls in a forest and no one is around, does it make a sound?” On the surface the well known question involving ill- fated trees, it seems a bit absurd. Of all the trees that have ever been cut down and observed, has any done so without making noise? As far as we know, there’s never been a silent tree falling.

But the question forces us to return to the definition of sound, which dictionary.com defined as

“the sensation produced by stimulation of the organs of hearing by vibrations transmitted through the air or other medium”

While a tree falling would in fact create vibrations in the air, by this definition, no sound would be produced since no ears (“organs of hearing”) would be around to detect it and create the sensation we interpret as sound. Careful examanition of the definition of sound gives us an interesting answer.

Which brings me to my leadership question for this article: if a leader makes a decision but doesn’t communicate it, have they really made a decision? A decision implies action. In a business organization, can action be taken without communicating to others? Perhaps, or perhaps not. It may depend on the nature of
the action.

While the true answer to my question may be nuanced, just like the question of the falling tree, its intended to make you consider. If you make a decision, who needs to know that you made the decision? What public action must you take in order for others to understand the decision you made and its ramification on the organization? Decisions are not made in a forest where no one else is around. Decisions are made within the confines of an organization and will impact it.

Next time you make a decision, consider the falling tree and ask yourself, who needs to know that I made this decision?

Dysfunctional Teams tend to be dysfunctional in the same 5 ways

Teams of all levels, whether on the front lines with a team of individual contributors, or a team of executives working together to run a business, suffer from common dysfunctions. In 2002, Patrick Lencioni introduced the 5 Dysfunctions of a Team model in his book of the same name. These dysfunctions build upon each other, like a pyramid. We must resolve the dysfunctions at the lower levels before we tackle problems at a higher level. Just like in the construction of a building, the foundation is the most crucial piece. However, all levels are key to a well functioning team.

Lack of Trust

Trust is key to any relationship. When we bring many people together, each person has a relationship with everyone else in the group. While it may not be possible for everyone in the group to have high trust in eachother, a significant lack of trust will result in suspicion and a “trust tax” that the group will suffer from, slowing progress of the team.

Fear of Conflict

Some people naturally avoid conflict. They have a strong avoidance of it. In a team, healthy conflict, rooted in respect, is crucial to creativity and solving problems that the team will encounter. Most teams exist to solve problems and they will be hampered at their problem solving ability if they avoid conflict.

Lack of Commitment

A successful team needs everyone working together to achieve the goal of the team. If one or more team members aren’t committed to the goal, everyone suffers. The team may not operate at its full potential, other team members may have to work extra, or the uncommitted team members could be disruptive to the goal of the rest of the team.

Avoidance of Accountability

On a team, each person brings a unique set of skills and experiences. Together, the team can leverage their skills and expertise to achieve the team goal. Only, that is, if everyone is accountable to their part and the team. If team members avoid accountability, others will not be able to rely on them and their contributions.

Inattention to Results

Only in the final dysfunction do we consider the results of the team. So many other behaviors are necessary before we consider ‘are we successful?’

If we are inattentive to the results of our team, then we are missing an opportunity for feedback. We miss recognizing when we are failing to deliver, but we could also miss out celebrating our successes. This behavior could lead to burn out, which could be equally detrimental to the long term longevity of the team.

Bringing it together

One key use of the 5 dysfunctions model is in launching a team. One should start by establishing trust, and no, trust falls are not the answer.

Next, teams should work to establish how they will work together and handle disagreements. There will be disagreements and it is best to establish how to approach and resolve conflicts before one emerges.

Then, as we kickoff a new team, we consider what our purpose is, how we contribute, and ultimately build towards a commitment to the team’s success.

As we discuss how each person contributes to the team’s success, we should be explicit in what each person is accountable for. Spell out what each person can expect from each other and we know who is doing what.

Finally, a team launch that is anchored in the 5 dysfunctions will consider what success for the team looks like. Consider how will we measure our success? How often will we check in with these measures? How will we make these measures actionable?

While the 5 dysfunctions of a team is a useful model for new teams, it is tremendously helpful for existing teams to determine where the team struggles. If you sense your team is struggling in one or more areas in this model, try this exercise. First, introduce the model to the team and explain each level, drawing the pyramid as you go. Then, invite them to put a sticker or mark on the layer they think the team is currently struggling with the most. Next invite the team into a discussion around the results, asking for observations that confirm or challenge the results. Finally, consider how you’ll tackle this dysfunction as a team to get better.