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:
None of these phases overlap and every single one must be completed before the next one begins.
Waterfall works great for projects that:
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:
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:
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:
These tools are a "nice to have":
...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!