Do you work remotely or manage a remote-based team?
One of the challenges any remote team needs to figure out early is how they’re going to operate. It’s not like team members can turn around and have a casual chat with the person in the desk next to them – teams are operating across cities, countries and timezones.
Your choice of project management methodology is important. Admittedly, there are so many different theories, tools and options available out there, that it can be confusing when trying to make the right choice for your team.
Where can you start? We thought we’d break down some of the types and tools we’ve seen used with great success in remote teams…
The Kanban Method
The Kanban style of project management is actually also popular with teams who follow agile methodology (which we’ll get into next). Kanban was actually invented by Toyota in Japan many years ago and implemented in their factories. It helps to address the nitty-gritty details that make up a project as a whole.
How does Kanban work?
Any project is made up of multiple working parts; there are tasks within deliverables and processes within those tasks. Kanban helps to provide a view of what each component is and where it is at along the project journey.
If we take car manufacturing as an example, Toyota wanted better efficiency with their parts inventory. Attaching a kanban card to each part meant that workers knew exactly where to pick up work on a part because they could see what had been done already and what stage it was in. They could do the work, check off their piece then move it onto the next stage of the process.
The kanban methodology can be adapted to work for virtually any process or project type. Here are the three basic elements:
- Board – this usually represents and holds the entire project. For example, you might have a board called “Redesigning X’s Website.”
- List – this usually represents the stage of the project or process. For example, on your website redesign project you might have a list called “Client requirements” as your first list, and items from that list might move to “In production” when they are being worked on.
- Card – A card holds individual pieces of a project that are required to be completed. Usually, the card will move from one list to the next until complete. For example, you might have an individual card on the redesign project called “Refresh website fonts.”
Here is an example of what a board might look like, borrowed from Derek Huether:
What about remote teams?
A key issue for remote teams in using any kind of project methodology is how well they are able to collaborate. You have to put in place a good system for knowing who is working on what, what has already been done and the overall status of a project.
Using the kanban method for a remote team means having the right tools in place to facilitate communication and oversight. Let’s look at a couple methods that help to streamline kanban methodology so that it is suitable for remote teams:
How many different apps do you use to get your everyday work done? Many people find themselves suffering from “tool fatigue” and that their workflows suffer because they are using so many that it becomes difficult to keep track. Rindle brings those tools together into one centralized view. You can create workflows from multiple channels with easy to use boards, lists, and cards, and share these with team members.
Trello is a great kanban-style project management tool that allows you to create cards, lists and boards that can be assigned and shared in your team. For each card, you can add checklists, instructions, due dates or file uploads to the back of them. Trello integrates with Rindle so you can include Trello cards on your overall view of what’s happening in your business.
Agile methodology was developed for projects in which speed and adaptability are necessary. An agile project consists of short “sprints” during which a section of the project is delivered. It is a highly iterative method that allows for rapid decisions to be made about changes or additions to the project.
This is a very popular methodology within software development because features can be developed in sprints and it can shorten the time taken to create a Minimum Viable Product (MVP). It is suitable for any kind of project that doesn’t really need a “stepped”, one item at a time approach.
On it’s own, Agile isn’t really a full project management methodology, but more of an idea of how projects can be split up and managed. If we take kanban as an example, your agile project can fit in by splitting each sprint into it’s own board. Essentially, you’re looking at several mini-projects within an overall end goal.
Agile for remote teams
Agile puts a lot of focus on individuals and being able to work closely together in order to achieve what is needed in each sprint. At first glance, this might make it seem unsuitable for remote teams, right?
Consider this from Chris Brookins for HelpScout:
“In the past, this meant agile teams needed to be co-located to take advantage of high-bandwidth, face-to-face communication — at least, that’s been the prevailing belief across the industry.
Having led co-located teams, remote teams, and mixtures of the two, I’m convinced there are significant advantages to remote teams and that agile methods can be adapted to them.”
Brockes’ team have found agile to be possible if they bring together the right mix of remote-based team members with the right tools. They use tools such as Trello and Github, and deal with “daily standups” by having team members post the following to Slack at the end of each day:
- What they did since yesterday’s update.
- What they plan on doing before the next update.
- Whether anything is blocking them.
“With a deliberate culture of consistent asynchronous communication, team members can focus on their work while staying in the loop. Our engineers thrive in an environment that promotes autonomy, trust and flexibility. The end result is a motivated and productive engineering team that can spend more time delivering value for our customers and our business and less time in painful meetings and long email threads.”
The waterfall method is also often used in software development, although it was originally adapted from hardware manufacturing. This method is based on sequential steps with progress being made by going through phases, such as Idea, Analysis, Design, Development, Testing, Implementation and Maintenance.
Six Sigma is one of the many variations of waterfall methodology and assumes a great deal of control throughout each phase of the project. Waterfall is not as flexible as agile in that it doesn’t really allow for scope changes later. It also tends to be low-involvement in terms of client participation, generally with only two meetings – one at the beginning and one at the end of the project.
Waterfall for remote teams
A weakness of waterfall, especially when compared to agile methods, is that delivery times are slower and any changes tend to be more costly as they may involve going back several steps. However, waterfall works for remote teams because of some of its relative strengths:
- Waterfall requires very clear documentation, following a logical sequence for each project.
- It’s based on predictable timelines and clear communication. Status updates are easy to keep track of.
- Each phase has clear deadlines and requirements. Reviews are straightforward in that all tasks need to have been completed for the project to proceed to the next phase.
Waterfall tools tend to rely heavily on charts – Atlaz is an example of an application that works well with this method, as are bigger project management platforms that can adapt to different methods, such as Asana.
Which Should You Choose?
While we could have gone into other project methodologies (critical path, critical chain, scrum …) these methods outlined are some of the most common we see with remote-based teams.
A key to making any of them work is to choosing the right tools that provide good oversight of projects and facilitate clear communication. There really is no “best” method, but consider elements such as risk, complexity, business goals and project size before committing to a method that will work for your team.