How can you avoid anti-patterns that harm your Scrum team's collaboration?

Absolutely, I've seen it firsthand; working in a Scrum team, the level of trust fundamentally alters the team's dynamics. I've been in situations where the absence of trust turned daily stand-ups into a chore; every idea was met with resistance, every mistake a potential crisis. But when trust was there, it was a game-changer. We could openly share opinions, learn from our mistakes, and celebrate our successes together. It was as if we were not just colleagues but comrades, fighting towards a shared goal. The journey wasn't just about meeting deadlines; it was about growing, learning, and creating something great together. It wasn't just work; it was a shared adventure, a bonding experience. It was simply transformative.

A key component to cultivating a culture of trust is for you to lead by example. Find ways to integrate yourself directly into the trenches with the rest of your team. Initiate challenging conversations with how you will help or where you are accountable. Approach everything without ego or judgment and focus on identifying how an issue gets solved VS who is to blame. By starting off relationships this way you immediately start to build trust because you are meeting the team halfway and extending an arm across the line to help and not add to problems.

I've experienced two dimensions around this anti-pattern of Lack of trust. The first is about lack of trust between team members. Visible symptoms are people working in silos, getting hung up on the "rules", and avoidance of conflict or difficult conversations. The second is about lack of trust between stakeholders/management and the team. Visible symptoms are "helicopter" managers intervening or being too prescriptive about the how; sprints being interrupted by random requests rather than going through agreed prioritsation procedures by the PO, and managers going direct to developers for updates rather than first looking at their sprint boards or again, asking the PO.

Often considered essential in Scrum, trust is more complex than a simple 'have it or don't' dynamic. It functions on a continuum, growing through joint experiences, problem-solving, and a healthy team culture. Trust can be partial; you may trust someone's technical expertise but doubt their judgment. It's a perpetual, evolving process that is usually subconsciously absorbed rather than openly acknowledged. Challenges offer a chance to build 'trust capital,' facilitating easier collaboration down the line. Recognizing the nuanced, evolving nature of trust is key to the long-term success of any Scrum team. Ironically, talking openly about these gradations in trust can actually strengthen it, making the issue visible and hence, manageable.

Although this sounds childish, it tends to be a common anti-pattern. When one is working in a team, it is often expected that you step-up and take care of things that are not directly part of your role. As an SM, my intent is not to prevent this. I aim to prevent/avoid conflicts that rise out of such scenarios. It all boils down to trust in the team and clarity in ownership of work /responsibilities.

First of all, let’s not immediately use the Scrum guide as the solution to a problem. While the guide holds a great deal of incredibly relevant and useful information, we tend to jump to using it before common business sense and coaching. Scrum is meant to add value, not dictate processes. The most critical aspect of avoiding role confusion is establishing a strong understanding of how people work together. Am I able to challenge my colleague? Do others around me receive feedback and value my opinion? Do I do these things for others? Crucial conversations are the key to establishing roles and responsibilities. If something is misaligned, everyone needs to feel empowered to not only speak up, but also to be heard.

Whilst having clearly defined roles is fine in theory, in reality it can easily fall into a "not my problem" state. I w worked in teams where the developers attitude is to deliver story points, and the SM to see how many points got delivered that sprint. Value to the customer? Nah not our problem. Outcome... Disaster If you see an issue. Own it. In another team I was a PO in was a totally different experience. Everyone felt that they could share ideas. I actively encouraged it. We had testers suggesting features and opportunities to improve revenue. Developers suggesting alternative options which were more simple to implement but gave the same outcome that the original proposed design. Outcome. Best sales figures. Huge NPS swing

An obvious and one of the mostly visible anti-pattern in scrum teams. I have seen companies taking the scrum practices serious but not this one. Most of the companies have workarounds to these three roles and therefore, might not be able to succeed. It's worthwhile to pay attention on the prescribed roles and get closer - specially, Scrum Master role and Product Owner roles would never be played by one person due to their accountabilities - Healthy conflicts and creative disruption would be more beneficial than avoiding such. I have seen product owners are there in most case but not scrum masters. Evaluating the role accountabilities and ensuring that these roles are defined would hugely contribute to effective scrum teams.

