How do you coordinate with other teams?

In my experience, along with the shared vision, we also need to plan for the timelines of the deliveries as well, it is important to row in the same direction but it is also important to coordinate the timing of the strokes of your ors as well. I have been working on a complex software platform where multiple product teams were working on delivering a major cross-dependent piece of work, there we all had a shared vision of what we needed to do, but major learning came from missed prioritization of internal dependent deliveries.

Defining a shared vision is essential because it captures the shared understanding of the goal of building the product. It is created by the Product Owner (often in collaboration with other involved parties) and guides the Scrum Team(s). It is similar to a North Star indicating where you want to go without the details on how to get there. A good Product Vision creates alignment around who the target customers are, what needs they have and/or what jobs-to-be-done we are trying to address, and what our product looks like on a meta-level incl. its unique value propositions. In addition, an excellent Product Vision also states how this product creates value for our customers and us as a business.

When delivery is going in the wrong direction, you will often find that the team did not take the time to agree on a shared vision - be it regarding how they work together, what they are delivering, what their customers expect from them, or even the quality standard expected of their solution. Without the shared vision, efforts go in different directions and teammates don't meet each other's expectations.

To keep any project on track, it's essential for everyone to be aligned to the same vision. One of the most important ways to do this is by ensuring that all communication happens publicly between the entire team, so that no one is left out of decision-making and no one misses key information. All important documents and artifacts should be stored in a central location that everyone can access at all times. And finally, ensuring that the entire team agrees on a definition of "done" can prevent excess team conflict.

Sharing the vision in Agile Scrum involves creating a clear vision statement, breaking it down into smaller user stories, and prioritizing tasks in the product backlog. Regular meetings like sprint planning, standups, and reviews ensure alignment with the vision. Transparent communication, visualization, and stakeholder involvement are key throughout the process.

Similar to any presenter, team members should read the behaviour and body language of team members to see the level of engagement when communication is happening. Some examples are nodding, active listening, asking clarifying questions, leaning in. When a communication ritual has gotten stale it's important to shake things up to help concentration and communication work well. This could mean changing the style of meeting, the location, the frequency. A retrospective at a cafe can make team mates more comfortable and willing to share their ideas. A stand up with a ball can control the conversation, inject some fun and maintain attention.

Communication channels are how information flows between stakeholders. The number of communication channels required to get work done increases exponentially as team grows. A properly-formed Scrum Team addresses this problem in 3 ways. 1st, the small number of team members allows for fewer communication channels. 2nd, cross-functional nature means the team rarely has to pull more people into the circle to complete work. 3rd, dedicated nature of the team means that there is as little wait time as possible, making those channels more efficient. Scrum teams have more options to reduce complexities of remote work with more straightforward communication channels. It is much simpler to schedule synchronous communications like Zoom conversations.

Do pay attention to communication the team has when not at their desk or in a meeting room. Having informal get together's to have some fun or just spend time together in a non-work context improves how the team communicates in a work context.

In my experience a daily stand up or sessions in kamban while there is no chaos stage in agile team: always a learning stage with too many learning curves helps a communication channel in the team.

The team is likely spread out due to varying time zones, a mix of remote, hybrid, onshore, and offshore arrangements. It's crucial to remember that significant cultural differences can exist within such diverse teams. Both the team and leadership must determine the most effective communication method that suits everyone.

In Scrum, respecting team autonomy is very important because it helps to create a culture of trust and respect within the organization. When teams are free to decide how they work, in what order, and by whom, they are more likely to be invested in their work, feel more ownership. Teams are more likely to communicate effectively with other teams. It also means the team can work more efficiently because they are not waiting for someone else to decide. Overall, it promotes team coordination, help avoid conflicts, better results and a more efficient organization.

The most critical element with autonomy is establishing clarity on what autonomy each team has, and what boundaries and dependencies are in place. This is the reality of Agile beyond a small 1-scrum organization - there will be set organizational criteria and dependencies on other teams, but as much as these can be minimized, and the autonomy of individual teams maximized, the better the outcomes will be.

This is important to get real creative and quality work within the team. The team members should be part of the decision-making to ensure they understand the overall picture - so they are doing more than just the work they must do.

Team autonomy is highly important. This is the reason it is always encouraged to have a developer instead of a lead as a scrum master. This helps avoid the assignment strategy and team has greater freedom and also accountability.

Nobody likes a micromanager. The tricks to helping your team have full autonomy without being anxious about the result are: 1. Provide complete clarity on the expected outcomes 2. Keep communication open. Let the team ask questions up front and along the way 3. Make sure the team has buy-in and can commit to the task at hand (no top-down directives!) 4. Establish psychological safety so they can bring problems to you without fear of retribution or being blamed 5. Break the goals up into milestones or set checkpoints along the way to check progress If you've done these 5 things, you can rest easy and let your team spread their wings knowing they'll do a great job.

In Scrum, managing dependencies is important because it helps to coordinate with other teams. Dependencies are relationships between tasks and functional units that define the work elements (stories, features, tasks) on which Scrum teams work. The dependency management process actively measures, analyzes, and works to reduce disruptions caused by dependencies from intra-teams or inter-teams, as well as external dependencies. Managing dependencies helps to ensure that the work of one team does not negatively impact the work of another team. Also teams can reduce risk of delays or other problems that could impact the project. Jira, SAFe, Maven tools can be used to manage dependencies, to ensure that everyone is working together effectively.

It is important to identify and discuss the possible dependencies and work on it ahead if possible. Some of the possible dependencies to consider include applying for licenses or upgrading hardware. Those processes usually take time to resolve and yet impact the progress directly.

Always brings a smile on face if stakeholders telling me that product backlogs can be written in a way that the there are no dependencies. How can we minimize the dependencies' between different teams? The first step is to determine if the dependency can be performed in one user story by one scrum team in two sprints. If not possible, I have a weekly daily scrum meeting with all involved teams so that dependency work can be shared and synchronized. Also, the testing of the software can be done by each team after creating a new repository path with the software of both teams after the team has evaluated their software changes first. And as described by Hui Sun Lee, hardware, network etc. dependencies are a completely different ball game.

I engage the architect(s) to be integral members of the scrum team, responsible for managing overall dependencies. Typically, there may be one or several architects based on the team size. Their role is ensuring the seamless integration of modules developed across various teams.

From my experience, I would say that this is the most difficult to coordinate and track, as it requires the deepest cooperation amongst team members, and is subject to the differences in priorities and sophistication / organization skills within the Team

Handling conflicts is important as it can help to improve communication, build trust, and increase productivity. Conflicts can arise in any team or between teams, and if they are not handled properly, they can lead to misunderstandings, resentment, and even hostility. By handling conflicts in a constructive way, teams can work together more effectively and efficiently, it also helps to prevent future conflicts from arising. It should be done in respectful and productive way. This can involve identifying the root cause of the conflict (act like a detective), finding common ground (mediator), and working together to find a solution that benefits everyone involved (negotiator). It builds a stronger team culture & improve overall productivity.

Here are several ways to handle conflicts between team members. Listen actively Communicate clearly Focus on the problem Find common ground Be respectful In addition, there are several conflict management styles that can be used to handle conflicts between team members with different personalities. These include: Accommodating Avoiding Collaborating Compromising Competing Each of these styles has its own strengths and weaknesses, and the best approach will depend on the specific situation.

A good sporting analogy when talking in the team about a conflict is "play the ball, not the man". Make sure disagreements are focused on the solution and there aren't any personal issues behind the discussions - call out any ego or envy. The best approach to avoid conflicts is to take time to develop the team relationships. Start with a social charter, out of work socials, real discussions at rituals - and the trust and understanding formed will reduce conflicts later on.

I encourage the team members to resolve any conflicts among themselves. Many of the disputes are tiny so they need escalations. If they can fix them - it also improves bonding as well. I got involved when they did not find a resolution.

Conflicts is a great internal measure of the health of the company. There are always some conflicts by nature of human being, but the nature of them is an indicator what people in company have in mind. Typically conflicts grown on the points that people are of more concern, by looking at their subjects you can easily understand what people actually care. This knowledge is very important for leaders and hard to gather any other way

Recognizing and celebrating achievements is crucial as it plays a very important role in keeping the team motivated and involved. It shows appreciation, for the work and dedication put in by team members fostering a team culture and enhancing overall productivity. Celebration builds trust among team members and improves communication. Furthermore, celebrating successes helps in identifying what is working well which should be continued. By acknowledging successes, teams can learn from their achievements. Leverage them for growth. This ultimately leads to better results and a streamlined organization.

As a team member, call it out if your team isn't celebrating success. It's highly demoralizing to finish a sprint or release, demonstrate the solution and then go back to delivering the next increment. Success has to be celebrated because it can't be assumed - many teams fail to deliver. Celebration leaves the team feeling more united, appreciated and motivated for the next push!

Recognizing team accomplishments is a powerful way to keep teams energized around the work they do. Frequent recognition feeds each person's sense of worth, so make the moment specific and memorable. Take time to highlight attributes that helped the teams focus on and achieve common goals.

One of the best things about Scrum is its flexibility and adaptability. Scrum is designed to work in a relatively uncertain environment where it isn’t easy to define the requirements and solutions before starting a project accurately. The Scrum team can amend change in any part of the project without affecting the project output.

At least one common meeting across teams to discuss dependencies and alignments. In case of dependencies with a specific team, set a meeting with all high-level decision-makers for the team. And before going to another team, understand what your team really needs and get answers to questions that they will have. After each meeting, Set clear expectations and action items and a timeline for action items. Build relationships with people, it helps a lot to specifically when you need to talk to people outside of your team.

One of the best things about Scrum is that it has so many built-in ceremonies to keep projects on track and teams aligned. Sticking to the defined Scrum ceremonies of Backlog Refinement, Sprint Planning, Daily Standup, Sprint Review, and Retrospective can create a solid cadence for the team and lots of opportunities for collaboration and communication. But don't be afraid to mix it up and do what works best for your team! At the end of the day, the best process for any team is the one that works for everyone.

For sizable projects, a "scrum of scrums" might be necessary. In my previous organization, with multiple scrum teams, we implemented a scrum of scrums to monitor overall progress. This consists of key representatives from each scrum team coming together.

In my experience, Kanban is often better than Scrum. Especially for inter-team tasks. Conditions: to be open minded, to accept only defined quality work and to reduce office politics to minimum. Scrum allow these to pass. Kanban not. Take it with a grain of salt, after applying in life. I don't expect to believe me, just try. Scrum do have it's advantages, too, just that until now, my experience overall with Kanban was better. Scrum-ban was pretty hard to follow by more that 2 people, less to see it's benefits.