10 Agile Best Practices for Remote Teams: Recalibrate Your Processes and Improve Efficiency

It’s hard to replicate these little interactions when working remotely. I’ve been managing Agile teams for the past 7 years. First, as a project manager at an outsourcing company, later – as a certified Scrum Master. It’s my daily duty at MindK to coordinate teams across 11 time zones, schedule meetings in the rare hours when everybody can be present and attentive, as well as collaborate with teams from different engineering cultures.

The pandemic was a big shock for everyone. Yet we had over 10 years of experience working with overseas teams. So I sat together with other project managers at MindK to create a simple A.G.I.L.E. framework that could be of great help whether you’re fairly new to the Agile concept, want to optimize internal processes, or start working with a remote partner.

• Align the team around the Agile values
• Grow the bond between distributed Agile teams
• Innovate as you obsess over customer needs
• Lead the team as a servant
• Evolve relentlessly
  
  

Align the team around the Agile values

It’s always a good idea to align yourself around the values described in the original Manifesto for Agile Software Development. Here’s how to make these recommendations work in the post-COVID world:

• Individuals and interactions over processes and tools → create small self-sufficient teams with the autonomy to innovate

Agile starts with small self-reliant teams. These teams should have all the necessary skills and expertise to deliver products from ideation to the customer’s hands.

Having good software engineers or QA testers is obviously not enough. Your team should include a Product Owner who identifies user needs to maximize the product value, a UI/UX designer who creates its look and feel, and a Scrum Master who facilitates the Agile processes.

You can also employ DevOps professionals to take care of automation and release cycles, Data Scientists for data-heavy projects, and cybersecurity experts to protect the product from malicious users. At the same time, Agile teams should stay small (7-10 people, max).

• Working software over comprehensive documentation → embrace iterative development

Most Agile teams work iteratively. They split a larger product into smaller parts that go from an idea to a ready-for-release state in a 2-week period called a Sprint. Each iteration starts with a Sprint planning session, where the team defines the task they’ll complete in the next couple of weeks. A Product Owner has to act as a user representative at this stage, asking themselves what features will deliver maximum value to the company and its customers.

The team maintains a product backlog – an ever-evolving list of features and tasks to be done. Before the start of a Sprint, the team will transfer the highest-priority features to a Sprint backlog that needs to be completed in one iteration.

• Customer collaboration over contract negotiation → continuously collect feedback

After releasing a new feature, the Product Owner should focus on collecting feedback, both from users and internal stakeholders. The team should analyze product and usage metrics to gauge the best way to satisfy customer needs. Running various types of usability testing is another great idea we started using at MindK. Giving your product to real users in a controlled environment can provide lots of valuable feedback and opportunities for learning.

• Responding to change over following a plan → learn from feedback and pivot if needed

At the end of each Sprint, the team will usually host a live demo of the new piece of software for key stakeholders. If they receive good feedback, the team will gather for a Retrospective meeting to discuss how they can do even better in the next Sprint.

But sometimes, your results might not be so good. You see, all products are ultimately based on assumptions – what your customers want, what the market needs, what your tech can achieve. Often, the only way to test these assumptions is to release the product.

I once managed a project for a Silicon Valley startup that was building a solution for managing offshore R&D offices. Its first version had the key features for hiring remote specialists, invoicing, and managing office equipment. Only after releasing the product did we realize our target audience had slightly different needs. So we used their feedback to redesign the product and launch a far more successful 2.0 version. Such pivots are very common among Agile businesses. After all, Twitter started as a podcast website, Groupon was once a consumer activism portal, and Instagram developers simply wanted to build a check-in app.

A cloud-based solution for the recruiting industry made by MindK [explore the case study]

Pro tip: keep your releases small and frequent

In 2021, Gartner surveyed 50 Agile teams to find how well they adapted to remote work. The conclusion was somewhat mixed:

• 92% of respondents were writing on average 10% more code (which is great).
• The total number of releases decreased by 21% (which is bad).
• The average release grew 64% larger (which is risky).

At MindK, we try to keep our releases small and frequent by using Agile team best practices and DevOps tools like Continuous Integration and Delivery (CI/CD). A well-made CI/CD pipeline can automatically merge code changes into a shared repository, run the build process, perform the necessary tests, and create a ready-for-release artifact. This makes it less painful to have frequent releases. On one of the projects I currently manage, we had a DevOps engineer who set up all the processes in Bitbucket Pipelines in about 40 hours. This saved hundreds of hours for our engineers who spent the next 2 years releasing new features without bothering the DevOps people.

Xelfer – a psych assessment app for choosing a career path that fits your talents and desires

Grow the bond between distributed Agile teams

Agile first appeared as a way to build software for co-located teams. The office environment creates lots of informal connections and face-to-face interactions that are essential for building rapport. When you see your teammates as more than just colleagues, you’ll go above and beyond to make them happy.

