Scrum Teams Come Together Like a Banana Split

The Toppings Makes it Complete

Before You Get Started

Take a close look at a banana split. Before you eat it, can you see a Scrum Team? Maybe I’ve indulged in one banana split too many, but I see the banana as the Scrum Framework. And the ice cream? They are team member skills. Teams need to be cross-functional, so vanilla, chocolate, and strawberry seem to take care of that. Ah, but banana and ice cream alone do not make a banana split. This dessert is not complete until we add toppings.

What are the toppings on this Scrum Team banana split? Team character. Scrum has transformed how teams and organizations work, but teams frequently overlook the fact that Scrum is a framework. The Framework is an excellent starting point, but it is the bare minimum, and Scrum is not complete until we add the toppings present in team character.

What is a Scrum Team?

The Scrum Framework defines team structure, but more importantly, it defines team characteristics that lead to success. Consider this paraphrased definition of a Scrum Team:

A small, cohesive unit of professionals focused on one objective at a time with no sub-teams or hierarchies.

This fundamental definition is further buoyed by Scrum’s overarching principles of Focus, Openness, Respect, Courage, and Commitment. Teams that follow this definition and embrace these principles are off to a strong start. Then, Scrum adds a little more to the framework by including a few guidelines, which are:

  • Ten or fewer people on a team, including the Product Owner and Scrum Master
  • Shared accountability, so the entire team is responsible for outcomes
  • Cross-functionality, so that it has all the skills necessary to create value in each Sprint
  • Self-organization which gives the team the autonomy to manage its own work

There’s your banana and ice cream, gratifying but incomplete. Team character, or the team’s collective character traits, create toppings. Interestingly, evidence shows that certain character traits directly influence team performance. In fact, studies of successful Scrum teams have increased awareness of these characteristics.

Teams, just like individuals, do differ in character; and certain character traits contribute to better team performance. So the team is right to expect that its Scrum Master will also help to lift their performance. Therefore, Scrum Masters should be aware of beneficial character traits.

Character Traits of Successful Teams and McKinsey & Company collaborated in 2018 to publish “How to Select and Develop Individuals for Successful Agile Teams: A Practical Guide” which found that team members possessing three capabilities were important contributors to team success:

  • Handle ambiguity without losing focus
  • Concentrate on outcomes over processes or outputs
  • Possess a sense of pride in the product

These character traits represent the Scrum banana split toppings. A banana split has essential toppings. I prefer chocolate syrup, whipped cream, and cherries on mine (feel free to substitute your favorites). Similarly, this report acknowledges a Scrum Team’s essential traits. 

Handle Ambiguity without Losing Focus

The Scrum framework addresses adaptive solutions for complex problems. Complex problems naturally include uncertainty, so ambiguity and uncertainty walk hand-in-hand. People who struggle with ambiguity will have more difficulty on a Scrum team, and this difficulty could impede team performance. People who are able to handle ambiguity with an open mind tend to thrive in agile teams.

Managing ambiguity requires team members to focus on goals and to prioritize activities in line with those goals. This combination of open-mindedness, focus on goals, and prioritization will help guide the team toward a practical solution. The solution may not be perfect, but the Product Owner may want to seriously consider whether perfection is a necessity or an enemy. Managing ambiguity covers most features and functions, so it serves as the whipped cream.

Concentrate on Outcomes over Processes or Outputs

Outputs are the things we deliver. Traditional project management encourages processes that emphasize the production of outputs; assuming that more output equals greater productivity. Unfortunately, more output does not equate to more value unless teams produce the right output, which can be hard to define. So Scrum does not promise to increase output; instead, Scrum encourages improved outcomes.

An outcome is a different state of operation, existence, or efficiency. We expect that this different state will be more valuable than the prior state. Therefore, truly effective Scrum teams aim for improved outcomes, not necessarily more output. Therefore, when targeting outcomes, we emphasize quantifiable improvements, typically through Objectives and Key Results (OKRs) which are designed to provide clear evidence of value. Outcomes are prevalent in every action, so they are the chocolate syrup. 

Possess a Sense of Pride in the Product

Former U.S. Labor Secretary Robert Reich frequently used a tool he called the “pronoun test”. When visiting a company, he would ask employees some questions about the company and then listen for the pronouns they use in their response. Do they refer to the company as “they” or “we”?

The “pronoun test” can also be an effective team pride barometer. Listen to team members as they speak. Do they use “we” or “they”? References to “we” reflect a team connection, which indicates team pride. This person will more likely value product pride over work pride. The product itself becomes more meaningful because the product itself represents an outcome.

