Since the global pandemic, there’s been a massive shift toward online work environments, making distributed teams the new norm. This change has turned traditional workplace rules upside down, pushing professionals to adapt quickly. Olanrewaju Oyedele, a Scotland-based product leader with expertise in Agile frameworks, has extensive experience managing distributed teams. Through this experience, he’s gained valuable insights into the benefits and challenges that remote work brings to product development. Here, Oyedele explores how Agile methods have adapted to this new reality and shares his strategies for navigating the challenges of remote teamwork.
What are the key characteristics of distributed product development teams, and how do they differ from co-located teams?
Distributed product development teams work from various locations, coming together online to create and deliver products. Since the Agile Manifesto was introduced nearly 20 years ago, tech improvements have made remote teamwork smoother and more effective. Here are the key traits that set these teams apart from those working in the same place:
Remote Collaboration: Team members work from different spots, using digital tools to communicate and collaborate. Real collaboration goes beyond just finishing tasks; it’s about sharing knowledge, solving problems together, and reaching team goals. Success here comes from a mix of expertise and perspectives, plus tools that keep communication clear, manage tasks, and help oversee projects.
Solid Communication Tools: Apps like Slack, Microsoft Teams, and Zoom are crucial for keeping everyone connected and in sync. These platforms make sure all team members and stakeholders are on the same page.
Asynchronous Communication: This type of communication doesn’t need everyone to be available at the same time. When you send an asynchronous message, you don’t expect an instant reply, which can be very impactful. Research shows people do their best-focused work at home. Sometimes, an email or a recorded message works better than a live meeting for things that don’t need real-time responses.
Virtual Meetings: Regular video calls or webinars keep everyone on track, help with decision-making, and build team spirit. Quick team check-ins, or “huddles,” work well for discussing progress, tackling any challenges, and staying aligned on goals.
Reliable Project Management Tools: Tools like Trello, Asana, and Basecamp help teams organize tasks, monitor progress, and share updates in real-time. Virtual whiteboards are also great for brainstorming and real-time collaboration, giving the team a digital “space” to innovate and plan together.
The biggest difference between co-located and distributed teams is the work environment. While co-located teams share a physical space and benefit from face-to-face communication, distributed teams rely on digital tools, which can sometimes lead to delays or miscommunication. Building strong relationships in distributed teams can be tricky since social interactions are limited, whereas co-located teams naturally interact in person more often.
Another significant difference is that co-located teams can easily communicate face-to-face, which can be more efficient for complex discussions and problem-solving. Distributed teams rely on digital tools, which can sometimes introduce delays and misunderstandings
Building strong team relationships can be more challenging in distributed teams, as opportunities for social interaction are limited, while co-located teams do have more avenues of face-to-face interaction on a regular basis.
How do you ensure that Agile principles are effectively applied across distributed teams with diverse working cultures? What specific challenges have you encountered while implementing Agile principles?
Implementing Agile principles across distributed, culturally diverse teams requires careful planning, clear communication, adaptability, and consistency. Here are some strategies I go with:
Pair Programming: So, I like to set up pair programming sessions where two team members work together at the same time, even if they’re remote. One person “drives” by writing the code, while the other “navigates” by reviewing it in real time. To keep it fair and fun, I’ve introduced a virtual wheel that spins to choose who’s driving and navigating. This setup works wonders for sharing knowledge, improving code quality, and bringing the team closer together.
Working Agreements: I make sure we set up working agreements right from the start. These are basically ground rules we all agree on—how we communicate, what behaviors we expect, and how we handle accountability. It’s a team effort to establish these, so everyone feels included and clear on expectations. And once we agree, we keep the guidelines easy to access for everyone.
Communication Tools: Since we’re all in different places, clear and simple communication is key. We use tools like Slack for quick messages, Microsoft Teams for video calls, and project management platforms like Jira or Trello to keep everyone aligned. I always aim to keep the toolset manageable—too many tools can be distracting—so we pick the ones that best cover our needs.
Regular Meetings: Regular check-ins are a must. Whether it’s backlog refinement, a quick daily stand-up, or sprint planning, I make sure we’ve got a schedule that suits everyone. The goal is to keep everyone engaged and connected, so we’re all moving forward together.
Defining Roles Clearly: Clear roles and responsibilities make a huge difference. I make sure each team member knows exactly what their role entails, so there’s no confusion or overlap. It keeps us focused and avoids wasting time on duplicate work.
Setting Response Time Expectations: We agree on expected response times so that work keeps moving without anyone feeling pressured. It’s a small step but helps a lot in making sure everyone’s on the same page about how quickly they’re expected to get back to each other.
Continuous Improvement and a Common Vision: We’re always looking for ways to improve as a team. Having a shared vision keeps us aligned, and everyone’s encouraged to bring in their ideas to make things better.
Speaking of challenges I’ve run into several types of problems while implementing Agile principles:
Lack of Face-to-Face Interaction: It’s tougher to build strong relationships and resolve conflicts when we’re not all in the same room. To help with this, I’ve started organizing team meet-ups a few times a year. We plan these well in advance (usually 3-6 months) to make sure everyone can make it, which adds a nice boost to our teamwork.
Maintaining Team Morale: Keeping everyone motivated and engaged is a bit harder when we’re all working remotely. I’ve found that regular check-ins and a focus on celebrating wins help, but it’s still a challenge.
Technical Challenges: There are always some technical hiccups—whether it’s video calls freezing, screen-sharing issues, or tool integration problems. These can disrupt workflow, so we try to tackle them proactively with backup tools and troubleshooting steps.
These challenges are real, but with the right strategies and adjustments, we can still build a strong, cohesive team that works well in a distributed Agile environment.
Can you share a unique leadership approach that has significantly improved digital product development in a remote Agile setting? What outcomes did you observe?
One unique approach I take for leading remote Agile teams is “Outcome-Oriented Goal Setting.” Instead of setting specific tasks, I focus on clear, measurable outcomes, encouraging the team to find their own creative ways to reach them. For example, I might set goals like “Improve customer onboarding conversion by 20%” or “Reduce user-reported bugs by 15%.” These goals are tied directly to key business metrics, giving the team a strong sense of purpose without telling them exactly how to get there.
With this approach, the team has the freedom to design their own strategies, building trust and avoiding micromanagement. I encourage everyone to try new ideas and experiment with solutions, maintaining an open feedback loop where results—successes and failures—are shared openly. We see failure as a valuable part of the learning process.
Here’s what I’ve observed from this approach:
Higher Team Engagement and Innovation: Team members feel motivated to push boundaries and try new things, leading to creative solutions and product improvements that wouldn’t emerge from a more prescriptive approach.
Better Alignment with Business Goals: The team builds a stronger understanding of how their work ties into the company’s objectives, helping them prioritize effectively and make decisions that support the big picture.
Improved Agility and Adaptability: The team becomes more comfortable adjusting their methods based on what’s working (or not). This flexibility reduces time-to-market and helps the team respond more effectively to user feedback or changes in the market.
Enhanced Sense of Ownership and Responsibility: With a focus on outcomes, team members take more responsibility for the product’s success, which reduces the need for oversight and builds a strong sense of ownership within the team.
This approach has helped us maintain a balance of creativity, accountability, and alignment with business goals, creating a truly engaged and adaptable team.
How do you foster collaboration and leadership in remote Agile teams, and what role do techniques like swarming and WIP limits play in improving team performance?
Fostering collaboration and leadership in remote Agile teams is all about balancing structure with flexibility to encourage ownership, trust, and adaptability. I take a deliberate approach that combines tech solutions with human-centric practices.
To keep communication smooth and active, I use tools like Slack, Microsoft Teams, and Zoom for real-time messaging, file sharing, and video calls. I encourage the team to use Slack for “huddles” during pair programming, which helps keep communication open and honest. Regular updates, challenges, and wins are shared as they come up. I also schedule frequent check-ins, both one-on-one and with the whole team, to make sure everyone’s aligned and feels supported.
We also do virtual team-building activities, and when possible, we plan in-person team days to strengthen connections and build a sense of togetherness. Encouraging team members to take ownership of their tasks and decisions fosters autonomy and responsibility, and I make sure to implement regular feedback loops—both formal and informal—to support growth. Recognizing and celebrating individual and team achievements goes a long way in boosting morale.
A useful technique I implement is swarming. In Agile, swarming means the entire team jumps in to tackle a single high-priority task or issue together. This approach is especially helpful in remote teams, where people can sometimes feel isolated or siloed. Swarming gets everyone focused on one task, pooling their skills and knowledge, which is particularly useful for time-sensitive tasks or complex issues like regulatory compliance.
Swarming works by having the team prioritize a critical task that’s either essential to the product or blocking progress, with everyone pausing their other work to complete it. To keep coordination tight, we use real-time communication tools like Zoom, Slack, or a shared digital whiteboard, which allows for rapid feedback and adjustments. We also establish a clear “Definition of Done” (DoD) for the task so that everyone knows when it’s truly finished. Done right, swarming improves team performance by uniting everyone around a single goal, making use of each member’s unique skills, and allowing everyone to contribute to the solution.
Another key tool I use is setting work-in-progress (WIP) limits, which cap the number of tasks that can be active in each stage of a workflow. Limiting WIP makes it easier to spot inefficiencies, boosting throughput and reducing the number of tasks that are “almost done.” This encourages a culture of finishing work completely, rather than juggling too many tasks at once. WIP limits also make blockers and bottlenecks clear; when an issue is flagged as causing a bottleneck, the team can swarm on it to get things moving again.
With WIP limits in place, the team focuses on smaller task sets, improving efficiency, reducing multitasking, and speeding up task completion. It’s important to set these limits based on team capacity, so that once a WIP limit is reached, no new tasks are added until a current task is done. This not only helps everyone stay focused but also highlights bottlenecks and inefficiencies early on. By visualizing our workflow this way, we can tackle root causes of any holdups and keep everything flowing smoothly, delivering value to customers faster.
Can you share a specific example where you led a distributed team through a challenging project, and how Agile principles helped you overcome obstacles?
I was responsible for guiding a team transition for a long-term project—one they’d been working on for about two years for a major client. This transition moved them from a focused, dedicated project team to part of a larger business-as-usual (BAU) team. The BAU team had a broader role, managing not just one app but a critical part of the platform supporting the organization’s main product. This shift was challenging for everyone involved since the client was used to having a dedicated team and now had to adapt to sharing BAU resources with other clients.
To manage this change, we leaned heavily on Agile principles to keep things transparent, adaptable, and aligned with both the team and the client. Early on, we held a series of alignment meetings to explain why this new setup was necessary. Regular Agile practices like sprint reviews and retrospectives were essential in keeping everyone in the loop and responsive to any adjustments. This continuous feedback loop was key for monitoring the client’s expectations, building trust, and reassuring them that their needs would still be a priority.
With team members spread across various time zones, we relied on Agile’s focus on cross-functional, self-organizing teams. We created sub-teams responsible for different parts of the platform, ensuring there was enough overlap in working hours to keep communication seamless. We also used asynchronous updates via Slack and Confluence, so everyone could stay in sync without interrupting their workflow. We adapted Agile ceremonies to fit different time zones, using asynchronous options for things like daily stand-ups and retrospective submissions, which helped the team feel connected no matter where they were working from.
Prioritizing deliverables with a shared backlog also allowed us to meet region-specific regulatory requirements for each client. Agile’s iterative approach let us fine-tune our approach to each client incrementally, ensuring any urgent needs or regulatory shifts were handled quickly.
By sticking to Agile principles, we managed a smooth transition to the BAU model, kept client satisfaction high, and ensured the distributed team functioned smoothly across regions and time zones.
How does your approach to Agile product management change when dealing with B2B clients compared to consumer-focused B2C product development?
When working with B2B clients in Agile product management, my approach shifts quite a bit compared to B2C product development. B2B environments often involve longer sales cycles, specific requirements, and a need for customization and compliance. Here’s how I adapt:
Customer Collaboration & Stakeholder Management: In a B2B setting, close collaboration with client stakeholders is essential. Unlike B2C, where feedback comes from a broader user base, B2B projects involve tailored check-ins with a smaller group of end-users with specific needs. I set up regular demos and detailed discovery sessions to make sure we’re aligned and can adapt to their unique requirements.
Customization and Flexible Roadmaps: B2B clients often require features tailored to fit into their workflows. Agile’s flexibility allows me to keep the roadmap dynamic, adapting the backlog to prioritize features that align with each client’s needs. In a B2C project, I’d typically follow a more predictable roadmap based on market demand.
Prioritization and Value Delivery: Each release for B2B needs to show clear ROI or address a critical issue, so I focus on delivering impactful, highly tested updates, even if they’re less frequent. With B2C, I’d aim for faster, more experimental sprints to engage users and build interest.
Feedback Cycles and Testing: B2C feedback tends to be continuous and data-driven, while B2B feedback is usually more structured. I set up formal feedback sessions and sandbox environments where clients can test features before a full rollout. This helps us maintain Agile flexibility while meeting the reliability standards expected in a B2B setting.
Compliance and Security: B2B clients often prioritize compliance and security. While Agile favors rapid iteration, I build in “hardening sprints” and regular security reviews to ensure we meet regulatory and data security requirements, which are usually less critical in B2C projects.
Ultimately, in B2B, my Agile approach becomes less about reaching a broad audience and more about deep collaboration and clear ROI. By staying flexible and focusing on high-value releases, I can build trust with B2B clients and deliver a product that integrates seamlessly into their operations.
