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.
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.
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).
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:
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:
Popular tools that allow you to create such a shared board include:
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.
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.
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.
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:
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.