The report also reveals that product pride brings with it three broad team performance benefits:

  • Product quality becomes natural rather than forced
  • Team members are organically motivated
  • Innovative ideas happen

Pride in product and team truly represents the cherry on top of this banana split.

Each team’s unique character should be recognized and encouraged, for it is this character that influences how the team functions. At the same time, there are character traits that make a team more inclined toward success and cannot be overlooked. These traits, when combined with team skills and framework adherence will influence outcomes, reliability, creativity, and innovation.

Ultimately, Teams best serve the organization consistently delivering value and changing outcomes; so a Scrum Master’s insight should help to encourage or inspire character traits that help teams to excel. This leads to better team performance and growth while forming unique toppings for this banana split. In closing, I do apologize for any cravings caused by this article.

Why Vision Statements Really Do Help Scrum Teams Hit Their Targets

High-Performing Scrum Teams Take Advantage of Vision Statements

Teams hit their targets
Stock Content Provided by Storyblocks

In my work with Scrum, Scrumban, and SAFe teams, I’ve come across some teams that were high-performing and delivered great value from the start. Other teams struggled to get their footing but grew stronger and learned to perform well. So in my coaching practice, I’m frequently asked what makes one team perform better than others. I typically explain that the answer to that question is somewhat challenging.

There is no magic formula to lead a Scrum team to become high-performing. Instead, many small but important factors, each easily overlooked, conspire to make the team significantly greater than the sum of its parts. One such important factor is the vision statement.

A vision statement is an aspirational description of the future. It creates context and purpose for team members. A good vision statement serves to motivate and even excite team members. In spite of that, one can easily underestimate its importance. That’s where we see that some teams don’t bother to create one at all.

Skipping the vision statement leads to a missed opportunity to drive and gauge team motivation. More importantly, skipping the vision statement is to forego a tool that keeps your team focused on the right priorities. Furthermore, the value statement contributes to the team’s collective identity. And that is an important and common characteristic of high-performing teams.

Please stay on the path
Photo by Mark Duffel on Unsplash

Creating the Vision Statement

In Scrum product development, the Product Owner is responsible for creating a product vision statement and the Scrum Master is responsible for guiding the process. The creation process is most effective when team members and stakeholders participate because collaborative approach inspires more creativity and offers as sense of contribution.

You may have participated in exercises designed to create a vision statement. That means you understand its value, so you embark on its creation as part of a group with the best of intentions. Then the worst happens: somehow a statement like one of these emerges:

“To create a shopping experience that pleases our customers; a workplace that creates opportunities and a great working environment for our associates; and a business that achieves financial success” — Albertsons Supermarkets

“To operate the best omni-channel specialty retail business in America, helping both our customers and booksellers reach their aspirations, while being a credit to the communities we serve.” — Barnes & Noble

These statements are noble, but not very effective as vision statements. They are long and not particularly memorable. Also, you ideally want to incorporate emotion to trigger an image or feeling. These are not likely to stay with you, promote an image, or inspire a feeling. So they risk being easily forgotten, and a forgotten vision statement doesn’t help inspire or motivate people.

Nailing It!

When done well, the product vision statement serves to motivate, inspire, and preserve awareness of why this product is important. If the Product Owner wants the advantage of those benefits, then they have to apply their own motivation to create a good one. Without that motivation they may treat it like a task on a checklist. When that happens, they risk producing a phrase that may meet a vision statement’s literal definition, say “Yup, nailed it!” and move on.

But sadly, they did not nail it. A bad vision statement is worse than no vision statement because you’ve spent time producing something that does not add value.

Man did not nail the bike jump
Stock Content Provided by Storyblocks

The Vision Statement Adds Value to a Scrum Team

A good vision statement has certain attributes.

  • Sticks with people
  • Reminds them of their purpose and direction
  • Enables people to form a vivid image of the future
  • Represents a source of self-respect and commitment
  • Allows teams to say “No” to certain requests

Your well-done vision statement reflects that team members deem this effort worthy of pursuit and believe in its meaning and value. That’s how you know you’ve nailed it!

When coaching a Scrum team toward becoming high-performing, use the vision statement to form the teams’ common core. Then teams, or teams of teams, have a basis to connect through a set of principles, values, and common objectives. That vision statement becomes the embodiment of team character and direction. The challenge is to create one that people are willing to believe in.

Man performing impressive bike trick
Stock Content Provided by Storyblocks

A Proper Vision Statement

Here is my favorite definition of a vision statement:

“A vision is the actual destination. It’s a vivid description of what success looks and feels like for us — what we are able to achieve, and the effect it has on our staff” — Ari Weinzeig, CEO of Zingerman’s

