One of the biggest challenges with remote work for the software industry is, how to execute. Many companies have long ago adopted agile ways of working, but like the original framers of the agile manifesto, nobody can foresee the future. Often the agile process for many companies has proven too rigid to go remote overnight and this isn’t just a problem it is existential for teams to continue to ship software.
While we’re on the topic of the agile manifesto, this seems like a good time to review:
Notice how it doesn’t mention anything about co-location or remoteness. It also doesn’t say anything about how to go about doing agile. The reason for this is that every team is different and agile is considered an organic process where self-organizing teams go about the business of shipping software. The manifesto is meant to serve as a guide but the principles of doing agile are really about feedback cycles at its core. Every team has different feedback cycles that inform, hopefully, how they go about doing agile in practice.
At the time the agile manifesto was written most teams were also co-located. As such many of the agile processes that have since been practiced were formed under a framework of co-location which does not scale well to remote distributed teams.
There are different grades to being remote as well, each with their own unique challenges. Fully remote teams that are geographically dispersed have their own friction points versus “remote” teams in the same general location/timezone. Commonly, there are hybrid models where part of the team is dispersed while a core part of the team is geographically centralized.
All these remote patterns present challenges in planning, organization, team building and culture management.
Now that teams are remote, even centrally located teams have remote challenges as parents are now having to adopt their meeting schedules around their children. Things like internet bandwidth could also be an issue in some parts of the connected world. All of these challenges make remote hard and agile project management harder.
Agile Tips and Tricks
If agile is all about feedback cycles, then the goal of agile practices is to shorten the feedback loop.
When remote teams are faced with feedback challenges it can be particularly daunting. Managers can no longer just “stop by” your desk and casually get a status update. Now, feedback attempts have to be made deliberately and with a purpose.
The first tip that should be obvious is that in order to make an agile process better, or any process better for that matter, is to gather feedback from the main stakeholders. In this case you want to make sure that you are performing a retrospective that captures meaningful feedback from the team.
If your team is not doing retrospectives or hasn’t done one in a while, it is time to start doing that immediately.
The next tip falls in line with gathering feedback and being responsive to change. What good is gathering feedback from the team to help tune your remote agile processes if you aren’t acting on that information to enact constructive changes?
Consider if your agile process is working effectively. Feedback from your team will help guide you, but there are a few places to start with agile if you are starting fresh or rebooting your process. In practice, we have found that agile principles that veer more towards lean agile approaches fit most situations better in a remote distributed context. A few of these approaches are listed below.
Continuous Agile
What is continuous agile? Well, simply put it is a backlog that never ends — typically represented by a Kanban board where teams stack-rank the tasks from top to bottom. It embraces continuous delivery principles along with lean agile principles. If your team is thinking about or has thought about continuous delivery and how to incorporate it into their agile workflow, the Continuous Agile website has a wealth of resources for product managers, project managers, and team members alike.
One of the tenants of continuous agile is the fact that it focuses on throughput rather than velocity which traditionally most agile processes use. When focusing on throughput, instead of a burn down chart teams can use a cumulative flow diagram to track progress. It’s of personal taste but we personally think the cumulative flow diagram to be more informative than burn down charts.
Shape Up
Is a different attempt at an agile workflow that incorporates designers into the process better than most agile frameworks. Shape Up is project management that incorporates design thinking, and typically has teams running in sprints of 3–6 weeks often with a week or two of “cool down” between cycles. This tends to work well for teams that often have an implementation cycle, and then a cycle of feedback and bug fixes. The cool down time is used by product managers to vet new work to be pitched to the team before the next “cycle” begins. We’ve personally seen this framework work well for remote distributed teams, especially when combined with tools like Basecamp that work well with the shape-up process.
One of the unique qualities about Shape Up is the way tasks are tracked using hill charts (via Basecamp). The idea is that as work is started, it is less clear and starting at the bottom of the hill. As things become more clear the progress moves up a hill. Finally when developers are in testing mode we see the task move down a hill. Hill charts are a great way to realistically gauge progress on a task vs. using estimations.
Lean Agile
Lean agile is all about eliminating waste and continuous improvement. Continuous Improvement is also known by the Japanese word: Kaizen. Just like with any agile framework, lean agile is about shortening feedback loops (eliminating waste) while methodically and continuously striving to improve/kaizen the process. This cannot be done without the healthy use of retrospectives to gather feedback from the team to see what’s working and what’s not.
One of the main benefits of Lean Agile is it is commonly implemented using a Kanban board, which gives teams a dashboard to see all work in motion and at rest.
Responding To Feedback
When responding to feedback from the team it’s important not to be dogmatic about the process.
When a process is not working or causes extra friction it should be noted and brought up during a team retrospective with actionable plans to fix it as the outcome. Teams should not be afraid to change and adopt pieces of different agile practices as long as they fit and work well for the whole team.
For instance, what if you have a process requirement where everyone must be at a stand up call at 11 a.m. every day, but you have team members on the other side of the globe?
This works well for some people and obviously not well for everyone. Perhaps this is even noted during a retrospective. One change we might think to make in this situation is to use a stand up channel in a communication tool of choice instead of a meeting. Then let people enter their daily updates by a given time each day.
This relaxes the requirement that everyone be present for a meeting and generally makes for a happier team (less meetings!). It also doesn’t fundamentally change the agile process in any way which is a win-win.
Another remote-agile tip to take from this example is that whenever information can be shared asynchronously, it should be. Keeping things as asynchronous as possible is nice because remote agile teams already have enough meetings to attend.
How To Use Meetings
Meetings are synchronous, requiring everyone to be present which is often great for increasing the fidelity of communication. Use meetings selectively but when you do have them, make them count.
In a remote-agile-world meetings are par for the course. You’ll have a lot of them and this is necessary to help drive planning, organization, team building and culture.
Culture is a new word not often brought up in the context of meetings. Culture is one of the main reasons for meetings in the remote sense. How else do you create a healthy work-culture if you’re not spending time spreading it, and conversely how would you spread it for a team that is remote?
Well-written communication can only go so far. As much as a team thinks their written communication can supplant this, it would be virtually impossible to trap the meta conversations that happen and curate them for the team to review.
If it isn’t obvious yet, meetings should take on a whole new dimension in a remote distributed setting. Not only are they necessary and you’ll likely have more of them, but they are the primary way by which teams replace the water cooler now.
The “water cooler” conversations are an integral part of virtually all co-located teams whether they choose to acknowledge it or not. It is an information highway and this is tough to replace once teams are fully remote.
One piece of advice with this in mind is to create time for light banter. Meetings can have some flexibility at the beginning or the end for the team to chat lightly, decompress or share some weekend updates. This will help remote distributed teams feel more connected to each other. It is time well spent and your team will thank you through the feedback they give.
Helpful Tools
Product and project managers that service remote teams will have to find the right mix of tools to use that compliment their processes. It’s important that the tools don’t add additional overhead for the team to use them, and that they provide meaningful value to the collective team when used. Note: That means it has to serve more than just who is running the project.
One indispensable tool is a virtual whiteboard of some sort that can be shared and preferably allows real-time collaboration among viewers. This type of collaboration helps a team stay and feel connected even though they may be continents apart. There are quite a few options out there, but we recommend the following:
Another obvious but indispensable tool would be what the team uses to conduct their virtual meetings. There are many solutions out there, but we’ve found great success using the following:
For project management, we recommend ShapeUp + Base camp, however one can still effectively manage a project with a free kanban board. Basecamp really excels at being a communication hub for your entire team but a free kanban board will give your team a visual heads up display of the project state at any time.
Among the best performing remote teams one thing is common, regardless of their project management style or agile flavor. They all maintain a team knowledge base. Knowledge bases for any team not only helps everyone share, distribute and maintain information but it allows new hires an on-ramp of information they can turn to. Having one feels indispensable once you have it.
Every team has their own preferred way of using or creating a knowledge base but many start out with a wiki or a simple shared folder of docs. There are several new tools available that help teams in this manner, bellow are a few suggestions:
- Notion or Roam if your team has a budget
- Github or Gitlab allows free project-based wikis and team based wikis if you pay
What’s important is that you start creating a knowledge base as soon as possible regardless of the implementation. Your team will reap the benefits immediately.
Wrap Up
Whatever your take on the remote experience is, one certainty is that post-pandemic many teams will continue to have remote challenges in some form or another. It’s hard to put the remote-cat back in the proverbial bag, so to speak.
Measure your own challenges and how remote has helped and hindered your team. Perhaps there can still be changes made, new tools or processes added or taken away, that help reduce friction.
Try testing where you can stay asynchronous and perhaps re-adjust your meeting schedules, or sprint structure to best make use of your remote team’s strengths and weaknesses. Consider how going remote changes everything from the corporate culture to managing people and projects.
It can be scary to introduce a new process or procedure but if you maintain good agile principles and gather feedback from the team early and often, small meaningful changes can be made that have tangible benefits. Benefits that over time will steer the team in a healthy remote-friendly direction.
Akava would love to help your organization adapt, evolve and innovate your agile initiatives. If you’re looking to discuss, strategize or implement any of these processes, reach out to [email protected] and reference this post.
