Agile purists have long preached that truly agile development can only occur with collocated teams. Meanwhile, novel coronavirus 2019 (COVID-19), has more and more people working from home every day. Does that mean we have to abandon ship and go back to waterfall? Should we burn our Scrum Alliance and SAFe certifications and race to the nearest PMP certification authority? Of course not. The truth is, while oftentimes preferred, colocation has never been truly required for highly functioning Agile teams thrive. Let’s start by looking at the Manifesto for Agile Software Development, the foundation on which all Agile frameworks are built.
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
Nothing in that statement says that the teams must be located in the same place. The assumption is that interactions and collaboration are easier when team members are in the same room. That assumption, however, does not infer that interaction and collaboration are not possible for teams working remotely.
The fact is that organizations like Zapier were founded to be entirely remote and agile has worked just great for them. I personally have set up Agile Kanban teams that included developers and test engineers who were located on-site, local remote, in Colorado, and in India. The key to success is sticking to the four tenants of the Manifesto for Agile Software Development and finding ways for your geographically distributed team to follow them. The path to this goal is as unique as each agile team. However, based on our experience and that of other experts, here are best practices in team building, communication, and collaboration to get you started.
Note: Many of Agile experts recommend requiring new teams to collocate during the “storming, forming, and norming” phases of team development. We understand and agree with the rationale for this. However, we have approached these best practices from a position where face-to-face, in-person, meeting and working are ill-advised or impossible.
Team Building
Software development is often thought of as a technical endeavor embarked upon as a solo journey by introverts who love the beauty of code. In reality, software development is a creative effort taken on by teams and reliant on huge amounts of trust between individuals. It is crucially important for Agile teams to act as teams. We have gone into creating a culture in a remote workforce in more detail in a previous article. Here we will focus on specific ways Agile teams can build the necessary comradery to be effective.
Individuals and Interactions are important parts of being Agile. For a collocated team, many of these interactions come accidentally and informally just from being in the same room. This is more difficult for remote teams, but it is just as crucial. As a leader, you can lead by example by sharing and asking about non-work subjects. Something as simple as starting the Monday stand-up with something along the lines of “Before you give your update, tell us the best thing that happened to you this weekend” goes a long way toward building rapport amongst the team members–rapport which is key to build trust, increase self-organization, and encourage ex parte communication.
Along those lines, the Agile ceremonies remain as, if not more, important with a remote team. Daily standups should continue to occur with everyone on video conference and actually standing up. Depending on your particular framework flavor (i.e. XP, Scrum, SAFe, etc.) there are other important meetings and milestones which normally occur in-person. All of these events should continue with a remote workforce. We have some links at the bottom of this article for tips on running the different ceremonies effectively while remote.
Communication
The inability to easily engage in ad hoc communication is a downside for any remote team. It is especially detrimental to the software developer who, in the absence of being able to simply speak up and ask a question aloud, now has to task switch, open up the chat application, ask the question, and wait for a response. However, this annoyance is more a matter of getting used to the new paradigm than an immense obstacle to overcome. Issues are more likely to occur in cases where a subject matter expert (“C”) would overhear a conversation between “A” and “B” in a collocated space and could provide vital details. In a virtual team environment, if that conversation is occurring between “A” and “B” in a one-to-one chat, “C” will never have the opportunity to fill in the missing facts. For this reason, team chat spaces should be encouraged whenever possible. If a conversation clearly becomes between “A” and “B,” they can take it to another room, but getting the initial discussion out to a large audience should be the first step. Any decision or question about function or architecture should be communicated to the entire team. It is better to over-communicate with your team than under-deliver (or completely miss) the product owner’s expectations.
What you communicate with a remote team will also differ from what is communicated with a collocated team. The Manifesto for Agile Software Development values “working software over comprehensive documentation.” With a remote team, you will find yourself documenting more. Asking clarifying questions, whiteboarding concepts, and interpreting the nuances of a user story is just more difficult for teams that aren’t in the same room. For a remote team, even non-functional requirements need to be discussed and documented at the outset. Test and acceptance criteria added to user stories is a good way to provide more insight into the expected outcome.
We have more on general communication best practices in our articles on working remotely from an employee perspective (“Working From Home: Not as Easy as It Sounds”) and on “Maintaining Your Company Culture with a Remote Workforce.”
Tools
Quality, easy to use, collaboration tools take on a new level of importance for virtual development teams. For all other virtual teams, collaboration tools make work easier. For virtual development teams, they make work possible.
It all starts with your project management software. Jira, Trello, and Basecamp are just some of the options available to track and manage what is, has, and needs to be done by whom and by when. These software options are specifically designed for development teams. So, little customization or compromise is needed prior to use. And, they offer options like virtual Kanban boards to move your user stories from sticky notes on the conference room whiteboard to the digital meeting space.
Project management is the start, but it is in no way the end. For software development teams, a source code repository with a distributed version control system is the real engine for efficiency. Github, Bitbucket, and GitLab but a few of the options in this space. The use of these systems helps to create a culture of continuous integration. They also allow for work to be split between groups or teams (i.e. frontend/backend, database and services/frontend, etc.) but still kept in a common repository.
The “Best” best practice for Agile software development is to collocate your team. However, sometimes the best practice for Agile software development is at odds for what is best for your team. Following these high-level best practices will allow you to get your virtual agile software development team off on the right foot. As always, you should customize the strategies you use to build your team, the ways you communicate, and the tools you use to manage your work to best allow your team to develop software according to the principles of agile.