Recently, I had an opportunity to experience the SCRUM framework on a project involving multiple teams.
SCRUM is widely used in software development, startups, and other fast-changing environments, especially when a project is undefined and benefits from regular feedback from stakeholders or customers along the way.
Personally, I believe SCRUM was a good choice for our team. However, as we began applying its principles—different roles, user stories, sprint planning, reviews, retrospectives, and more—we found ourselves struggling with coordination.
SCRUM doesn’t offer detailed guidance on how to coordinate across multiple teams that differ in return time, capacity, nature of work, or experience levels.
Here’s the thought process I went through to address this coordination challenge.
Content
- Step 0: Decide Whether SCRUM Is the Right Fit
- Step 1: Clarify Team Responsibilities and Dependencies
- Step 2: Identify Team Limitations and Constraints
- Step 3: Set a Realistic Timeline
- Step 4: Define Feedback Deadlines
- Step 5: Establish Decision-Making Rules
- Step 6: What If There’s No Feedback to Work With?
- Step 7: Align Evaluation Criteria with Your Goals
- Final thoughts
Step 0: Decide Whether SCRUM Is the Right Fit

I’ll be honest—I skipped this step at first. But in hindsight, it’s one of the most important things to consider whenever you face challenges using the SCRUM framework.
I came across a study conducted by Thesing et al. (2021) that surveyed practitioners on the differences between Waterfall frameworks and Agile frameworks (such as SCRUM). They also included a questionnaire to determine whether Agile frameworks are a good fit for your context. Make sure to check it out.
Step 1: Clarify Team Responsibilities and Dependencies
The project I’m working on aims to deliver a service based on psychological research. Our teams include:
- R&D: Research and improve the product
- Software Development: Build and maintain the software and database
- Sales: Sell the product and gather customer feedback
- Social Media: Raise public awareness of the product
To start, I needed to clearly understand each team’s responsibilities and how they depend on each other. A mind map helped me visualize this (see below)

Here’s a summary of what I found:
R&D
- Depends on: Sales and Social Media for feedback on which topics to prioritize
- Informs:
- Sales and Social Media about new product features
- Software Development so they can update the software accordingly
Sales
- Depends on: R&D and Software Dev for updates on what’s available to sell
- Informs:
- R&D on customer reactions and suggestions
- Software Dev on feedback about product usability
- Social Media on customer interests and demographics
Software Development
- Depends on:
- R&D for product updates
- Sales for usability and feature feedback
- Informs: Sales and Social Media about new or updated features
Social Media
- Depends on:
- Sales for customer interests and demographics
- R&D and Software Dev for updates
Given the high level of interdependence, each team needs to regularly share feedback with others to help define the next sprint’s goals.
Step 2: Identify Team Limitations and Constraints
Limitations might include team size, experience levels, budget, time availability, or stakeholder expectations.
Knowing these helps us decide whether we’re dealing with soft or hard deadlines and whether we need to extend a sprint or an epic. These factors also influence how ambitious we can be in each sprint.
Step 3: Set a Realistic Timeline
Decide how often each team should sit down to report progress, receive feedback, and decide what to do next. Should it be every two weeks? Three weeks? More?
Keep in mind:
- Teams with different experience levels or workloads may require more or less time
- Epics might start or end at different times for different teams.
It’s OK if timelines don’t align perfectly—just make sure they’re intentional.

Step 4: Define Feedback Deadlines
Since teams depend on each other to plan next steps, each one should commit to sharing updates (via meetings, notes, or reports) before a certain deadline. This allows others to reflect and plan accordingly for the next sprint or phase.
Step 5: Establish Decision-Making Rules
This is especially important in exploratory or early-stage projects.
Agree on a set of values and criteria to help answer questions like:
- When should we drop a plan and move on?
- When is it worth continuing, even if results aren’t ideal?
These rules should be rooted in your team’s mission, vision, or guiding principles:
- What do we want to build?
- Why does it matter?
- How do we want to work?
- Who are we doing this for?
Step 6: What If There’s No Feedback to Work With?
Sometimes, due to different processing speeds, teams might not have fresh feedback from others. In that case, what should they do?
Here are a few healthy options:
- Take time to rest or reset
- Reflect on recent sprints
- Explore new ideas or test hypotheses
The important thing is not to stall, but to use the time intentionally.
Step 7: Align Evaluation Criteria with Your Goals
People will do what you reward them to do. How you measure progress should reflect what you’re trying to achieve.
You might be aiming for:
- Improvement over time: Set goals collaboratively, based on internal growth
- Benchmarking: Compare against external standards to reach a specific target
Check out my post on pre-test/post-test vs. benchmarking if you’re interested in diving deeper into this topic.

Final thoughts
As your team is trying SCRUM for the first time, the team has to learn both how to use SCRUM for their context AND run the project at the same time. It is better to take it slow and spend more time reflecting and adjusting.
Let me know what you think about my brainstorming process. These steps aren’t a silver bullet, but they’ve helped me think more clearly about how to coordinate teams in SCRUM—especially when everyone’s still learning.
*Credit to Khoa Huynh for training me on SCRUM <3


One response to “SCRUM: How to Coordinate When Teams Are Still Learning”
Thanks a lot for sharing <3