How to be agile with agile
when remotely developing software for a client
We very often get questions about the agile method we follow in our projects. Is that Scrum or Kanban or maybe a variation like Scrumban? We know that there are companies who are strict about the method they use in their projects and treat it as a recipe for successful projects. We’re quite on the opposite side. We’re agile on agile methods. We like to think about them as a set of tools that could be picked and adjusted to the particular needs of a client and project. In this article, we share how it works in practice, when we lean towards scrum and when we prefer kanban. We also cover best practices for planning and retrospectives.
Lightweight approach
The first thing to realize is that each project is different and each client has different needs. We either join an existing team, that already operates in a particular environment or we become a separate team working directly with business client.
In the first case, the lightweight approach enables us to adjust to a specific situation. We need to operate within some fixed frames but we can pick and adjust parts of the agile methods that make a project run smoothly. It takes a mix of common sense, empathy, good communication skills and experience to organize a project in such a way that it makes the most out of available tools and best practices.
In the second case, we have more freedom in organizing the methods and practices that we follow. Sometimes it involves educating the client about agile. Still, again it’s about adjusting the methods to a particular project environment.
Basic frames that shape our projects
Although we’re not radical about any particular agile method, we tend to follow some common rules that are part of agile:
- We usually organize our work in a scrum-like way.
- Tasks are tracked using a kanban-like board (using any tool from Trello to JIRA).
- We work in 2-week sprints, having demos at the end of every sprint and planning sessions at the beginning. We try to have a quarterly roadmap to understand the long-term goals and broader context of a project.
- After each sprint we deliver an MVP — it’s a fully functional application with a minimal number of features.
Kanban vs. Scrum — when to use which
There are two aspects of every project that we take into account when considering a particular method. First, it’s the size of a project — in general for small, quick projects kanban works fine. For bigger, complex projects scrum works much better.
It’s usually connected with the second aspect, which is the scope of a project and how well it is defined. Scrum is especially helpful in projects that aren’t defined, that emerge throughout work. The method helps with organizing work within the complex environment. Kanban, on the other hand, works great for well-defined projects or really small projects where priorities are changing really fast, even a few times during one sprint. Also, for projects with completely independent tasks, that are more of maintenance again kanban makes more sense.
Few thoughts about planning
Planning gets overcomplicated easily. It usually consists of a few phases like understanding the business requirements, gathering the priorities, sprint planning based on planning poker and estimations and finally choosing tasks for the next sprint based on their velocity.
At the same time, a lightweight approach works really well in many projects. It’s based on the assumption that you can’t properly estimate a task until you actually start doing it. That’s why long-term planning sessions and estimations could last longer than the actual work. Sometimes it makes sense to simply let developers answer the question — What do you think — what can you accomplish this week which will move us closer to the goal? It’s been working for our teams in many cases. But it’s always something you need to check whether it works in a particular project or not.
Remote retrospections — how to make them work
One of the disadvantages of remote work is that it makes communication more challenging. It’s easier to miss out on someone’s reactions, bad mood or in general deteriorating atmosphere in a team. That’s why regular retrospections are so important. They let people vent, share their feelings and concerns. It’s time for catching up with any miscommunication that might have happened. We do regular retrospections — depending on the needs of a particular team it’s from every 2 weeks to every 2–3 months. Here is what proved to work in our case.
- Taking care of the setup
As basic as it sounds, for remote retrospections, it’s really important. We talk to the client and make sure in advance that everyone will be able to take part in the meeting with a camera and a good microphone. We ask the client to book a conference room and get the equipment prepared in advance. The quality of the video and audio connection plays a huge role.
2. Preparing your team in advance
We like to remind the team about the coming retro at least a few days in advance. People need time to reflect on the things that happened and the work they’ve done. Before the first retrospection in a new project we discuss its purpose and some ground rules that we want to follow, like: no pointing fingers, focusing on the problems instead of people.
3. Making notes
Every retrospection needs to have an owner who is moderating the discussion and writing down everything. We like to keep the whole idea really simple. You can use google docs, confluence or dedicated tools that help with information gathering and voting (groupmap.com, TeamRetro, Reetro). The goal is to have a history of what has been discussed and what are the action points. Without that the whole idea of retrospection becomes pointless.
4. Letting people vent
It is hard sometimes to confront difficult emotions and frustrations that have piled up since the last retrospection. This is, however, what the team needs. People need to vent, need to say aloud what they didn’t like, what didn’t work. Just make sure that everyone focuses on the problem instead of blame. Such honest and open discussion builds up trust and adds to the quality of communication.
5. Assigning action-points
We end up every retrospection with a list of action points that get assigned to people in the team. That way you set ownership and make sure that there are real outcomes out of the discussion. What helps, is also setting reminders on a Slack channel so that people don’t forget about their tasks.
6. Making it a habit
Finally, we like to think about the whole idea of retrospection as a process. That’s why we start every meeting with a review of action points from the previous one and we end up the meeting by setting the date for the next meeting in our calendars. That way, you see it as a continuous improvement effort instead of random meetings for pouring out the frustrations.
Get “Remote Software Development” eBook
Dive into our 10-years journey of building a remote-first company and get all our lessons learned.
Want to learn remote work from us?
We’re a software consulting agency helping companies grow through software. Let’s master remote work together!