A vision statement, when done well, provides a point of reference for most decisions. It answers the question: Why are we doing this? So, if a team’s steps are not taken with the vision in mind, then they will drift off course and the value delivered will suffer considerably.

A good vision statement will meet these criteria:

  • It is inspiring and makes sense to those who contribute to the product
  • There is a strategically solid approach to achievement
  • It is in writing
  • It is communicated consistently and enthusiastically

You may notice that vision statements can be abstract. This is fine because it should trigger people to conjure an image. It just shouldn’t be so abstract that it becomes hard to understand or picture. An emotional influence helps to keep it from becoming too rigid or formulaic. Here are examples of a few good organization level vision statements:

Create economic opportunity for every member of the global workforce” — LinkedIn
Connect with friends and the world around you” — Facebook
Accelerate the world’s transition to sustainable energy” — Tesla
Capture and share the world’s moments” — Instagram

Scrum Team Members Find Imagery Motivating

Did these statements trigger an image for you? Each person will create their own image, and that is intentional. What matters is associating the statement with an image. That makes it easier to remember and reference over time. Additionally, when weighing various product options or features, the option that is most in-line with the vision statement should carry the most weight.

Together we create
Photo by “My Life Through A Lens” on Unsplash

Creating the Product Vision Statement

An ideal vision statement is one sentence or shorter in length. There is a practical approach that will guide your team to that point which is called the Envisioning Workshop. In this workshop, we use a template like the one recommended in Geoffrey A. Moore’s “Crossing the Chasm” (shown below) to create a product elevator pitch. 

For (target customer)
Who (statement of need or opportunity)
The (product or service name) is a (solution category)
That (key benefit or reason to buy)
Unlike (biggest competitor)
Our product (primary differentiator)

This template is particularly useful in that it focuses the participants’ on the product’s value proposition. Then the participants use the completed template to collaboratively condense that template down to a vision statement.

This template can also be used for an internal product or if there is no competitor. If you are replacing an existing product, you can treat that product as the competitor. 

In the Envisioning Workshop, having completed the template, workshop participants use games to employ abstract thinking to come up with a meaningful and imaginative vision statement. The use of games helps to keep participants actively engaged, and there are many games, so I my favorite source of games that stimulate creativity is the website Gamestorming. At the end of this workshop you will have an elevator pitch, and you will have condensed the pitch into a statement representative of the team’s vision.

Efforts and courage are not enough without purpose and direction.

Why a Vision Statement Matters to a Scrum Team

A vision statement contributes to team performance in the following ways:

  • Helps you to maintain product direction, consistent with the product’s value proposition
  • Improves strategic decision-making throughout the development process
  • Aligns teams and stakeholders

The Product Owner will take ownership of vision statement creation and communication. So the statement has to be in a form that is easily conveyed to anyone who ever looks in the direction of the product. It should also be embedded in all product communications so that it has a constant presence.

If you have access to artistic talent, you can take it a step further by creating a logo for team use. In a multi-team organization, a team or product logo forms a sense of pride and camaraderie. You can also include the logo on awards and diagrams. Also, members who serve different teams can collect logos that reflect their contributions. The possibilities are endless.

High Performing Teams and the Vision Statement

A high-performing Scrum team embodies unity. It has a common sense of purpose, reinforces mutual respect, and members look out for each other. You can’t teach people to behave this way. They have to feel it. When a team has embraced this concept, the Scrum principle of self-management becomes a natural part of the team culture. And that makes life easier for the entire team and the stakeholders.

You don’t want to overlook this small factor that can make a big difference in team performance. A vision statement alone won’t necessarily revive performance, but a good vision statement will conspire with everything else that you do well to ensure you delight your customers.

Agile Teams Don’t Self-Manage Themselves

My introduction to Agile teams happened just as I had transitioned from lead software engineer to release manager at an investment bank. Our team had just built an investment management system that was well received and quickly became quite successful. We were pleased with it, but the growing team struggled to keep pace with business demands, and that triggered concerns. In response to our concerns, senior management committed to direct a new development strategy.

We had already created a release team, a testing team, and then grouped developers into business domains. Then, one Thursday we got an invitation to an all-hands mandatory meeting set for this Monday. Next, our calendars were blocked off for a mandatory 1 or 2-day training session next Tuesday and Wednesday. What in the world is going on? No one knew, and we couldn’t reach senior management.

Monday morning came and teams were assembled in the auditorium. After some introductory remarks, we got the news: Effective immediately we are implementing Scrum. First, everyone will attend Scrum training tomorrow; then on Wednesday, team leads (me) will attend Scrum Master training while business analysts attend Product Owner training. I saw this as good news. Coincidentally, I had read Mike Cohn’s “Succeeding with Agile” a few months earlier, so I was ready to put an Agile practice to work.