This is one of the reasons why it’s often so hard to scale up the Agile approach in large enterprises and distributed teams. The good thing is that you can easily overcome the distance barrier if you make a conscious effort to stay social, precise in your explanations, and attentive to people. At MindK, we created three simple rules for our distributed software teams:

• Follow the schedule. At the start of each project, I like to agree on a communication schedule that fits our client needs. When working with people from across the ocean, I try to make the best of the golden hours when one team has just started working and the other hasn’t yet finished their tasks.
• Stay attentive. Keep the face camera on. If you feel like the meeting has zero value for you (and visa versa) – just say NO. In advance.
• Be real. Have you ever spent several minutes on Zoom, trying to explain a serious issue to your team only to have your cat cover up half of your face with her cute butthole? Such interruptions are unavoidable when working from home. So our teams at MindK created a fun little tradition of introducing their pets during internal meetings.
• Schedule some casual time. I like to arrange a special meeting every now and then to drink a glass of beer, discuss our lives, or watch a quality movie together. We also take every opportunity to meet in person – throwing an office party, going to a paintball session together, or traveling abroad to work at our clients’ offices.
• Be a team player. Don’t mute the group calls. Provide feedback to your peers. Be empathetic, open, and sincere.

A young wizard at MindK school of magic and design, trying to identify the polyjuice potion among six unlabeled flasks. Only 3 of them are poison.

Pro tip: set the communication routines that work for all parties

Your communication schedule should work for all parties. Each time, I ask myself and my clients: Is it enough to have a status report once a week? Will they have time to attend our daily meetings? What medium suits them best? Are they Zoom fans, email aficionados, or face-to-face weirdos?

Agile rituals are important for creating a steady pace of work. Yet, they aren’t the 10 commandments you should follow to the letter. From time to time, I like to ask my team whether they’d like to add a ritual or remove it. This is the list we currently use at MindK:

• Daily stand-ups

These 5-minute meetings should happen every day (usually, in the morning). Each team member reports on the work they’ve done yesterday, their current tasks, and any issues they’d like to address. I recommend our clients visit the standups once or twice a week to get a better idea of the team’s progress.

• Sprint planning sessions

This is a meeting for the entire team to plan the work for the next Sprint. The Product Owner will usually work with UI/UX designer and Business Analyst to adjust priorities, detail the features for the next iteration, and create their designs.

• Sprint reviews

At the end of each iteration, our teams hold a meeting with the key stakeholders. We demonstrate the new features, collect feedback, and discuss any issues we have on the project.

• Retrospectives

After each Sprint, we gather to discuss any mishaps, review the processes, and improve team communication.
We also have smaller meetings – impromptu talks between developers in Slack Huddles and other Agile collaboration tools, design brainstorming sessions, QA test case discussions, and so on. I also keep a daily questionnaire where everyone can ask a question to a specific team member. Keeping everything in one file allows us to remember all important issues and decisions.

Pro tip #2: work on team motivation

Tuckman’s model of group development defines 4 stages of team performance:

• Forming – the team sets up its processes. At this stage, it’s essential to encourage team members to leave their comfort zones and stop avoiding conflicts.
• Storming – first disagreements arise between the team members. Encourage people to listen to their peers and go into the problem-solving mode.
• Norming – leadership gets shared among the team members. Invite your teammates to share feedback and fight the resistance to change.
• Performing – at this stage, Agile teams can work independently and achieve greatness.

Small things can mean a lot for the team motivation. For instance, I always want to finish our daily Scrums on a positive note (even if we have huge challenges). This way, your team will then spend the whole day working their best to solve these challenges instead of suffering from a bad mood. I also like to wish people a happy birthday by setting their photo as a background for a team call. And what would be better than a nice present? This can be as simple as a custom T-shirt or a gift box with stickers and memes we posted in the project’s chat.

Innovate with an obsession over customer needs

Most customers don’t care about your business or products (sorry). All they want is to get some value or solve their pains. The main task of Agile teams is to understand as much as they can about those core needs and find the best way to satisfy them.

Long gone are the days of multi-year plans and requirements that are set in stone. Most teams try to release a Minimum Viable Product (MVP) as soon as possible. This 1.0 version of your software should only have the core functionality necessary to get feedback from early customers. Selecting the features to include in your MVP is, therefore, one of the most important tasks for an Agile team.

Pro tip: build your backlog together with product vision

I’ve already mentioned that every product should have a backlog – a prioritized list of tasks and features to have in your solution. We tend to describe the high-priority items in greater detail during a Sprint planning session, estimate them and move to the Sprint backlog. The rest of the items can stay pretty vague at this point.

