When forming a new Scrum team, it’s crucial to look beyond the foundational aspects of Scrum and consider the broader ecosystem of practices, mindsets, and collaborative tools that contribute to a team's long-term success. This article focuses on just a few of the many topics that can be crucial for a team's growth and sustainability.

In my experience, teams are often simply taught what Scrum is, but many essential elements are overlooked. This can happen due to the inexperience of the coach or Scrum Master; lack of time to properly prepare; or, unfortunately, a lack of buy-in from managers who push for training to be completed as quickly as possible. 

Addressing these additional areas can make a significant difference in setting up a team for success:

1. Team Culture and Psychological Safety

Creating a positive team culture where members feel safe to express their ideas, take risks, and provide constructive feedback is essential. Psychological safety fosters innovation and allows the team to learn from failures without fear. Establish ground rules for open communication and active listening to build trust from the start.

2. Defining Team Values and Working Agreements

Aligning on shared values helps guide the team’s interactions and decision-making processes. Establishing working agreements ensures everyone is clear on expectations for behavior, availability, and participation. These agreements should be reviewed periodically to adapt to evolving team dynamics.

Examples of working agreements include:

• The preferred days for team members to work on location versus remotely
• The agreed times for key Scrum events like daily stand-ups, sprint planning, and retrospectives
• How peer reviews of work will be conducted, such as dedicated review sessions or integrating feedback within daily work

These agreements create clarity and foster a shared commitment to team practices.

3. Effective Use of Collaboration Tools

Remote and hybrid teams need strong digital collaboration practices. Introduce collaboration tools to facilitate brainstorming sessions, create visual artifacts, and document shared learnings. Training the team on how to use these tools effectively can greatly enhance communication and efficiency.

4. Backlog Management and Prioritization Techniques

While backlog refinement is a core part of Scrum, diving deeper into prioritization frameworks like MoSCoW, the Kano Model, or Weighted Shortest Job First (WSJF) can help teams make more strategic decisions. Ensure that product owners are equipped to guide these practices effectively and that the team understands how to contribute.

Additionally, emphasize the importance of properly splitting backlog items vertically so that each item delivers incremental value. This approach ensures that each piece of work completed adds real user or business value. Define a clear definition of “done” to establish a shared understanding of completion criteria and maintain high-quality standards across the team.

The importance of story points should also be highlighted. While story points can aid in planning, their main strength lies in triggering discussions and helping the team share a common understanding of the complexity and scope of backlog items. This practice fosters better alignment and clarity across the team.

5. Agile Mindset Beyond Scrum

While Scrum is a popular framework, embracing the broader agile mindset—focusing on adaptability, continuous learning, and iterative improvement—helps the team apply principles flexibly. Introduce Lean concepts, Kanban practices for visualizing work in progress, and DevOps principles for fostering collaboration between development and operations.

Conclusion

Building a Scrum team involves more than simply implementing the basic rules of the framework. By focusing on these additional areas—team culture, working agreements, collaboration tools, and advanced backlog management—teams can develop a more holistic approach that supports sustainable growth and long-term success. Investing in these practices sets the stage for a resilient, collaborative, and high-performing team.

What other topics are important for you when you train new teams?
 

by Christian Bisson

Agile team cohesion is the seamless collaboration, effective communication, and shared goals and values among team members. I frequently prompt new teams to reflect on a time they thought things were going great; consistently, "the team" emerges as the primary factor contributing to that moment’s greatness.

Being intangible, team cohesion is often undervalued, with some viewing it as simply as an overhead. For example, team building activities, or even retrospectives that have a bit of fun included in them can be seen as a waste of time. Heck I’ve also been told by team members that it was an insult to their intellect! 

Despite that, the impact of team cohesion is far-reaching, offering substantial benefits to the team and the project at hand.

Enhanced Communication

Cohesive teams communicate more effectively, leading to smoother workflows through several key mechanisms:

• Shared Understanding: Team cohesion fosters a shared understanding of goals, objectives, and project/product requirements among team members. When everyone is on the same page, communication becomes more targeted and relevant.
• Open Communication Channels: In cohesive teams, trust and mutual respect is built over time which creates a culture of open communication. Team members feel comfortable expressing their ideas, concerns, and feedback. Not only does this transparency helps in addressing issues promptly, but it also provides the team with collective creativity to find solutions to whatever challenge they face.
• Adaptability to Change: In agile environments, where change is frequent, cohesive teams are more adaptable. Effective communication ensures that everyone is informed about changes promptly, and the team can collectively adjust its strategies and tasks to accommodate new requirements.

Increased Productivity

• Alignment of Efforts: Shared goals provide a common purpose that aligns the efforts of each team member. When everyone understands and commits to the same objectives, individual tasks and activities naturally complement one another, avoiding conflicts and redundancy.
• Motivation and Engagement: Having shared goals fosters a sense of shared ownership and commitment. Team members are motivated to contribute their best efforts when they see how their work contributes to the overall success of the team and the achievement of common objectives.
• Efficient Capacity Management: A united team optimises their capacity by ensuring that each team member focuses on tasks that align with the team's goals. This prevents duplication of efforts and ensures that time and expertise are utilised efficiently.
• Collaborative Problem-Solving: Shared goals encourage collaborative problem-solving. Team members are more likely to work together to overcome challenges and find innovative solutions when they share a common objective. This collective approach enhances problem-solving efficiency and effectiveness.
• Mutual Support and Knowledge Sharing: A united team promotes a culture of mutual support where team members readily assist each other. This support extends beyond task completion to knowledge sharing, where individuals leverage their strengths to help others, fostering continuous learning and skill development. Furthermore, this prevents “points of failure” where one member only can execute a certain task or has a certain expertise, lowering risks if team members leave the team or are missing.

Conclusion

Team cohesion is important, and it’s important for all members of the team to understand its value so that everyone contributes to it.

How do you actively contribute to your team's cohesiveness? Share your insights and any noteworthy team-building activities you've found effective.
 

By Christian Bisson

Within the realm of agile project management, the composition of a team greatly impacts its success. While all team members play a vital role, the inclusion of an external product owner (as opposed to an internal one) poses challenges that can hinder teams’ potential to deliver value to users. 

In this post, I will highlight four potential pitfalls of having a product owner external to the team, with real-life examples underscoring the benefits of an integrated team approach.

1. Misalignment and Unclear Vision

When a product owner is external to the team, misalignment and an unclear vision can arise. The absence of direct day-to-day collaboration stifles the shared understanding of project goals, priorities, and user needs. This lack of alignment makes it difficult for the team to make informed decisions and deliver a product that meets customer expectations.

Example: Imagine a software development project where the product owner is external and has limited interaction with the team. This separation hinders effective communication and prevents the product owner from gaining in-depth knowledge of the project domain. As a result, misaligned priorities and a fuzzy vision emerge, leading to a disconnect between the team's efforts and the desired outcomes.

2. Inefficient Prioritization and Decision Making

An external product owner often leads to inefficient prioritization and decision-making processes. Without a direct line of communication, the product owner's expertise and insights may not reach the team effectively. As a result, crucial decisions regarding scope, timelines and trade-offs may be delayed or misinterpreted, leading to project inefficiencies and missed opportunities.

Example: In a marketing campaign project, an external product owner who lacks real-time interaction with the team may struggle to grasp the evolving market trends and user preferences. Consequently, delays in decision making occur, preventing timely adjustments to the campaign strategy, ultimately impacting its effectiveness and return on investment.

3. Communication Gaps and Feedback Delays

With an external product owner, communication gaps and feedback delays become commonplace. The limited availability and reduced involvement of the product owner hinder continuous communication and the timely exchange of information. This results in a slower feedback loop, preventing the team from promptly addressing concerns, adapting to changing requirements, and delivering high-quality increments.

Example: In a mobile app development project, an external product owner may have competing priorities and limited availability for sprint reviews. As a result, feedback on delivered iterations may be delayed, preventing the team from incorporating valuable insights—and potentially leading to inefficient use of development resources.

4. Detached from User-Centric Mindset

When the product owner is external, the team risks losing touch with a user-centric mindset. The direct contact between the product owner and end users diminishes, inhibiting the team's understanding of user needs, preferences and pain points. Without this critical insight, the team may struggle to develop solutions that truly resonate with the target audience.

Example: Consider an e-commerce project where an external product owner has limited interactions with actual customers. The team, lacking direct access to user feedback and insights, may fail to anticipate user behavior, resulting in an e-commerce platform that falls short of meeting customers' expectations and inhibits business growth.

Conclusion

In the agile realm, the inclusion of an external product owner introduces several pitfalls that can hinder project success. Misalignment, inefficient decision making, communication gaps, and a detached user-centric mindset are among the challenges an integrated team approach aims to mitigate. By recognizing the drawbacks of an external product owner, agile teams can foster collaboration, transparency, and a deep understanding of customer needs, ultimately leading to more successful project outcomes.

The above points assume there is one external product owner for the team. However, if there are multiple external product owners in a team, all the challenges mentioned earlier become even more significant. It not only amplifies the existing issues, but also adds to the tension and confusion within the team.
 

When facing a challenge in a project or during the evolution of your product, it's natural to look for quick solutions that can help you move forward. However, this approach can lead to "patching" the symptoms rather than addressing the root cause of the problem. 

In the context of agile software development, a good example of patching that I see trending is relying too much on the Scrum Master as a "Swiss army knife," where any problem is fixed by expecting them to compensate in some way.

While it's true that the Scrum Master is a versatile member of the team, it's important to remember that their primary responsibility is to facilitate the Scrum framework, not to be a jack-of-all-trades.

Instead of treating the Scrum Master as a catch-all role, it's crucial to find the core problem that's causing the challenge and address it directly. This may require some investigation, analysis and collaboration among the team members, but the payoff can be significant. By identifying the root cause, you can avoid repeating the same issue in the future, improve the overall quality of the product, and increase the team's productivity and morale.

So, how can you find the core problem when facing a challenge? Here are some steps that can help:

1. Define the problem. Start by clarifying what exactly the challenge is that you're facing. Is it a technical issue, a communication problem, a misalignment of expectations or something else? Write down a clear and concise description of the problem that everyone can understand.

2. Collect data. Gather information about the problem by talking to stakeholders, reviewing documentation, analyzing metrics or conducting user research. The goal is to get a holistic view of the problem, its impact and its potential causes.

3. Analyze the data. Once you have collected the data, you need to make sense of it. Look for patterns, trends and insights that can help you identify the root cause. This may require some critical thinking, brainstorming or hypothesis testing.

4. Validate the hypothesis. Once you have a working theory of what's causing the problem, test it by gathering more evidence, conducting experiments or soliciting feedback from the team. The goal is to confirm or refute your hypothesis and refine your understanding of the problem.

5. Address the root cause. Finally, once you have identified the core problem, take action to address it directly. This may involve implementing a new process, fixing a bug, improving communication or changing the team's dynamics.

Conclusion
By following these steps, you can avoid the temptation to patch the symptoms and instead focus on solving the core problem. This not only benefits the current project/product, but also builds a culture of continuous improvement and learning that can help the team succeed in the long run. 

So, the next time you face a challenge, resist the urge to rely on the Scrum Master as a Swiss army knife and instead use their expertise to facilitate the process of finding the root cause.

How do you deal with challenges?

by Christian Bisson

In a complex world where we strive to improve, there is one trending weakness that I’ve seen amongst many teams and organizations—they measure little to nothing, and make decisions based on “gut feeling.”

Having key metrics is a powerful tool to identify areas to improve, and not just for weak points—you want to recognize strong points as well so that you can continue them. Here are a few examples…

Value

How many times have you seen teams happy to deliver something—only to have absolutely no idea what value was ultimately gained from that delivery? There are a few ways you can be blind to the value being delivered (or not delivered):

• Not knowing how many users actually used a new feature (maybe none?)

• Was anything gained out of it? (Money? New hires or better retention?)

• What was the actual cost compared to the gain?

All too often, people waste money when they could focus their resources elsewhere if they measured the return on investment (ROI) and adapted accordingly.

Delivery predictability

What will be delivered, and when? Every organization faces a challenge to know this. And all too often, typical random delivery dates are given to stakeholders—and forced on teams. This in turn hurts the quality of the deliverable (not to mention the very small odds that the dates are even being respected).

By measuring on a small scale (like a team’s velocity throughout sprints) or a larger scale (like being familiar with SAFe and its “product increments”), you can compare results to actual data to make more reliable predictions (at the end of the day, it is still a guess).

Product backlog health

Throughout the years, I’ve seen many backlogs, from small to gigantic. And I rarely see any of them being measured to make sure they’re actually healthy.

The definition of “healthy” varies, but in this case let’s assume it means that the backlog is an ordered/usable artefact that teams can rely on to know what to work on next to bring value to stakeholders.

Here are a few things that can be measured:

• How many items are ready to be used by the team (i.e., refined)?

  • Is it too much? Too little?

• How many total items are there in the backlog? (If there are too many, it becomes clutter.)

• How much time do items spend in the backlog before they get started? (I’ve seen items rot in backlogs for years, never getting done,)

Conclusion

There are so many things that can be measured and used to properly align next steps—and they require the proper tools to do it efficiently. You want to spend as little time as possible getting the data and results that you need, and utilize reliable “live” information (with little cost to get it).

What will you be measuring in 2023? What do you think your blind spots are?