Becoming a high performing team is not a straight line, it’s a journey. By being more aware of where the team is along their journey, you’ll be better equipped to help; whether it’s through teaching, facilitation of a startup or reset, coaching in the moment or other approaches.
The Tuckman’s Team Development Model offers a window into the Team journey as a series of stages. These stages include Forming, Storming, Norming, Performing and more recently, Adjourning and Transforming.
If you’ve read or watched the Lord of the Rings Trilogy, it describes the archetypical Hero’s journey. Here’s a recap of the stages as it relates to the story (Please be advised, there are spoiler alerts ahead).
Forming
The Tale begins in a small village full of Hobbit people. The setting is cast in beautiful lush green pasture-land with rolling hills. There’s a sense of curiosity and wonder about the place.
The characters don’t necessarily know each other well, or at all. However, they share a common connection through their friend Gandalf the wizard whom they admire. You can call him the Agile Scrum Master or Coach.
Soon an evil arrives and threatens the land. Gandalf makes it known to the villagers that they must act to stop the forces in order to survive. He assembles a group of volunteers to combat the evil presence, and they embark on their long journey.
Here it can be helpful for teams to get clear on their shared goals, values and agreements. The earlier they can get to know one another and identify their preferred ways of working, the sooner they can move forward in service of becoming a high performing team.
Storming and Norming
Along the way, the protagonists have petty squabbles with one another. They bicker at times and form camps. Trust is low.
While the group is trying to figure out how to work together, Gandalf, one of the strongest protagonists unexpectedly dies while protecting the group from an attack.
The group realizes that if they continue to operate as they have, that they will not be successful and the world will be lost.
If you find that your teams are going through a period of conflict, know that they have actually moved forward. In service of helping the group, this could mean staying neutral and providing room for the group to work through things on their own, sharing that this is a natural part of becoming a team, or by facilitating deeper conflicts where appropriate.
Performing
Here it becomes evident that the company now is truly working as a team. They share a collective goal. Selfless behaviors are emerging. They are operating more synergistically.
At one point, one of the characters is carrying another up the mountain because they are unable to continue themselves.
Together, against many difficult odds and obstacles the team defeats the great evil and returns back to the place where they started.
Adjourning and Transforming
While the characters in the same place they started, they are not the same people they used to be. They have all been transformed internally. There is a collective sense of accomplishment paired with a bittersweet, melancholy. This is goodbye for some, and for all a goodbye to what was.
There is a sense of optimism and excitement for the next adventure or calling ahead combined with a sense of angst and uncertainly of what lies ahead.
Takeaways
A high performance team is magical, when it happens. However, getting there is not. Becoming a high performing team involves a concerted journey that takes awareness and effort. If you can discern where teams are along their path, and better yet, help them to detect their own stages, you’ve already stacked the odds in favor of success.
Think of a time when you’ve been a part of a strong team. Can you recall where there were major challenges and breakthroughs? What happened?
How does this fit in your current context? Can you identify where your team might be today?
What is one of the most amazing teams you’ve been a part of? And what made that experience stand out?
Growing up as a kid, my father used to take me to basketball games in the Oakland Coliseum to watch the Golden State Warriors play. Back then, the Warriors were good. That was before they were mediocre, and before they were good again. It was one of my fondest early memories of teamwork on display.
Regardless of where your heart lies, it is hard to argue, the Golden State Warriors are one of the most dominant teams in sports today.
So what makes a team great? What’s that “secret sauce” that sets them apart from others? If you’re curious, read on.
High performance Agile teams exhibit teamwork
More and more today, organizations are incorporating team-based structures as the standard for getting work done.
Science shows the significant benefits of organizing as teams, including the improved ability to solve highly-complex problems, better morale, productivity, higher quality and ROI. However, the reality is that many so-called teams are really operating as groups.
So what is the difference between a group and a team?
A group is a collection of individuals who share individual goals, but the ownership of goals resides on each individual.
A Toastmaster’s club, for example, is a group. Each person has an individual goal of advancing their own public speaking skills and they join the organization as means to support their ends.
A group might be a Community of Practice, where individuals come together to share resources for the benefit of learning. Each individual is responsible for growing their professional skills.
In a sports analogy, this might equate to a group of talented players who are assembled but generally are more focused on their individual stats. They optimize for more time with the ball in hopes of landing a big contract with the next high paying team in the future.
Conversely, a team is a group of people who own, and are collectively responsible for achieving a goal.
As such, the outcome falls squarely on the team, as opposed to the individual. The game is won or lost for the team. In many cases with high performing teams, there is a willingness to trade individual heroics for the betterment of the overall goal.
In basketball, we might refer to the collective goal as winning a championship. In team behavior, we see things like assists. That is a stat that represents passes to other team members resulting in a basket.
In Scrum, we have the concept of a sprint goal. The sprint goal is an increment of useful product functionality that is planned out by the team. It results in something valuable that is delivered to the customer in four weeks or less.
And so teams are looked at as collectively contributing to a worthy goal which is often too difficult to be accomplished by an individual alone.
In the best case scenario, groups may create a mutually beneficial structure to achieve their individual goals but teams will often fail to produce strong results if they operate as a group.
In a team, the model breaks down when:
There is a lack of urgency or compelling vision behind the team goal
The team goal is not clear or well understood by the team
There is disproportionate incentivization on individual contributions vs. team contributions. Conflicts of interest arise and the team will fail to collaborate sufficiently to meet their goals.
There is a lack of trust or safety.
While this may seem straightforward, it is not uncommon to see group dynamics play out in organizational teams and cross-departmentally. The culture of “Business vs. Technology”, or “Us versus them” is generally an indicative symptom of the problem.
High performance Agile teams focus on developing their capability over achieving specific results
High performance Agile teams see themselves as a capability to be developed. They favor this paradigm over short term result seeking. And they invest their time and energy accordingly.
If you had the option of picking one of the following, which would you choose?
Creating a playbook that can solve a specific problem
Creating a playbook that allows you to create any number of playbooks
In number one, we are more focused on planning for and winning individual games with the key individuals and their roles.
In number two, we are more focused on instilling a mindset and developing the capabilities of the team so that they are better positioned to handle anything that comes their way.
It is not uncommon for the Warriors to play younger, less experienced players, even in higher stake game situations. They are willing to risk losing a single game because they know that they are developing and deepening their bench. The hope is that by developing the capability of the team, it will create more favorable circumstances for winning in the long run.
By internalizing and embodying the values and principles, or the “being” side of Agile, teams are in effect taking on the “playbook of playbooks” model. Moreover, teams that understand the line of thinking, or the “why” behind the Agile practices will produce far greater outcomes. However, internalizing the agile mindset takes time, energy and practice and teams can benefit from the help of an agile coach.
High performance Agile teams show humility
Make no mistake, the Golden State Warriors have a certain swagger about them. Are they confident? Yes. Are they proud? Most definitely. But they put humility on display, especially when it comes to highlighting their teammates’ contributions.
When you look at the players during the press conferences and in half time interviews, you often hear players deflecting questions about their individual contributions to those of their peers or their teams.
Here is one example (paraphrasing):
Interviewer: Steph, you did a great job scoring to close the gap at the end of the second half to win the game. What was going on in your mind to do that?
Stephen Curry: ‘Actually, I thought we could have done better offensively overall. Our defense really shined there. Green was able to convert most of the opponents shots into rebounds and pass the ball around to create the right opportunities to allow me to take those shots’.
High performance Agile teams exhibit a strong internal mindset
There are points during the game where the team looks like the deck is stacked against them. For the Warriors, it’s not uncommon to see them going into second half with a deficit of 10 points or more before coming back. Everything seems to be going badly and fear sets in.
In that moment, it is easy for anyone to lose presence, to give way to the downward pull of defeat. Where it would be game over for most teams, the Warriors somehow draw from a reserve of internal strength and recover.
The Warriors return to a place of poise and presence. They don’t let setbacks get the best of them. Yes, the team has a collection of skilled and capable people. And they do show a high degree of emotion and intensity at times. But what we are looking at here is how they choose to act in the face of adversity. What we are talking about is a strong mental attitude.
However, this is not just about shared attitudes. With a firm team structure in place, many fear-based behavioral risks are dispelled. This largely has to do with the sense of shared responsibility and psychological safety that true teamwork facilitates.
Tony Robbins talks about the importance of not assuming the victim mindset. When a team member is down, team members pull each other up. They have developed the ability to quickly reset and recover despite whatever challenges are being thrown in their direction.
The Scrum values
Some of the highest performing Scrum teams I’ve worked with exhibit a strong mindset by embodying the following values:
Courage – they draw on the collective strength of the team to overcome obstacles and challenges that would not otherwise be possible by any one individual
Commitment – they commit to doing everything possible to achieve their goals, supporting one another as necessary
Focus – they are clear on what it is they must do, they keep each other present, and focus on doing few things at a time
Respect – they treat everyone as an important part of the team regardless of experience or background, they aim to build leadership at all levels of the team. In fact, there are no titles within a development team in Scrum. Everyone is a “team member”.
Openness – they are not afraid to say the things that must be said, they show vulnerability and acknowledge their mistakes openly, they make their work highly visible, they are clear on their roles and will also step outside of their role as necessary to meet the goal of the team
High Performance Agile teams share leadership
Servant leadership is a philosophy whereby the main goal of the leader is to serve the people who work for them. This is in contrast to the traditional leadership model where leaders primarily serve those above. It might feel more akin to being under the wing of a life coach than a benevolent patriarch or matriarch. Some additional characteristics of this type of leader include vision, encouragement, empathy, influence (selling vs telling). Since they are always seeking to grow and improve themselves, servant leaders are generally higher on the Emotional Quotient. That is, they are highly present, are active listeners, and they are keenly aware of their own internal states and how it plays out in social relationships.
Among the very best teams, leadership is a shared practice. In fact, while watching the Warriors play for the first time, it might be hard to tell who is exactly in charge in any given moment. Steve Kerr, the Warriors’ head coach, established a strong leadership foundation. It allowed him to take a long leave of absence in order to recover from painful complications related to back surgery. The team sustained in the playoffs and went on to win the championship that year.
Some of the most effective Scrum teams that I have been a part of exhibit behaviors where someone steps in as a leader, then yields, and another steps in and takes their place.
In the book “Mastering Leadership”, Anderson describes the creative leader type as a developer of people. What we are talking about here is taking responsibility for helping others to grow and self actualize, both on a personal and professional level.
Steve Kerr is a fine example of a servant leader. As a former player himself, he has over eight championship rings. Yet he acts with poise, respect and humility toward others including opponent teams.
He shares a compelling vision for success, but gives the team room to make their own decisions which often comes with mistakes and failures. He models patience, trust and wisdom through his actions.
One of the twelve principles behind the Agile manifesto is to “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. Two of the four modern Agile principles simply state, “Make people awesome” and “Make safety a prerequisite”.
This relates to creating the environment where people are given training and latitude do the their jobs. It also means ensuring that team members feel completely safe to speak up and make mistakes without fear of retribution, and an environment where they are encouraged to share learnings and take those lessons forward.
In today’s volatile, uncertain, complex and ambiguous world, it is critical that we strive to bring out the very best in our teams.
How do you write and communicate effective Business requirements from an Agile standpoint?
I recently worked with a client who was interested in leveraging Agile to improve requirements writing and communication in her organization.
In the pre-call meeting for the class, she asked me, “So how do we establish good requirements between Business and IT? And how do we pass them along and not have to hear from the Business again?”
First, the good news is that there are tangible ways to significantly improve requirements writing and communication.
The second part of this question requires a bit of re-framing.
To expect that no communication is required from the business (or vice-versa) is not a realistic outcome. However, with the right structure in place, requirement communication and delivery will become a productive exercise.
So let’s dig in. Here are some ways to significantly improve requirements writing and communication.
1) INVEST in your requirements
Agile requirements use INVEST to improve writing
Requirements should follow the INVEST principle. That is, they should be Independent, negotiable, provide value, be estimatable, are about the right size so that they can be implemented by the team, and are testable.
2) Use a “card, conversation, confirmation” approach to agile requirements writing and communication
The most Agile requirements are written from the customer standpoint. A great way to apply this concept to requirements is to use the “card, conversation, confirmation” format.
Card: As a <customer> I should be able to <action> so that <benefit>
Conversation: Review the card with development team and cover questions. Aim to have conversations to flush out assumptions and mark as ready. Move on when the team unanimously gives a thumbs up confidence vote.
Confirmation: This is the acceptance criteria that must be met in order to sign off on the requirement. A good way to write acceptance criteria is to use a Gherkin format. Use the vantage of a particular customer/user.
Example: Scenario 1 – Given <a precondition>, when <action>, I should expect <result>
3) Choose the right level of granularity
Requirements should zoom into the right level of abstraction for the audience in mind. Make sure to keep the overarching goals in sight. Requirements should be born from a high level purpose. They should be increasingly broken down into more bite-sized areas for execution.
All of these levels are relevant since they connect strategy to execution. The levels should connect the why to the what to the how.
Initiatives – Organizational business goals (KPIs, Business requirements) Ie. Improve speed of content entry by 10% (Executive level)
Features – Highest level of requirements ie. Content Management and Publishing Portal (Executive-Program level)
Epics– functional requirements – ie. Content Entry (Program and Team Level)
Stories – (Team Level) More detailed but (INVEST) small, independent, valuable, estimateable, testable – entail a conversation, have clear acceptance criteria. Ie. Publisher uploads new science publication document.
4) Establish up-front working agreements for better communication
Agile talks about the importance of customer collaboration. There are two types of working agreements that help improve communication between business and engineering. These working sessions happen initially up front and are revisited periodically.
Draft a Definition of Ready
The Definition of Ready (DoR) includes all things that should be included in requirements before they can marked READY to be worked on by the development team. Some examples might include:
1) Clear acceptance criteria are in
place
2) The requirements include major
design assets
3) The requirements reviewed and acknowledged
by the team
Draft a Definition of Done
The Definition of Done (DoD) includes all things that must be completed before declaring the requirement as DONE (or “done done”). Some examples might include:
1) The unit tests have been written
and pass.
2) Test Coverage is 80% or better
3) The acceptance criteria have
been met
4) The requirement has been reviewed
and acceptance tested by the business owner
5) Take smaller bites
Often the pain associated with requirements is related to information overload. This is often where you may find requirements churn.
Break down requirements into smaller chunks that can independently provide business value. Leverage the INVEST criteria. Try to spend no more than a focused 1-2 hours per session to groom the top-most valuable items. Then move down the backlog of requirements and repeat.
6) Have the right people in the room
Have you ever played the telephone game? And how did that turn out?
Ensure that the right people are in the room from the get-go. The right people are those who can uncover assumptions of the requirement, or those who can help make the right decisions. Wasted time and effort will be saved in the long run.
For a product owner on a team, this
meeting might include the engineering team and designers.
Or for Business Owners, this might be representatives of the financial, marketing and operations teams.
Get everyone aligned in the same room from the beginning and you have already stacked the deck in your favor.
You may find that you have trouble identifying the right people. Step through the requirement end-to-end from a customer standpoint. Try to understand the underlying systems that are in place. Some examples of systems include the Marketing system, Fraud system, Customer Records system and Billing system. From there, identify key people who represent those areas and bring them in.
7) Establish a rhythm
Practically speaking, one of the biggest challenges related to requirements and communication is that Business people in particular often have chaotic schedules, and it is all but impossible to get everyone in the same room.
Are you begging, bribing and stealing for peoples’ time? One of the most effective ways to solve for this is to establish a regular product requirement grooming cadence. So if the events are already established, attendance will improve. With a regular schedule, meetings will be shorter. If you’re a facilitator, this reduces the overhead of scheduling multiple ad-hoc meetings.
Depending on the nature of the
project, a focused hour a week can work well for 10-20 person product/engineering
team.
8) Visualize the work
Leverage a visual centerpiece around the work. It could be an ordered backlog, or a roadmap showing the current and upcoming features.
This will be used as a springboard to help drive collective conversations about the product. Use an easily accessible, up-to-date medium (like a shared wiki). This will go a long way to simplifying communication and alignment.
9) Hold regular product demos to capture and communicate requirement feedback
One of the most powerful ways to bridge
communication and foster continuous product improvement to is hold regular product
demos.
In terms of format, these demos are often hosted and led by the engineering delivery teams. The demo is delivered to the business stakeholders.
The intention is to focus on sharing the actual working solution. This activity should be informal and not require much up-front preparation. So leave the slides at home. From this, you can expect a lot of valuable collaboration to spring up. Questions and feedback from the Business can be used to shape the product backlog in the future.
What’s great about this exercise is that it’s unifying, motivating and engaging. The teams walk away with a sense of recognition and appreciation and the business has learned something new.
In Summary: Writing and communicating great Agile requirements
With the right structure in place, your organization will significantly improve on requirement writing and communication.
Incorporate INVEST and ‘Card, conversation, confirmation’. Your Business will be on its way to having clearer requirements.
Break down requirements into smaller more actionable units. Rhythmically include the right people.
Visualize your work. This will lead to a more aligned view. It will permit feedback to refine the product over time.
Finally, foster a common understanding of expectations between Business and Engineering. Establish working DoR and DoD agreements.
Now you have the structure to improve requirements writing and communication. It’s important to take action! Make a conscious effort to apply these techniques daily and you will gain improvements!
Contributions
Thanks to Daniel Bales and Angela Wick for their valuable feedback.
Michael Nassif is a Principle at ZenAgile, a training and consulting firm that specializes in developing high performance, empowered organizations. They take a heart-centered approach by providing hands-on training and workshops in the applications of Lean and Agile.
Implementing an Agile Transformation is No Simple Feat
Creating deep, lasting organizational change is hard.
One of the biggest reasons behind a successful organizational tranformation is the quality of leadership that is behind the implementation. Without strong Leadership in place, a company is unlikely to make cultural change stick.
The Reason Agile Transformations Fail
Most transformation efforts seek to instill a creative culture – the kind that attracts the very best talent, drives innovation and ignites speed to market. Leaders aim to promote and foster this in their organization. Yet often the same leaders have not fully honed their own internal capabilities and those of their people in order to enact and sustain the change. And so you get a lot of activity that fails to result in a deep, lasting change. And leadership does not see itself as the reason it failed.
Have you ever experienced the “flavor of the month”?
In order for cultural change to stick, leaders must be willing to look inward. Management training and on-the-field practice does not equal the real world day-to-day. Like gravity, without the proper internal operating system in place, Leaders will fall back to their modus operandi, or Reactive Level of Leadership.
As a Lean-Agile coach for Fortune 100+ organizations, I recognize that am limited in my ability to effectively help other leaders rise to a higher level of performance than I am currently capable of internally. Correspondingly, it is important that Leaders take the initiative to work on their own development and the development of their people. The Leadership Circle Model defines this process as:
1) Uncovering the creative and reactive leadership areas
2) Developing creative leadership areas
3) Reducing reactive leadership areas
Broadly, there are five stages of leadership that are relevant to the degree that an organization achieves transformational success; The Egocentric, the Reactive, the Creative, the Integral, and the Unitive. Here I will be covering the first three.
The Egocentric Leadership Level
“Do not tolerate brilliant jerks. The cost to teamwork is too high.” – Reed Hastings, CEO Netflix
At this level, it’s all about Numero Uno (me). About 5% of adults operate here. The emphasis is on loyalty to self. This type of leadership is normal in adolescent development. But in adulthood, it’s considered pathological and it’s extremely destructive to an organization’s health. From a Leadership and culture standpoint, this must be addressed.
The Reactive Leadership Level
This is about loyalty to the organization. There is a strong congruence between a Leader’s competency and their sense of identity. For example, if I am good at fixing problems, then a Problem Fixer is who I am as a person. I may be the Intellect, the Architect or the Orchestrator. That’s me. I’ve seen good talent leave the building because the ways of working changed, like the incorporation of a new programming language into the company’s technology stack as a DevOps and Continuous Delivery enabler. Here, the “Java Expert” identity was put squarely at risk, and they felt compelled to act accordingly.
These Leaders typically care deeply about their people and manage like well-intending matriarchs or patriarchs. It’s all about competency. It’s mechanistic. Input is typically taken from below and decision making is made at the top. At this level, there are lots of risks and liabilities as it relates to leading and sustaining a transformational change. The vast majority of leaders in organizations operate here.
The Creative Leadership Level
The Creative level emphasizes development of self and others. The leader is no longer the sole decision maker. They instead act as facilitators and as developers of people. They are responsible for the vision, and in helping others to see how it converts into reality. At this stage, sharing power is not seen as letting go of control, but rather as acquiring power by way of sharing it.
As I transitioned in my career from a Scrum Master supporting a couple of teams to Coaching a program with over a dozen teams, it was important to recognize that in order to scale successfully, shifting my mindset from being a problem solving leader to a developer of others, was integral. I could not be everywhere. The economics simply no longer made sense.
In fact, the degree to which I was able to equip others as Leaders became my own top success criteria. For example, if I found that in a given week I had an increased volume of people swarming my desk, I knew something was up. I would step back and ask myself, is the intent clear enough? Do people have the information readily available to them make high quality decisions and act? What needs happen to enable them to do their job effectively?
This doesn’t just mean supporting formal Leadership roles like management and product but also the “knowledge workers” who are closest to the work itself.
Thought Exercise:
Clock yourself at five minutes to write answers to the following questions:
What is the primary cause of failed transformations?
Which levels of leadership do you see yourself mostly operating in (egocentric, reactive, creative)?
What are your top two strengths? Where do you go when you’re in a crisis?
Executive Scenario: Our customers are a priority. We need to deliver this by quarter, we can fix things that are broken in q1 next year. What type of Leadership level does this suggest?
“We’re agile, we have scrum teams, we do daily stand ups, we have sprint planning.” What could be missing?
“We have scrum teams, we do daily standups, we focus on impediments, we care about our people and our customers, we monitor our quality, we are often willing to take short term business trade-offs to make sure our technical debt is kept down.” Is this an Agile team?
In what ways will transitioning to the next area of Leadership benefit those around you and your business success?
