How Remote Developer Teams Stay Agile

There are many ways to tackle software development. One of the more popular ways is Agile. We interviewed Gosia Jezierska, our in-house Agile expert, on the benefits of using Agile over other software development models and how Agile can be used for remote developer teams.

Hi Gosia, thank you for taking some time out for this interview. To start off, can you tell me what Agile is and why you use it over any other way of working together?

Agile is an iterative approach to build and deliver software incrementally. It stands in direct opposition to the traditional waterfall software development model.

Waterfall breaks down projects activities like this:

• Requirement analysis
• System design
• Implementation
• Testing
• Delivery and maintenance

None of these phases overlap and every single one must be completed before the next one begins.

Waterfall works great for projects that:

• Are relatively short
• Are not complex
• Have fixed, clear, and predictable requirements
• Are well-documented

But the amount of unpredictability and uncertainty in modern software and product development is very high. Users' expectations and market trends change so rapidly that there's little justification for the Waterfall model anymore. Hence, Agile.

Agile focuses on:

• Constant introspection of and adaptation to changes
• Constant improvements to the product and the process, through regular feedback
• Fulfilling client requirements based on regular deliveries
• Close cooperation between the business team and the development team
• Self-organizing teams
• Less documentation (when compared to Waterfall)

The cost of making a change in Agile is low when compared to the Waterfall model, where an update in the requirements requires developers to move through all the phases again.

Additionally, with Agile, clients can see the results right away. They can verify whether the product meets the users' expectations by collecting feedback. In Waterfall, the final result is only seen after the last stage of the project.

At X-Team, the projects my teams and I are working on have rapidly changing requirements. That's why Agile is the best fit for us. We're able to deliver value to our users faster and we can meet their expectations by collecting feedback after each delivery.

That's a wonderful explanation, thank you. It seems like Agile is the way forward in software development today. But is Agile always a recipe for success?

A common misunderstanding of Agile is that you don't need analysis and planning anymore. But all the traditional Waterfall phases are still in use in Agile, except that they're situated on a task level instead of on a project level. These stages (planning, design, development, testing, delivery) create a repeatable cycle that's always followed by gathering feedback. The cycle adjusts to the users' needs until it's completed.

Implementing an iterative approach isn't a solution for fixing bugs that are caused by the lack of planning and scoping. The purpose of iteration is to process users' feedback. Proper planning, analysis, and task scoping cannot be skipped.

Implementing Agile also won't work if the organization itself isn't Agile. Agile isn't just a set of rules and best practices; it's a mindset too. It applies to everyone in the organization. If your team is trying to work in an Agile way, but management is autocratic and wants to have full control over everything, it'll be very difficult to succeed.

Similarly, if management wants to apply Agile methods to the organization, but the teams aren't self-organized and require a lot of micromanagement, there's a high risk of failure.

A newbie mistake is trying to use Scrum (because hey, everyone uses Scrum!) for projects that are very simple and predictable. Scrum is meant to be used for complex products. It's usually overkill for simple projects with a fixed scope. Of course, this doesn't mean that a simple project can't be done in an Agile way - it can! For example, a simplified Kanban flow can be a good fit for a simple project. But the team must remember to always use common sense and avoid complicating the process. Always follow the KISS principle.

How is an Agile sprint typically structured? What are the steps you go through?

A sprint typically consists of the following:

• Sprint planning: every sprint starts with a planning session. During the planning, the team decides which items from the product backlog can be delivered during the sprint. This is also when user stories are divided into development tasks and when the team sets the sprint goal.
• Daily scrum (stand-up): this is a short, daily meeting (max 15 min) where the team synchronizes and creates a plan for the next 24h.
• Sprint review: this is held at the end of a sprint. Stakeholders and the Scrum team talk about what's been completed during the sprint and adjust the product backlog if required.
• Sprint retrospective: the purpose of the retrospective is to review and understand what went well during the sprint and what needs improvement. The output here is a list of adjustments that needs to be implemented during the next sprint. This may result in better code quality and an overall improvement in the process, all of which will result in better quality and value of the product.

During the sprint, the development team focuses not only on development, testing, and delivery, but also on reviewing the prioritized product backlog, providing estimations, breaking down user stories, and working together with the product owner on a daily basis.

And what does a successful sprint look like?

It's often thought that a sprint is successful when the team has delivered all of its planned tasks. But it's not a failure if a team doesn't deliver everything planned for the sprint.

A failure would be if the team fails to deliver on many sprints or if they deliver on time, but have to sacrifice in quality. It would mean that the team hasn't learned from the previous mistakes they've made.

A successful sprint happens when the team reviews their work and draws conclusions. Agile is about constant introspection and adaptation, so success happens when a team improves their work and process to deliver the highest possible value to their users.

Here at X-Team, we work remotely. What are some of the challenges that come with a fully remote sprint?

Working remotely in an Agile environment is convenient and has a lot of benefits. But it brings some challenges too. The biggest challenge is syncing up with the other team members, who are spread all over the world and who are working in different time zones. It requires some flexibility from the team; someone might need to stay up late or have to get up early.

Interaction between development team members is also less intense when compared to regular office work, where everyone sits in the same room. That's why it's important to be proactive and self-organized, and to always raise an issue as soon as it occurs. A quick call or chat with someone from your team can quickly find a solution to a problem; it can be as effective as a face-to-face meeting. I also had devs on my team who were pair programming while working remotely. Not easy, but possible!

The final thing is that you'll sometimes need to wait for an answer to your question, because the person you're asking it to isn't online yet. It may take a couple of hours, or sometimes a day, depending on the difference in time zones. To avoid this situation, it's best to structure your team in such a way that working hours overlap.

And finally, what are some vital tech tools for a remote Agile team?

A "must have" for every remote Agile team is:

• A proper issue tracker: the most important tool for everyone in the team. You need to keep issues and their statuses up to date, and make sure that all the planned or in-progress work has corresponding tickets in the issue tracker. My favorite issue tracker is Jira, but there are many great issue trackers to choose from.
• A tool for communication, group chats, and calls: at X-Team, we use Slack for our daily communication. It's great for project-related discussions. I also use Google Hangouts for calls.
• A shared calendar: to remember about project events, additional calls, and any other planned activities (e.g. days off from team members).

These tools are a "nice to have":

• A tool where you can store all your docs: it's best to keep all documentation in one place and make sure it's always up to date.
• Product management tools: something that helps the product owner plan the product and maintain a product roadmap.
• Tools for sketching and creating quick prototypes: anything that helps to visualize the requirements.

...and many more, depending on your team's needs.

It's best practice to use only the most necessary tools and make sure you're not duplicating their purposes. I know that there are a lot of great apps out there that can help you organize your processes and work, and it's very tempting to try as many of them as possible, but it also costs a lot of effort to keep all those tools up to date and maintained.

That was very insightful, thank you so much Gosia!