Roles are dependent on how the team operates and who you have on the ground at the time. I always encourage the team to ask themselves - how do I add value to how we work as a team? Then facilitate discussion with the team why these roles exists and how they add value. then execute on agreed roles/scope then retro.

To prevent sprint overload, establish a clear definition of "done" and strictly adhere to it. Make sure team members understand that incomplete work should not be carried over to the next sprint. If necessary, create a "Done" checklist that everyone can refer to. Additionally, involve the team in the sprint planning process to ensure they have a say in what's committed to the sprint backlog

This is where sprint planning helps. Take this opportunity to ensure backlog items are within the sprint goal and allow breathing room within team velocity. Backlog items should not max out the team’s capacity at the start. This allows for flexibility in the event of unplanned circumstances or events. It also provides room to either 1) Address technical debt or 2) Work on other backlog items if time permits.

Most of the teams I had worked previously, overlook this aspect - mainly due to how product leadership lead them. Expect the highest value delivery by scrum teams, yet, high performance comes when teams are focused on a few important priorities at a time. Remember the magical term each product owner and scrum teams must utter daily - "Sustainable Pace" - Your effort must be to achieve a sustainable pace without any exhaustion or burnouts. How so? Prioritize your roadmap, pick one a or a few priorities at a time - slice these priorities into stories and groom and prioritize your backlog - do this often so that ever sprint, you pick up the top priorities. More importantly, handle adhoc work carefully. - they must not distract the sprint!

Avoid Overcommitment: During sprint planning, set realistic goals and avoid overloading the team with too many tasks. Overcommitment can lead to rushed work, quality issues, and burnout.

Gently prompting the team about "carryover" work tends to help with avoiding sprint overload. Focus on the sprint goal, the commitment to only doing what is needed to accomplish the goal, it key to avoiding this challenge. The work will be in the backlog for the next sprint. It won't go missing.

Fear of failure and lack of trust could lead to silo mentality. It's important to celebrate both victories and failures, fostering a culture where we can experiment and safely fail, together. Pairing even on new topics can be an important tool to building trust and sharing knowledge among team members. Occasionally prompting the team to informally present new things they learned or found interesting, or even something they're particularly knowledgeable about can also help and encourage the same from others. Soft-promoting rotation of task technologies and helping amongst team members also goes a long way. Finally, even new members can bring new insight to complex topics and it's important to have everyone feel safe acknowledged and heard.

One, I still think there is value in sprint planning & backlog refinement. The team should look to establish a team velocity. I still believe in load factors. If they can plan together, establish a team velocity, and decrease that load factor, it will be a big step towards decreasing silo mentalities and practices. Ultimately they have to own it, and have a shared accountability. Two,something I miss about physical boards is the ability to not have “assignments” and probably could be done electronically… make it a team board; the standup has to have a level of self and team awareness, accountability and ownership. Find a way to eliminate individual accolades; allow the team to self govern and performance manage (a whole other topic)…

Encourage experimentation and learning from failures. Team members should feel safe to try new approaches and learn from mistakes without fear of blame.

Very common pattern in many teams - We tend to create different silos when we have narrowed focus and lack of alignment o the bigger goals: Few silos quite obvious: I am senior engineer I am too junior We are devs and we don't QA We are QA and there could be so many more... In order to avoid these silos, create a collaborative environment, discourage silos thinking and approach. Mob programming and pair programmings work best. I often use the daily scrum to ensure, team think as a team, not just individual plans but a consolidated , committed-daily-plan. In the individuals can discuss their contribution. Use the information radiators to make the discussions, decisions and progress visible to everyone. Fix the culture to be supportive

To overcome the detrimental effects of a silo mentality, promote open communication and knowledge sharing across different roles and expertise areas. Support a culture of collaboration where team members feel comfortable reaching out for help and offering assistance to others. You can eliminate the silo mentality and create a united team that works cohesively toward shared goals by breaking down information barriers and creating an environment of mutual support.

Scrum is a powerful framework but it should not be treated as gospel. The idea that scrum should be followed without change is antithetical to the underlying spirit of agile. No one should be afraid to modify their scrum process to make it work for their team. When a team begins to question the value of parts of scrum it is not sufficient to answer "that's what the framework says." Some parts of scrum can become an impediment to the team and the business. Scrum can and should be modified as needed to work for the business and the team. However before making changes to the framework it is important for the team to throughly understand the intended purposes of the parts they are modifying and any potential ramifications.

Most organizations believe that their situation and problems are unique. The truth is that nearly every organization regardless of the industry faces similar problems and the “yes, but we cannot do it here” attitude, is only a poor excuse of those who for various reasons are reluctant to change. So, starting with Leadership so that there is a long-term commitment for the transformation is crucial. Leaders must set clear vision, invest in training, and lead by example; foster a culture of trust and openness, ensuring transparency and safe communication, demonstrate a mindset addressing underlying fears and showing Agile’s adaptability through small, incremental changes, as well as positive reinforcement and support in case of early failures.

This is human psychology playing it's tricks - Who doesn't want to think, we are right - so the safest thing is to pretend that we are not far away from it:) When the teams don't have sufficient clarity about their practices and mainly when the practices are too shaky, it's obvious to fall into this trap... To fix this... Pay attention on the process as much as you would be serious on product goals.. You should try to improve the way you do the things. Start picking the most critical practices and fixing them one by one. Scrum is light weight by it's nature, so it's not totally impossible to develop a sufficient set of standards here. Ask your self, if you are doing scrum do scrum:) not something else.

Every team lead should be Agile advocate within the team, which includes promoting Scrum in organisations that are willing to embrace it. However, letting the team suggest different ways of working and trying out different things, processes and procedures is not anti-pattern. Team should decide how they should work, the lead is there to guide them and help the team to realise pros and cons of every approach they want to take.

A periodic refresher for the team about Scrum & Agile goes a long way in preventing this anti-pattern. Additionally, as long as delivery and team is not impacted, I presume we need not bother about 'Scrum-but'.

Major Anti pattern is Mindset. Many teams adopt agile but live with fixed mindset. To embrace Agile completely we have to adopt growth mindset. Welcoming change, accepting failures, criticizing work we are doing, empirical approach, developing less but with high value etc all these comes with Growth mindset. Agile teams anti patterns will reduce significantly if growth mindset is accepted.

To avoid anti-patterns that harm your Scrum team's collaboration, it's important to focus on effective meetings. Unproductive meetings are a real killer of efficiency and team spirit. Non-effective meetings lack structure, clear objectives, and purpose. Meetings that are not time-boxed often drag on, reducing productivity and focus. When meetings lack a clear purpose, they can become catch-all sessions, addressing too many issues without resolution. If participants do not have visibility regarding what is on the agenda, they come unprepared. It leads to repetitive discussions week after week, severely hurting team morale. These inefficiencies hamper team collaboration and progress, undermining the core principles of Scrum.

Provide Clear Product Backlog: The Product Owner should maintain a well-organized and prioritized product backlog. This helps the team understand what's coming next and ensures that everyone is aligned on the project's direction.

Often, teams deviate from the agenda of the scrum ceremonies, which is a very common anti-pattern. Team members will start discussing various options for architecture and solutions in daily scrum meetings, and it will no longer be time-boxed. Retrospectives often become a review meeting. Planning and grooming will have overlapping agendas. SM will have difficulty reminding the agenda, and 50% of the team will say So what if we discussed it? ?? Teams who successfully change their mindset take advantage of the Scrum framework by adopting it step-by-step. In turn, They take a considerable leap in transitioning from the Waterfall to the agile way of working.

Work on the midset is the key to have a successful, but it's not a simple way. Work with some numbers might help you to growth the midset on higher management, they understand numbers. For me the most valuable principle is the transparency, it will guide you always! Work with a clear backlog and the right priorities and show it to the team, it will help to guide the team to the right direction.