The Scrum Guide says that the Product Owner (PO) is responsible for creating and maintaining the Product Backlog. But important stakeholders like POs are often too busy or lack the technical expertise needed for this role. That’s why MindK employs professional Business Analysts to help the PO clarify the requirements and turn them into tasks for the team during requirements gathering workshops. These 2-day meetings can include all team members along with key stakeholders and user representatives.

The goal is simple – clarify the product vision, define its objectives, and intended users. For this purpose, I recommend personas that can help you put a human face on users with their unique needs and pains.

Save this information on a whiteboard, so each time you’ll have a question about a new feature – ask yourself “What would Nina think about it?”

Image source: pinterest.com

When you have a clear idea about your customers, you can better define your product vision:

• What are the goals of our product?
  What KPIs can help you measure the progress towards these goals?
  What motivation will drive people to perform actions in your app?
  What are the top-priority features you need to have in your MVP?

We like to ask these questions to every person in the room and write them down on a whiteboard. There are different ways to prioritize these ideas – split them into Must-haves, Should-haves, Could-haves, and Wishes (the MoSCoW method), use the Kano Model to sort ideas according to user satisfaction, or rely on the Product Owner’s expert judgment.

An Agile team should revisit the backlog after each Sprint. Collect feedback, monitor usage metrics, and track product KPIs on a continuous basis.

Lead the team as a servant

Old-school managers tell their subjects what to do, sucking out all the creative potential of Agile teams. To foster innovation, leaders must play quite an unusual role. Like experienced teachers, they should pose interesting problems for the team and allow them to find the answers on their own.

This style of management, proposed by Robert K. Greenleaf, is called servant leadership. This approach has been a mainstay at some of the world’s top companies, praised specifically for their leadership style.

In Agile, this role belongs to a Scrum Master. Usually, this is the most experienced member of the team – a Project Manager or a Senior Engineer with a knack for leadership. A good Scrum Master can:

• Organize the Agile processes and keep all meetings productive.
• Coach people on how to follow these processes.
• Teach and explain things to the team.
• Talk to stakeholders to clarify the business value behind the code.

Pro tip: encourage the team to take ownership over the project

Leading as a servant is only viable if the team itself is mature enough for the Scrum approach. Each team member should take ownership over the entire project – which is impossible if all you’ve got is a bunch of Juniors. You can, of course, only hire Senior and Upper-Middle developers with strong soft skills like we at MindK, but there’s another way.

Pair your Juniors with more experienced developers as mentors, while the Scrum Master teaches them the Agile processes. It’s also important to build a culture of ownership in your company. When some issue pops up on my project, I don’t single out a particular person – after all, we all could’ve noticed the problem earlier if we paid enough attention.

Evolve relentlessly

A mishap I often see in big organizations is that they want to switch to Agile overnight. They don’t realize that the approach is all about journey, not destination. A truly Agile company will never stop evolving its practices.

Take, for example, the Scrum Guide – one of the primary sources for any professional Scrum Master. One of its last updates was removing the limits on topics that should be discussed during the daily stand-ups. So it’s always a good idea to follow the latest Agile trends. But don’t adopt them blindly – everything needs to fit the goals of your project and add value to the team.

Remember, change is stressful, so keep talking to your team. Organize one-on-ones, check on your peers, and remain empathetic.

Pro tip: use your Agile expertise to embrace DevOps

Agile can serve as a good basis for bridging your Development and Operation teams. DevOps uses advanced automation tools and best practices of Agile methodology to:

• Cut the time-to-market.
• Increase the pace of innovation.
• Raise the product quality.
• Increase team productivity.
• Improve the deployment frequency and success rates.

Agile and DevOps work together to improve customer satisfaction. Companies like Amazon, Netflix, and Facebook all link their success to this powerful combo.

MindK started using DevOps more than 7 years ago, adopting it as one of the cornerstones of our company. The first step in this process was to separate environments into development, test, staging, and production. This frees up a lot of time for the Ops team to implement DevOps best practices like Continuous Integration and Delivery (CI/CD), automated regression testing, Infrastructure as Code, and so on.

DevOps expertise is sadly quite scarce in the market, leading to rising competition between companies. As of July 2022, LinkedIn lists over 97K DevOps vacancies in the US while the entire country has only 47K DevOps specialists. It’s no wonder that many companies look towards DevOps outsourcing as a way to bridge this skill gap. A free DevOps consultation is often enough to give you a roadmap for solving the key pain points in your delivery pipeline.

Conclusion

Agile first emerged as a way to build software in small co-located teams. However, many of its benefits got lost when companies switched to Agile with remote teams. Yet, there’s a way to fix this!

Practice shows – teams that embrace these Agile best practices can be as productive and effective as their office-dwelling peers.

Retooling your Agile processes can be challenging – whether you want to embrace remote work, open an office in another location, or collaborate with offshore partners. MindK has been building software for global clients since 2008. We excel both in engineering and Agile development. So don’t hesitate to message us if you need some help with your projects.