In the context of the COVID-19 pandemic we are all faced with a very real and very new situation — we can’t be with our teams in the same way we used to. So what does it mean to be agile in a distributed or remote scenario?
This question is nothing new, we as an industry have been struggling with “the software crisis” for decades. We have a shortness of talent which means we need to distribute work to wherever we can find the right people. On top of that we have climate issues and unsustainable urbanisation which makes us more conscious of our own impact.
This means that being able to work remote is something which we have been able to choose as a competitive advantage for our businesses and teams. We have been able to weigh access to talent and environmental parameters against richness of communication and make informed decisions on a case by case basis — but as of now it’s not a choice for many people, it’s something they have to do in order to stay safe and productive.
Where does this leave us in regards to staying agile?
First of, I want to make clear that when I say agile I am referring to the four values and twelve principles that make up The Agile Manifesto — nothing more, nothing less.
The Agile Manifesto has a powerful first line:
“We are uncovering better ways of developing
software by doing it and helping others do it.”
Before going further I think it’s important to recognise that agile is about being better and helping others become better at developing software. This means we actually need to be delivering software to be agile.
This is further emphasised by one of my favourite principles:
“Working software is the primary measure of progress.”
Further more, it also means we have to reevaluate and change our ways of working continuously, especially when given new information. None of this is a hinderance for remote or distributed work however depending on your interpretation the following principle can be tough to navigate:
“The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.”
The worst part — it’s true. I truly believe this, there is no way to make it go away. However the principal states that it’s the most efficient and effective method not that it is the only method. If we look at “Media richness theory” video conversation is right up there — a close second behind face-to-face communication. This means that in a situation where face-to-face is not available, not viable or too expensive we should be able to deliver working software using the second best option — video conversation.
The other principles also carry a lot of merit but are fairly unaffected by the move to a distributed team. Instead I want to spend some time looking at the values of agile. I want to start right at the bottom — because what is found at the bottom is often overlooked — but what is found at the bottom is very important especially in a distributed scenario.
“That is, while there is value in the items on
the right, we value the items on the left more.”
The Agile Manifesto clearly states that there is value in processes, tools, documentation, contracts and planning — however it also tells you how you should prioritise those things. It is important to remember that agile does see value in these things, because we will need some of them in order to make working software — especially in a distributed team.
Individuals and interactions over processes and tools
You and your team always come first, even when you are working remotely. Our dependance on processes and tools becomes higher when we are distributed but it is important to remember that the needs of our team guide our process and tooling choices. Don’t pick a tool and build your work flow around that tool — pick a work flow and find a tool that supports it. If a tool or process is not supporting your team never be afraid to change it.
Working software over comprehensive documentation
Never compromise from getting working software out of the door but make documentation a close second priority regardless of if you are distributed or not. Documenting decisions, important comments and meetings is not comprehensive — it is necessary. Since the effectiveness of communication is severely hampered when working remote the level of necessary documentation will go up slightly. Things you may have said to your team now need to go on slack or in the comments for the story — both count as documentation.
Customer collaboration over contract negotiation
It’s always important to have good communication with your customer but it becomes even more important in a distributed scenario. Inviting to daily Q&A meetings, sharing status updates or sending one more update e-mail than usual might be good practice. Your customer might loose touch with the team during the iteration when there is no physical space to visit — it is important to reach out and pull them back in. Share success and tribulations in order for them to understand the progress of the project and avoid contract negotiation which may arise from suspicion caused by the loss of visual progress that remote work creates.
Responding to change over following a plan
Not much to say — just remember you are still agile even when you are remote. Your team needs to have mechanisms in place to share information and pivot quickly. That is why working agreements can be crucial — it’s important to know when you can reach the whole team and inform them about how and why the plan has changed.
As a parting thought I don’t believe remote or distributed work is more difficult than colocated work — I just believe it is different and most of us are not trained in this discipline and have not practiced it. We are now thrusted into this situation; without warning — we are thrown in at the deep end of the pool and our only viable option is to learn how to swim quickly. I believe we can do it.
Here are some guides we at tretton37 created to help our own employees, our clients and the industry at large become better at remote and distributed work:
