Agile and Remote Dev Teams
How to Use Agile to Manage Remote Dev Teams, from G2Guide’s Segun Osu
The way you manage a remote team’s work dictates both their success and yours. This is a summary of a session held by Wework Labs mentor Segun Osu, director of G2Guide.
Why agile makes sense for remote teams
Agile is designed to anticipate change and it helps provide the type of environment that great teams need to prosper – autonomy, mastery and purpose. Our teams typically consist of 4 to 5 developers, an agile coach/scrum master and a product owner. We proactively provide teams with a sense of purpose and direction, and keep teams happy to make them productive. In a nutshell, we build in team motivation by design.
How Scrum works
First, decide what work you would like to have done, in the format of a so called product backlog. However, unlike traditional project management, the scrum development team also has a key decision making role – you agree with the team which items of work they can complete within a set time period, commonly referred to as a sprint.
The product backlog actually consists of a pipeline of ideas for work that may be considered for completion in future. This feeds into another list called the sprint backlog which is a list of work items that the team thinks it can actually complete within a set time period, typically two to four weeks. Each work item needs to have enough detail for the team to estimate the effort required to complete the work.
We have sprint planning meetings to review the workload and 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 – possibly, complete with acceptance criteria. The team works unhindered for the duration of the sprint.
Every morning we have a daily standup meeting, to make sure that impediments are removed early. We also proactively encourage clients to rank product backlog items to make it easy for us to continuously identify high priority work – that will provide the greatest business value – in readiness for the next sprint.
At the end of each sprint, the goal is to demo the completed work and deliver a fully complete and potentially usable unit of software, rather than just work in progress.
Why agile scrum delivers results for businesses
Before agile became popular, long development cycles were the norm, users might only get to see the product on completion, but their needs may have changed. Agile teams work in shorter development cycles, sharing the output at regular intervals, iterating and adjusting course so that the product remains aligned with changing business needs. At G2Guide we use this framework to continuously deliver work that clients tell is of highest value to their businesses, providing full product demos 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.
At the end of each cycle we also formally review how our next sprint’s performance could be improved. We plan ahead and decide what should be included in the next sprint and continue to focus on clients’ business priorities. In a nutshell that is an overview of how we typically use the agile 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.
