Distributed agile: The Storm approach

How to run an agile project with a distributed team

The most recent Deloitte Outsourcing Survey found that outsourcing of IT functions was expected to rise by 31% in the forthcoming years. The reasons given by respondents for choosing outsourcing included cost management, to allow more focus on core business, address capacity issues and enhance service quality.

However, as the digital channel has become central to business models, we’ve found that organisations want more control over core systems but have become disillusioned with the effectiveness of traditional body shopping models.

In this post, we’ll explore how Storm works with clients using a distributed agile approach which allows close working with internal teams and alignment of incentives of all team members to achieve a common goal, as well as shared risk and reward remuneration models.

What is a distributed team?

A distributed team is a team spread across two or more geographical locations. As such, the team lacks a common physical space and relies on digital technologies in order to run and facilitate the delivery process.

Traditionally, all members of an agile project team would be in the same location. However, as Mike Cohn, one of the founders of Scrum explains, “having an entire team, especially on a large project, in one room, or even one building is a luxury no longer enjoyed by many projects. With multi-team projects being the reality, you need to know how to scale and how to work with agile distributed teams.”

The Storm approach to distributed agile

When a project requires integration with existing systems that are managed and owned by our clients, a significant amount of development work is needed by both partners to change or replace them.

In many cases, it’s impractical to have developers from both Storm and our clients working in the same location, so we need a distributed agile approach to plan, manage and control the delivery of a project. Our approach keeps the best of the Scrum framework and adapts it to operate across as many locations as needed.

There are two approaches we will generally consider when engaging with a client: either run one Scrum team dispersed across multiple locations or run two or more Scrums, with each operating in different locations.

Smaller scale projects

The distributed agile method is suited to smaller scale projects where members of the development team, across the contributing organisations, are likely to be collectively working on one integration or piece of functionality at one time, through to completion. We used this approach to deliver a recent project for the Scottish Qualifications Authority (SQA).

Scrum relies on clear and frequent communication and promotes this through a series of regular ‘ceremonies’ during a Sprint. During the SQA project, we followed this to the letter with:

• sprint planning meetings
• daily Scrums
• sprint review meetings
• sprint retrospective meetings

At the daily Scrum, which is traditionally a face-to-face daily huddle lasting no more than 15 minutes, members of a Scrum team provide updates on their progress with assigned work, ask quick questions and raise any blockers.

There are obvious challenges to holding the Daily Scrum when individuals are not all in the same place. To ensure the value of running these meetings was not lost, we used video conferencing with screen-sharing for these meetings, with all members of the Scrum in attendance.

With screen-sharing, the Scrum Master can run through a virtual Sprint backlog (using a project management tool like Jira, Trello, VSTS or Assembla), which enables each team member to provide an update on how they are progressing with assigned work, ask questions and raise any blockers.

This approach can equally be applied to all the other ceremonies, if necessary, but we try to get together face-to-face for the longer sessions when it is practical to do so.

Working with a single Scrum distributed across several locations relies on access to a task-tracking tool which is easy to access and update by every member of the team. We also advise using a dedicated Slack channel for the team to share updates, ask questions and to communicate more regularly outside of the regular Sprint meetings.

Larger scale projects

We have found the distributed agile approach most effective for larger scale projects where there are multiple partners involved in delivery, as well as multiple technologies (both new and legacy).

We work with all our partners to arrange our respective teams into several Scrums, each with their own Scrum Master. These Scrums are not always defined by location. Each team needs the right skills and personalities to achieve its goals. The factors that drive these decisions vary from project to project, but technology and project complexity are key considerations.

Scrum of Scrums

Each Scrum team runs its own Daily Scrum, operating as normal with all the team members, the Product Owner and Scrum Master in attendance.

When we scale the Scrum framework to support more than one Scrum, a good approach to managing the delivery overall is to setup a ‘Scrum of Scrums’. This is an extra ceremony where representatives from each of the Daily Scrums provide updates to answer what:

• has been completed since the last Scrum of Scrums?
• work is your team planning to do before the next Scrum of Scrums?
• current or predicted blockers does your team have?
• blockers could you cause another Scrum team?

Normally, each Scrum team sends one or two members, with one always being the Scrum Master.

The Scrum of Scrums can also be used for the Product Owner (or Product Owners when there is more than one) to liaise with the teams. They can identify dependencies or issues that might affect the deliverables or priorities defined in the Product Backlog, which ultimately informs Sprint planning for each of the Scrum Teams.

The Scrum of Scrums is also a good opportunity for the wider team to discuss up-and-coming dependencies and open issues with in-flight work. We advise projects with multiple cross-team dependencies to hold the Scrum of Scrums as often as they find practical.

Case study: Wood Mackenzie

One of most successful large scale projects we utilised distributed agile working on was for Wood Mackenzie. Working together to develop an innovative web platform that would transform their customer experience, we used the principles of Scrum to ensure two teams, operating out of different locations, could reliably work towards the same goals on the same platform.

The distributed agile approach allowed us to work seamlessly with our client, exploring opportunities and tackling blockers timely to ensure the project met the requirements on time and budget. With a substantial onsite presence at Wood Mackenzie and cross-site working by several members of each team, we established a strong relationship and shared understanding of what really mattered to them.

The method enabled all key individuals on the project to communicate with one another directly and resulted in dedication from initiation to launch. The individual Scrum teams were setup to work in similar ways by adopting and embodying the principles agreed at a wider team level. This ensured communication between the teams was open, transparent and clear, giving everyone a voice.

The success of the Wood Mackenzie project was testament to the effectiveness of distributed agile working. The full project team became a force to be reckoned with and were able to deliver a large, complicated platform on time and budget.

What have we learned from distributed agile working?

Regardless of what approach you take for delivering a project in an agile way with a distributed team, there are few principles and techniques that we have found useful.

Build a culture

Agile delivery is a culture, not a process.

In the context of a distributed team, a culture of shared ownership and common purpose is crucial to a successful project. Two (or more) locations with a shared vision, fair distribution of responsibilities and a relaxed but professional rapport is far more effective than a team which is geographically together but lacking in these areas.

Set clear and achievable goals

Project goals are no different to any other intention, target, ambition or desire – they need to be SMART: specific, measurable, achievable, realistic and time-framed. The culture of an effective team creates a safe space to honestly and collectively discuss and agree goals. A distributed structure often makes the frankness and honesty required to set great goals easier to achieve.

Use online collaboration tools

Since distributed teams by definition lack a common physical space – they need access to a suite of tools, which create a common virtual space. We are very fortunate to have access to a range of innovative digital tools, which when combined established agile processes and great project management allow distributed teams to deliver projects.

Traditional agile project teams are effective because they can manage a backlog of tasks and day to day work with minimal effort, while communicating in a natural and frictionless environment. We replicate these advantages in distributed teams using two key pieces of software:

Assembla – Our project management and ticket tracking system is an always-on device agnostic Scrum board in the cloud.

Slack – Quick questions, big questions and easily sharing files. Slack makes team communication easy, keeps our email inboxes clutter-free and helps us keep track of the conversations that matter.

Trust the Scrum teams

Good team culture, SMART goals and great tools are all crucial to an effective distributed agile project team – but the people in the team are the real differentiator. We work with our clients to get the right mix of skills and personalities in each location – so that we can get out of the way and trust the teams to deliver.

Get in touch if you're interested in learning more about this model of working on digital transformation.