One of agile principles is

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

You wonder, is it still relevant? Given that everyone is working remotely, is it true if face-to-face conversation is the most efficient way? Don’t you think we should revise the principle?

Before we think it is wrong, we need to look at Agile’s history first. Agile Manifesto was made in 2001 (which was 20 years ago!) and at that time, no one would ever think there could be a situation where everyone works from home. Thus, it is understandable why these 17 people wrote that face-to-face conversation is the most effective way to develop.

“Even before the pandemic began, companies have worked globally, having offices from San Francisco, Amsterdam, to Jakarta, where people don’t meet in person. The reality now is already different from what this principle says!”. Yes, it is true that now companies have distributed teams all across the world. But, rather than building a new framework from scratch to replace Agile, they try to adapt Agile in their distributed team. I don’t have experience in this area, but you can read more on this article on how to adapt agile in your distributed team.

What I want to emphasize, we can try to copy what these companies have been doing in adapting Agile remotely. In this article, I will explain how to successfully adapt Agile in remote from my perspective.

Intro to Agile

Before we dive deep into adapting Agile remotely, we should know Agile first. Agile is an approach used in software development by developing software iteratively, delivering in small parts, rather than launching everything in once. The Agile Manifesto covers four important values in software development:

• Individuals and interactions over processes and tools. In The Pre-Agile era, people tended to focus on making sure the processes and the tools were right. In Agile, it is okay if we don’t have the best process or tools. It is more important to make sure that individuals in the team communicate well.

• Working software over comprehensive documentation. Since we need to work iteratively in a shorter time, it is better to have working software faster than spending time in making comprehensive documentation. Making documentation is still important, but we don’t spend too much time on it as we did before.

• Customer collaboration over contract negotiation. Rather than evaluating customer inputs only in launching time, we try to consider customers' opinions at every specific time. If we use Scrum, there will be a sprint review in which customer/business stakeholders can give input on how we can improve the software.

• Responding to change over following a plan Agile is widely used when the requirements of software are not that clear enough. Obviously, because it is still not clear, the requirement can change at any time. We need to respond to the uncertainty and adapt to changes in requirements based on the priorities.

Aside from these four values, there are also 12 Principles of Agile Software which you can see here . One of them is that I have mentioned before, which says face-to-face communication is the most efficient and effective way of sharing information in the team.

Scrum

There are many methods of implementing Agile out there. One of them is Scrum. Scrum is a framework that helps teams work together. The main idea is that the team who works in developing software will self-organize their work, deciding what to do, who should do it, by themselves. If you remember, it implements Agile Principle that says “The best architectures, requirements, and designs emerge from self-organizing teams.”

Scrum team consists of following members:

• Product Owner. Product Owner is someone who is responsible for deciding the product goal, making the goal smaller and deciding the priorities of the product development.

• Scrum Master. Scrum Master is someone who makes sure that development is done in Scrum way. Specifically, he or she will lead the team in Scrum events. By having a Scrum Master that supports the Scrum team, the principle of “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” is implemented.

• Development Team. Development team is a team of people that are responsible for translating requirements to a working software.

I have mentioned about Scrum events which basically are processes that should be done in Scrum team. Not only explaining about the process, I will try to compare how we do Scrum events during remote work and pre-remote.

Scrum Events

Sprint

Sprint is basically a time period for the team to complete certain work. It is usually done in a short time, usually 2 weeks, to make sure the principle of “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” works. There is no difference between sprint time in pre-remote work and remote. We still do sprints in a short time.

Sprint planning

Before the sprint starts, we should plan on what we want to do and finish in 2 weeks. Product Owner will give objectives for the sprint and the Product Backlog Items (PBI). The development team will decide what they will do in the sprint, dividing PBI to smaller tasks, and discuss how much effort that they should spend by deciding Story Points. By having a bigger story point/weight, it means the development team should spend bigger effort to do the task. The team will also assign who should do the task.

Pre-remote time, we do sprint planning in person, and write the tasks in sticky notes and stick them to the board.

Alternatives: There are many alternatives to the physical board. We use GitLab issue boards to assign tasks to the development team. Personally, I feel by having tasks documented digitally, I can just go to the website directly rather than looking at the board which I can easily forget. I can also see tasks which are assigned to me directly.

Daily Standup

Daily standup is a quick short meeting where the development team will give updates on what they did in the previous day, what they will do after standup, and what blockers they are facing. It is called “standup” because it is very short and we can talk in turns while we stand up. Of course, since we don’t meet in person, we don’t literally stand up now.

Alternatives: We do daily standups at Google Meet. You can use any video conferencing app to do daily standup. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” principle is implemented through daily standup. I feel video conferencing apps are efficient enough so it is not only limited to face-to-face.

Sprint Review

After working for 2 weeks, we will show what we do by demonstrating the app to the stakeholders. The stakeholders will try our work and give feedback on things that we should improve. We try to fulfill “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” and “Working software is the primary measure of progress.” principles.

Sprint Retrospective

Remember the Agile principle which mentions “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”? Sprint retrospective tries to cater that principle. In a retrospective meeting, after working for a sprint, we will evaluate what we do, what things that make us happy, what we don’t like and what we should do for the next sprint. From my experience, once I felt that we had too many meetings and somehow I don’t like it because I have to do context switching between coding and meeting. Thankfully, I found out that I was not the only one who thought that because other people mentioned it during the retrospective. From the issue, we could find a quick solution, which was to cut unnecessary meetings. Alternatives: For now, we haven’t done any retrospective, but from my experience, MIro is nice for doing sprint retrospective remotely.

Note

Even though we can address blocker and ask help in daily standup, it doesn’t mean we need to wait for daily standup to ask for help! We can ask for help at any time. As a developer, I found out that asking for help is a bit harder during remote, since usually I just can tap the person that I would like to ask, but now, I have to ask in message. These are tips on how to ask:

• Give context to your question clearly. State what you have done (for example, you have searched solutions in StackOverflow, etc).

• We can ask for help synchronously by arranging Google Meet where we can share our work to the person that we ask. That person for sure will point out what we should do.

• Alternatively, there is a great app where you can code synchronously. My team and I use VS Code Live Server where we can code directly to our friends workspace. Interestingly, they can share their server and terminal so we can debug it directly!

Conclusion

From what I have mentioned before, Agile can be done even if we don’t meet the team in person. There are many alternatives that we could try to make sure the experience in doing Agile is the same as we do it in person. Just remember, individuals and interactions are more important than tools that I have mentioned before!