Project management that enhances our independent spirit
Learn how we manage projects at The Remote Company with teams that are scattered across the globe.
At The Remote Company, we’re a group of fiercely independent people. It’s part of our remote-first DNA. We’re a tight team of individuals who take full responsibility for managing our own work.
Before I started working as a Product Manager at The Remote Company, the project management (PM) approach was self-management. Each person decided for themselves how to manage their projects. And it worked!
Most team members in a small business setting can manage their own projects from start to finish without much help. But as we added more projects and people, things like shared goals, deadlines, communication, collaboration and team productivity become critical to building an efficient company.
Our growth forced us to reevaluate how we approach our projects.
We cherish our self-management style, but we also realized that we would not be able to evolve and serve all of our customers at the highest level without adjusting our PM process.
Our solution: implement an agile project management approach that is personalized to fit our style. Here are some highlights of our current system that helped increase productivity without losing our independent work mentality.
Why agile project management?
As a remote-first company with strong company values, we needed a project management style that would follow along with those values. We wanted a simple method, not an overly complicated one. We desired a technique that could embrace change as easily as we do. Lastly, we wanted a process that would allow all team members to feel empowered and motivated them to take responsibility.
We decided that agile project management met all of our needs.
Agile PM is a method based on the values and principles of the Agile Manifesto for Software Development, which fosters a collaborative environment, accepts change, and can quickly deliver products through shorter iterations.
By following an agile process:
We are putting a value on individuals and interactions over processes and tools
We are welcoming changing requirements, no matter where we are in the development process
We are communicating daily on issues or changes throughout the project
We are providing our team members with an environment and the support they need to stay motivated to get the job done
Our goal with agile is to allow each person to work on their own with a clear path while minimizing any confusion or obstacles. Here is how a typical cycle works for us:
Product backlog: The product backlog is a holding tank for all user stories related to the end product. It's the Project Manager's responsibility to groom and prioritize these stories for the upcoming sprint planning meetings. (groomed = prepped, prioritized, and ready for the team to work on it).
Sprint planning: During sprint planning, team members have an opportunity to review user stories, ask questions and share any "gotchas" that others missed. The goal of the planning call is to have a clear and finalized subset of work to address during our two-week sprint cycle.
Sprint backlog: The sprint backlog is where we add the user stories selected from the product backlog. These are the stories we'll work on during the upcoming sprint. The sprint backlog gives us a clear picture of what needs to be completed in the next two weeks, without being overwhelmed by the big picture tasks.
Sprint: The sprint is a predetermined time frame in which the teams work on the user stories in the sprint backlog. For us, two-week increments work perfectly. During the sprint, developers are working through each user story discussed during the Sprint Planning call.
All of the project management tasks in The Remote Company are done in GitHub for the development process. We utilize the Projects feature to create a swimlane view of the work. All of the user stories for the sprints will start in a “To Do” column, and as developers begin to work on their user story, they will move it from “To Do” to “In Progress” and so on—until it reaches the “Done” column. The goal of the sprint is to have all the user stories in the “Done” column.
Sprint demo: At the end of the sprint, the teams have an opportunity to demo the work they have completed to everyone else in their team, the Project Manager, CPO or CEO. Demos are critical in this approach, as it allows for the teams and internal stakeholders to review the product as its being developed and allows for adjustments to be made along the way—rather than when the final product is complete and it would be more time-consuming and difficult to make the changes. The demo is also a time for the developers to share their accomplishments with others.
Final product: Before the final product, our teams will rinse and repeat grooming the product backlogs, sprint planning, and sprint iterations until the final products are complete.
To give you a clear picture of how we work, here are the five main steps we take to manage projects.
Our five main steps to managing projects
Step 1: Writing user stories
User stories are part of the agile approach. They're meant to shift the focus from writing about requirements to talking about them. Our stories include a sentence or two and, more importantly, a series of conversations about the desired functionality.
When written in the voice of the end-user, it gives us all a clear picture of what we are building, who we are building it for and why. User stories typically follow this format or a similar format:
As a < user type >, I want < some feature/goal > so that < some reason >
Example using the format:
As a user, I want to provide my email address on The Remote Company’s website so that I can begin to receive helpful tips on how to work remotely and grow my remote business.
Step 2: Sprint planning
Before the start of a sprint, the teams hop on a video call to review the groomed user stories that their Project Manager has put together in a backlog. During this call, the teams discuss the user stories, provide time estimates and choose which stories will fit into their upcoming sprint.
Step 3: Two-week sprint cadence
A sprint is a short timeframe (1-4 weeks) in which the teams work on predetermined user stories. When implementing a sprint cadence to our processes, we determined two weeks was our sweet spot. It's enough time to get through a measurable amount of work while getting that work to a releasable state.
Step 4: Sprint demos
At the end of the sprint, each team member gets an opportunity to demonstrate the releasable work they've completed in the sprint. It's a time where we can see what was built, provide feedback and discuss any tweaks that may be needed. It's also a time to celebrate their incredible work!
Step 5: Rinse and repeat
After the sprint demos, the next set of user stories is planned and we start a new cycle. Our teams “rinse and repeat” until they have a final project.
Keeping teams aligned across time zones and individual schedules
All of our team members are scattered across the globe and while that brings a sense of diversity and flexibility, it can also create a few challenges. Luckily, these challenges can be easily overcome.
For our Project Managers, the main challenge was finding the best time to schedule meetings.
For example, I’m based in the US, while most of my team members are in the EU. For everyone’s convenience, we decided to plan our sprint calls in the morning for me (8 AM EST) and in the afternoon for the rest of the team.
This set-up satisfies everyone, as the team gets a few extra hours to review upcoming sprint tasks and have their questions prepared before the call. If a team member happens to be unable to attend the meeting, we make sure to have a recording available for them to review afterward.
Next to our video call meetings, we also use other applications to connect and communicate asynchronously.
Our main communication tools include:
GitHub: Used for specific task-related questions about projects
Notion: Used for personal to-do lists. We also share all of our company’s documentation here — from team information to guidelines, processes and onboarding documents
Slack: Used for general day-to-day conversation and discussions. Our Project Managers have a dedicated Slack channel where they connect to ask questions, provide tips and support each other
Our teams don’t require a fixed schedule to do their work. As one of our core company values, everyone is given the freedom to complete their tasks according to their own schedules. This allows people to schedule their day to work whenever they feel most productive and deliver their best work.
Internally communicating multiple product updates
The Remote Company manages four different products, each with its own Project Manager and different projects. As you can imagine, we have quite a lot of product updates every month! So how do we communicate these updates to the entire team?
To share the recent developments of each product, the Project Managers work together to create a monthly newsletter using MailerLite’s drag & drop builder. This internal newsletter is sent to everyone in the company and highlights new releases, features that are currently developed, and our plans for upcoming sprints.
Not only us, but all departments within The Remote Company send these newsletters. Every month, employees can read about support team successes, what marketing has been up to and which new people got hired. It’s a great way to connect and keep everyone updated about what’s going on within our company!
It’s all about scaling without losing your identity
Since moving to these easy-to-implement processes, we've seen improvements in our productivity, collaboration and accountability. Our team members feel more connected to the bigger picture while still enjoying a sense of independence and self-management.
This agile philosophy will enable us to maintain our productivity as our teams grow! I can't wait to see how our new methods will help us rock 2021.
