How to Deal with Agile and Scrum in a Remote Environment (Updated)

Below you will find some tips on how we tackle them at Netguru. But before we go there, let’s debunk one myth:

Neither Scrum Guide nor Agile Manifesto forbids remote setups

Scrum does not mention co-location at all. One of the Agile Manifesto Principles states that The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. As a fan and promoter of remote work I don’t disagree. Face-to-face conversation in the most efficient and effective. But it’s not the only option and often our remote options are the best ones in the given context.

Diagram Copyright 2002 Alistair Cockburn

You have to go deeper!

If you live and breathe agile values, then remote agile is in your reach. But a lot of common techniques of agile can’t be copied from F2F to remote environment, thus agile in a remote environment can be harder to create and maintain.

I see that a remote environment can let mature agile teams thrive, while it can make less mature, less self-aware teams struggle. The challenges are real, and after overcoming them remote agile can be even more powerful than a collocated setup - when you minimize the downsides and harness the advantages to the maximum.

I know that being truly agile is possible in a remote organisation. I really like this definition of Agile - “able to adapt to rapidly changing market/environment”. After all, remote work is just another challenge for our adaptability.

Think about what is so great about being collocated. What advantages and opportunities do you have in such a setup? And then think about your remote team. How can you achieve the same results here? What solutions and tools would you need to emulate these opportunities?

A simple example can be: I see my teams build stronger connections when they have the space to get to know each other. For my collocated team it happens in the kitchen: they talk about their vacations, weekends, and afternoon plans. In a remote setup, I can make the Monday daily call a little longer and start a habit of sharing what we did during the weekend.

Building an agile team in a remote environment

In each team at Netguru we are continuously building a development and cooperation method that helps us deliver value to the client. The process/framework is always deeply connected to the Agile Manifesto and its principles and is usually strongly inspired by the Scrum Guide.

Building an agile team in a remote environment is a combination of two big challenges - being agile and building a team. Below I’d like to focus on the challenges that are especially common when you combine those two.

Two most important tips:

• Set aside some time for reality checks of communication and transparency, especially at the beginning of your team’s journey. In a remote environment it’s easier to miss some red flags.
• Experiment with translating exercises and activities to a remote environment.

Want to use a technique you know from on-site meetings?

It’s often possible - think about how the technique uses elements of physical environment, and how can you achieve it online. Use online whiteboards, shared documents like Google docs, and video calls (ex. you can split a 12-person call into four 3-person calls for work in groups).

Common challenges in managing remote teams:

Finding structure in chaos

It’s extremely easy to slide into chaos realm when dealing with software projects.

So many options in virtual space, all those decisions that are not yet made, and all the changes that will surely come. How to deal with that?

Our answer is: flexible structure.

A good example of such a flexible structure is the Scrum framework. It lays out some must-haves and leaves you space to fill it with content suitable for your product. Write down this meta-information on your product with your team. Naming team rules and flow explicitly is key for agile approaches, like the kanban principle - visualize the workflow.

With my teams I usually cover the following topics:

• Meetings flow - when will meetings take place, who needs to be there, what is the goal?
• Visualise our tasks workflow - usually I use a JIRA workflow here.
• What can I expect from…? - especially useful in bigger teams, write down roles in the team and what they can expect from each other. This is meant to be a group exercise, the process of forging shared expectations is more important than the outcome (written agreement).
• Use widely known agile techniques for describing the flow - write down a DoD, a DoR, a team contract, a release plan.

Do you have all this in your head? Great, let’s now share it with the rest of the team. A great tool for co-located teams is a whiteboard in the team’s room. My goal is to emulate this great tool and harness the power of online solutions to power it up. I usually use a Confluence page for that, but you can easily build a whiteboard for your team in any other tool. A good whiteboard is:

• Accessible by everyone
• Something you see when you enter team’s “virtual space”, be it a Slack channel, a Confluence space or a JIRA instance.
• Easy to edit and manage by every team member.
• A collection of relevant, engaging information.
  

Popular tools that allow you to create such a shared board include:

• Miro
• Trello
• Confluence
• JIRA Dashboard

Reality check:

• Do we have a shared understanding of our flow (team events, expectations towards our roles), is everyone on the same page?
• Did you agree on communication channels?
• Is information easily accessible and searchable for each team member?

Tips:

• Start with what you have. Don’t try to find a perfect solution, describe the processes already in place and then gradually improve them.
• Start with what you know. It’s easier to begin when you have a common ground. I usually start with the scrum guide setup and work with the team to find what we need to add or adjust.
• Build habits - the habit of looking at the sprint burndown chart at standups, the habit of starting the day on a shared dashboard, the habit of saying hello each morning on your chat channel.

Building trust

First steps may be hard, but when you focus on promoting self-reliance and maintaining transparency you have all the foundations you need.

Building trust is crucial for effective collaboration. I focus on building trust both inside the technical team and between the technical team and the client or whole business team on the client side.

We need transparency between development and business to make sure we are building the right thing. And we need openness inside the team to make sure we build it the right way.

Reality check:

• Is feedback communicated directly (not through a manager)?
• Do we have regular sprint retrospectives? How does the team behave there?
• Are impediments communicated immediately to the rest of the team? And to the Product Owner?

Tips:

• Agree with the team to always assume good intentions. If needed, remind each other about it. It’s a simple (but not easy) tool to steer away from playing the blame game and complaining towards actionable feedback.
• Agree on ground rules for cooperation:
  • How can team members grab each other’s attention during work time for urgent issues? At Netguru we use Slack mentions for that.
  • Do you want to specify some focus time during which you won’t react to non-urgent, unimportant communications?
  • The best idea is to have an agreed form for different kinds of communication.
• Communication:
• Make sure the team has some space for having fun together. Just a few ideas to spark your imagination:
• Introduce a funny part to your standup. In one of our projects, we had a daily joke, in another we showed our pets on camera when working from home, meaning other teams couldn’t wait to see what funny T-shirt our QA is wearing today.
• Have a channel on Slack with a more laid back atmosphere - Slack can be your watercooler, a place where your team talks and bonds.

Self Reliance & Self-Regulation

Remote work requires maturity.

Each team member needs to be able to take responsibility for their work environment and take ownership of their work’s organization. Just like in agile work.

Being a member of a self-organizing team requires first taking ownership of your work, and then expanding it to the whole team.

Trust, self-reliance of team members, and self-organization of the team are interconnected. You have to build on all those qualities incrementally - more trust means more space for self-reliance.

Self-reliance and self-regulation of the team is an important topic both in remote and in agile work. When building agile in a remote environment this challenge is even more important, because both the cost of the failure and the payoff from success is doubled.

Reality check:

• Does the team deliver the Sprint Goal at the end of each Sprint?
• Is the team accountable for their commitments? How?
• Is the responsibility shared? Do people help each other towards a common goal or just take responsibility for their individual delivery?
• Does the team take responsibility for achieving the business goal? Can they describe the current business goal and how are they contributing to it?
• Are we giving feedback to each other?
• Do you trust your teammates that they work as much and as effectively as you agreed? What would you need to trust them?
• Does the PO trust the team? Trust in their ability to deliver, technical guidance, work ethic? Ask them openly about it. What would your PO need to build this trust? Maybe they would like to join the Daily Scrum meeting (my advice - just as a listener, available for the team’s questions)? Or should you work on a more interactive, feedback-centered way to prepare and conduct Sprint Reviews?

Tips:

• Lay down the ground rules at the beginning of the collaboration. It’s much easier to self-regulate when you know the boundaries. In practice that means that as a PM I’m much more involved in creating practices at the beginning, and then I'm gradually introducing the team to take over the responsibilities.
• Write down expectations and agree how you will hold each other accountable. For remote teams, keeping this kind of agreement is even simpler than for collocated ones. I usually use a Confluence space to keep such agreements - it’s important to keep it in a tool that is already used; it can be a shared drive, a wiki, or even a separate repository.
• Leverage the daily standup. It is there to help the development team self-regulate. Is someone late to the standup or skips it often? Is the work of a single developer unpredictable and the rest of the team can’t rely on it? Spot issues like that and raise them openly in the team, understand why it happened, and find a solution together.

The project manager's role in managing remote teams

Every new team needs to find their structure to avoid chaos.

My first task when starting a new project is to help with that first, basic structure. Then I focus on building trust and transparency to make sure we are building a real team, around a common goal, and not just having a group of great specialists, each focused on their own mini-silos.

When the team is working inside this first frame, the next challenge begins. I’m there to help them build self-reliance (both as individuals and as a team) and make sure they will build self-regulation mechanisms for themselves.

During this process the team starts to take ownership of the frame they were given and adjust it to their needs - step by step they create new team rules, influence each other's behaviour, and learn from each other. My job as a Project Manager, or as a Scrum Master, is to be with them and help them with their transition and adapting to changes they encounter.

My vision of this journey was strongly influenced by the use of Situational Leadership in Mike Cohn’s presentation “Leading a Self-Organizing Team”. If you are looking for further inspiration, I recommend that you take a look at the whole presentation.

Remote work environment tips

Being agile in a remote environment is definitely possible, but can be challenging. You will have to focus both on all the challenges of building a team and the challenges of organising remote work.

At Netguru we leverage our experience in both and I know that they can easily add up to great synergy.

If you want to experiment with remote agile yourself, remember to:

1. Name your values. You need to understand your values first to make sure you share them with the whole team. Personally I see the Scrum Values as a good starting point for remote team values: Courage, Focus, Commitment, Openness, and Respect.
2. Meet with the team daily. Make sure to cover not only technical topics. You want the team to work out their values in practice - give them space to do that. A good start is to write down an agreement inside the team - a team contract where you will discuss how you plan to work and hold each other accountable.
3. Look out for communication gaps and conflicts. It’s easier to avoid unpleasant topics in a remote world and it’s harder to give impromptu feedback. Start with yourself - give small feedback, both good and bad, right after every call, every encounter.
4. And in the end - remember to leave the team space to learn from both successes and failures. You are not there to shield them from everything. Step by step, they should be able to handle more chaos themselves and become less dependent on your support.

Adapting agile to a remote environment is the next big step for the agile community.

It’s already happening in a lot of organizations worldwide and it’s a big challenge for every team and every organisation.

If you would like to talk about your challenges - reach out to me or join our webinar series. We may discover some new approaches together.