In spite of all-around optimism, we learned many lessons; and ironically, the launch itself proved to be the first lesson.

Forming Agile Teams

Lesson: Team members were given an immediate mandate.

One essential aspect of the Agile mindset is mutual trust. Much of Agile cannot work without trust, and communication is a key element of trust; therefore, communication matters when initiating an Agile practice. Best intentions notwithstanding, the act of surprising people with a mandate serves to undermine trust. On the other hand, the act of incorporating team members into the planning process enhances trust. Furthermore, it provides a sense of inclusion and allows people time to adapt.

Self-Organizing and Self-Managing Teams

Lesson: Members were assigned to teams.

Agile teams are self-organizing and Scrum teams in particular are self-managing as defined in the 2020 Scrum Guide Update. Encouraging teams to manage themselves is a form of empowerment that leads to many other benefits that I will describe later. The core principle of self-management is that those closest to problems tend to be best equipped to properly resolve those problems; but self-management is neither natural nor easy.

Team members typically expect to take direction from management, but a self-managing team drafts it’s members and identifies and resolves problems themselves with assistance from a Scrum Master. They collaborate with other teams to minimize conflict and make effective use of the Product Owner to ensure they meet business needs; thus, eliminating decision-making impediments. While solving problems, self-managing teams also have the freedom to succeed or fail with experiments.

Empowered Teams

Lesson: Changes required committee approval.

Empowered teams have the freedom to experiment, but therein lies the challenge. Experimenters are often celebrated when successful and punished upon failure. This practice kills team empowerment. An experiment’s purpose is to teach, so when teams fear the consequences of falling short, they don’t grow much beyond the limits of their existing abilities

Mutual trust between teams and management is the lynchpin of empowerment. However, trust requires a willingness to be vulnerable, which can make almost anyone nervous. The cost, however, when mutual trust is absent, is that the team cannot function at its best. A team that is not empowered cannot self-manage.

Team Expansion: Adding and Replacing Members

Lesson: Outside control of ongoing team membership.

An Agile team should ultimately be able to fully deliver an increment of value without dependency on other teams; but there is no requirement that teams start out fully formed. Members can be added or replaced while becoming cross functional.

Adding and replacing team members will slow team progress initially as new people integrate with the team; so, take this into account when planning Sprints or program increments. When possible, it is generally better to add three members at once, than to add one member per iteration over three iterations; but evaluate individual scenarios as this is not always the case.

Impediments: Removing Members

A common myth is that team members cannot be removed from an Agile team. This is unrealistic. What Agile does expect is that the Scrum Master and team will make every effort to resolve problems within the team before resorting to removing someone. The team has a responsibility to act if a member’s behavior, when considered objectively, consistently interferes with delivery, quality, or value.

Self-managing teams are more reliable, creative, innovative, and they continuously improve. Furthermore, research shows that self-managing team members generally have high morale. For leaders, developing a self-managing team requires an organization-wide commitment to the Agile mindset. Back then, we expected to realize the benefits of Scrum; but we didn’t fully appreciate the concept of self-organizing teams.

I’ve described some of the lessons learned, but there were others. For example we kept using specialized teams, treated daily stand-ups as status meetings, and allowed influential people to sneak in “quick changes”. In a nutshell, we squeezed past practices into the Scrum framework.

Ultimately, we learned from our mistakes by doing other things well. We made effective use of Retrospectives; we experimented; we set boundaries with influential people; and we created cross-functional teams. We evolved practices to use the full Scrum framework and engaged experienced Scrum consultants. We began to show significant quantifiable improvements which made everyone’s work life easier and customers even happier. Teams of self-managed teams made this possible along with a leadership team that was willing and able to trust the process and the teams.

The Agile Leadership Ecosystem

What’s so Different About Agile Leadership?

Effective leadership is a primary key to organizational agility. As reflected each year in the “State of Agile Report”, organizations that commit to all aspects of Agile principles tend to realize the greatest benefit. These organizations start with a focus on leadership. Each Agile framework in its implementation makes great investments to clearly define leadership roles and responsibilities. Some go farther and define the required leader competencies. This emphasis on leadership makes it clear that organizational agility does not come from isolated tactics. It requires an all-in commitment to strategy.

The leading obstructor to pursuing organizational agility continues to be organization itself. And that’s a shame because the factors leading to these obstructions are completely within the control of the organization — if the people are truly ready, willing, and able to do what it takes to succeed. All too often, the collective will of the people within the organization lacks the readiness, willingness, and/or ability to do the work needed to realize success. And resolving that problem starts with leadership.

