How to Use the Agile Framework to Manage Remote Dev Teams, from G2Guide’s Segun Osu

When you’re overseeing a remote team of developers, the way you manage their work and outcomes dictates both their success and yours. Labs mentor Segun Osu, director of G2Guide, held a Labs session all about working with remote development teams, including how to manage them and why the scrum agile framework is the way to go to ensure success.

Why agile makes sense, especially for remote teams

A big benefit of using agile is that it is designed to anticipate change and “for the team doing the work, it supports autonomy, mastery and purpose,” Osu says. “Our teams typically consist of 4 to 5 developers, an agile coach/scrum master and a product owner. Small close teams are ideal and you need to make sure that you create an environment that supports excellent communication and collaboration.  To do that with a remote team, you need the right tools. We use Jira to manage our projects, together with Slack, Skype and Joinme."  

“Most of the time, I think that the main objective–within a creative environment such as software development - is to make sure that you proactively do things that support having a happy team with a sense of purpose and direction.  Keep your teams happy because happy teams are productive teams,” Osu says. “Productive teams are motivated teams, and motivated teams give you shippable software, quicker with fewer bugs, more often.”

How Scrum works

“Scrum is not a methodology,” Osu explains. “It’s an agile framework.”  First, with Scrum, “you make sure that there is always a backlog of work to be done,” Osu says. “It may sound like common sense, but the number of organizations out there thinking that agile means you can work efficiently with a remote team, without some structure, is staggering.”

“You always need to have a product backlog—a list of things that need to be done, expressed as user stories (see below), simple definitions of each work item.  This feeds into another list called the sprint backlog,” Osu says. “That sprint backlog is essentially a list of work items that the team thinks that it can complete within a set time period, typically two, three or four weeks.

“During those two to four weeks, give the team complete autonomy because that will really support motivation and drive productivity,” Osu says. “Each work item needs to have enough detail for the team to estimate how much effort is required and complete the work without having to come back to you for more explanation. You work with the team in what’s called a sprint planning meeting to decide what is to be worked on so that during the sprint, the decision making has already been done. You’ve decided with the team, for example, that the landing page needs a large blue button to perform a particular task, it needs to have a dropdown list, it needs to run an algorithm, etc. You express your needs in the form of user stories - high-level definitions of requirements.  Once the sprint backlog has been agreed, you let the team go off and do it.”

During the sprint time period, “you have a very short daily meeting called a stand up,” Osu says. “During the stand up, the topic of conversation is what each person did yesterday to help the team achieve the sprint goal. And then, what will each person do today to help the team achieve the sprint goal, and finally, what are the impediments or work blockers that might cause delay along the way.”  At G2Guide we provide a resource to quickly address impediments directly with the client, so that the team can continue working without delay.

During sprints we work with clients and encourage them to continuously review competition, market developments, business needs and more.  We make sure that each item in the product backlog is ranked by priority.  That makes it easier to quickly identify the highest priority work for the next sprint.   And keep in mind that sprints are not somewhere between two to four weeks in length—they’re exactly two weeks, exactly three weeks, or exactly four weeks. “It’s a set time period,” Osu says. “And during that time period, the team is fully focused on completing the sprint backlog. And you’re anticipating and expecting that what the team gets done is actually usable at the end. That’s a really important point.”

At the end of each sprint you have a sprint demo where the team basically provides an overview of the work that was completed in the last sprint and together with the client discuss the next most valuable items of work, from a business perspective, to be included in the next sprint.  

Before agile became popular, “very long development cycles were the norm, your end users might only get to see the product when everything was completed but the product itself might no longer be aligned with business needs” Osu says. “What we’re talking about with agile is doing the work in shorter, iterative development cycles, sharing the output at regular intervals, iterating and adjusting course so that the product remains closely aligned with changing business needs.  The agreed output may be part of an unpolished MVP, but there should be the agreed business value in the work at the end of each sprint.  At G2Guide we use this framework to continuously deliver work that clients tell is of highest value to their businesses, at least every 2 weeks. For a client, that could mean being able to engage future suppliers, customers or even investors, sooner rather than later.  That’s a key part of the value of agile—you get a potentially usable product that aligns with your business priorities, after each sprint. You don’t have to wait until the end of the project. After most sprints our clients push the product out to users, show progress, and get feedback to improve the next iteration.”

“We also do what’s called a retrospective,” Osu says. “You look at the work and ask how your next sprint’s performance could be improved. And then, you have the next sprint planning meeting to decide what should be included in the next sprint so that you continue to work on business priorities, and the team has autonomy each time.”  

“In a nutshell,” Osu says, “that is an overview of how we typically use the scrum framework to keep teams motivated, continuously respond to change—market conditions and clients’ priorities—and get development work done, often within challenging time and budgetary constraints”

Learn more about hiring as an early-stage startup.

This post is based on content from a WeWork Labs programming session.

Interested in connecting directly with this mentor? Ask your Labs Manager for help.

You've successfully subscribed to WeWork Labs Insider
Great! Next, complete checkout for full access to WeWork Labs Insider
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content. Check your email If you are not already signed in.