For fourteen years™ (formerly CollabNet/VersionOne) has published an annual “State of Agile Report”. This is an annual analysis of organizations using Agile frameworks. The analysis consistently shows, year over year, that inadequate management support and sponsorship, along with resistance to change, remain among the top obstructors to adopting Agile. Let’s consider how to address that.

Change Agents

A change agent is someone committed to leading organizational change. A change agent will drive and sustain the ecosystem through leadership by example. More importantly, they model Agile mindset, principles, practices, and values. They understand and embrace the importance of servant-leadership. They recognize that practicing openness, trust, and transparency will encourage others to do the same. They are aware that these practices have proven over decades to create greater value to stakeholders, adapt well to change, create superior products, and foster continuous improvement and innovation. Why? Because given the room to thrive, people inherently adopt an interest in doing better at whatever they do. These practices form a more effective management ecosystem.

Sociologist, Ron Westrum famously created an organizational culture model which defined three categories of organizational leadership behavior:

Pathological: Power-orientedBureaucratic: Rule-orientedGenerative: Performance-oriented

These behaviors define the organization’s ecosystem, and thus its ability to adapt to change. Pathological and Bureaucratic styles are all-too prevalent, but there are significant and encouraging indicators of Generative leadership growth.

The good news in the State of Agile Report is that the leadership situation is improving. Leaders in a growing number of organizations have accepted that they are better off operating in an Agile-friendly ecosystem than in traditional pathological or bureaucratic models. This is a great improvement with, or without Agile. But Agile frameworks challenge the status-quo in different ways. The Scaled Agile Framework (SAFe®) requires Lean-Agile leadership as part of its implementation. Scrum is also a strong advocate of the Agile mindset as demonstrated in Scrum Master and Product Owner certification.

The DNA of Agile frameworks includes a specific form of leadership. It strives to produce leaders as change agents capable of inspiring the best of people. It requires a non-traditional approach to leadership. When forced, the approach can become a source of resistance. But ultimately, as results prove the value of Agile leadership, more traditional organizations will be well-served by evolving their ecosystems toward agility.

You will recognize generative leadership by the organization’s ability to foster effective flow of information, high cooperation, trust, authenticity, common respect, emotional intelligence, continuous learning, and decentralized decision making. There are other characteristics consistent with generative leadership, but they ultimately come culminate in human growth and higher quality products and performance.

People don’t resist change. They resist being changed!Peter Senge

[tcb-script type=”text/javascript” charset=”utf-8″ src=””][/tcb-script]

But Why Agile?

Agility is the ability to quickly respond to change and organizations frequently struggle with change. Traditional management clung to pathological and/or bureaucratic leadership styles which naturally led companies to produce solutions as if nothing would never change. The flawed thinking in both of those styles is the belief that we know everything we need to know. The unfortunate truth however, is that we do not know everything we need to know, and we never have.

By misleading ourselves in this way, we create unnecessary stress, struggle, and scrambling. When something unexpected happens, we scramble and go to great expense as we react. Our approach was not designed to handle change. Agile confronts that faulty approach head-on. Agile assumes change. It accepts the fact that change is inevitable. By building change into the process, Agile teams respond to change. They are not impeded by change.

The Agile Ecosystem

In software engineering we broadly envision Agile as the ability to quickly respond to change. An organization shows agility when it stops reacting to changing needs, demands, expectations and requirements. Agile organizations respond. Agility lives in the real world, where changes are expected, we are aware that we don’t know everything, but we are confident that we can handle anything. Agility perceives the world differently, and thus requires a different ecosystem.

The traditional American organizational ecosystem is one of command-and-control; where leaders issue directives to be followed by everyone. Agility cannot exist in this environment. Agility requires trust, openness, and transparency; none of which thrive under command-and-control. Attempts to use Agile methodologies within command-and-control organizations have met varying degrees of success; however, consistent success requires consistency of practice throughout the organization.

When the ecosystem hosting the project supports Agile principles, then the project has a natural home and can function optimally. When the project team uses Agile frameworks in an incompatible ecosystem, then factors, large and small will interfere with the project’s life system. The project is very much like a fish out of water. Many project leaders have attempted to use an Agile framework with great intentions in non-Agile organizations, but few have succeeded. Agile frameworks require management support and sponsorship. Without the appropriate level of support, especially when things don’t go as planned, the uphill climb becomes even steeper. So Agile functions well in an ecosystem where its frameworks can thrive in a drive toward organizational agility.

Editor’s Note: This article reproduced with permission from Medium.