Amanda from MailerLite

Amanda7 min readRemote cultureJanuary 24, 2020

Project management that enhances our independent spirit

Project management that enhances our independent spirit

At MailerLite, 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 at MailerLite, 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 you add 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 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 new 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.  

From all practices, we decided that agile project management met all of our needs, so we decided to implement it into our process. 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:

Agile pm process

Product backlog: The product backlog is a holding tank for all user stories related to the end product. It's the responsibility of the Project Manager 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 2-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 2 weeks, without being overwhelmed by the big picture tasks.   

Sprint: The sprint is a predetermined time frame in which the team works on the user stories in the sprint backlog. For us, 2-week increments work perfectly.  During the sprint, developers are working through each user story discussed during the Sprint Planning call. 

Since we use GitHub for the development process, we decided to utilize GitHub’s 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 team has an opportunity to demo the work they have completed to the team, Project Manager, CPO or CEO.  Demos are critical in this approach, as it allows for the team 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, we will rinse and repeat grooming the product backlog, sprint planning and sprint iterations until the final product is complete. 

To give you a clearer picture of how we work, here are the 5 main steps we take to manage projects.

We keep it simple: 5 main steps 

5 steps agile pm

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 MailerLite's website so that I can begin to receive helpful email marketing tips and tricks. 

Step 2: Sprint planning

Before the start of a sprint, we hop on a video call to review the groomed user stories that the Project Manager has put together in a backlog. During this call, the team discusses the user stories, provides time estimate and chooses which stories will fit into our upcoming sprint. 

Step 3: 2-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 process, we determined 2 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 the incredible work of the team!

Step 5: Rinse and repeat

After the sprint demos, we plan the next set of user stories and start a new cycle. We “rinse and repeat” until we have a final project.

Scaling without losing our identity

Since moving to these easy-to-implement processes, we've seen improvements with our productivity, collaboration and accountability. All of our developers 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 the team grows! I can't wait to see how our new methods will help us rock 2020. 

Do you have a PM process? Tell us about it. We love hearing new ideas!

Amanda Lomanto

I’m Amanda, Project Manager at MailerLite. I’m usually behind the scenes helping our team build new things. While I’ve managed tons of projects, the best one was my wedding. Somehow between all the decision-making and saying “I Do”, I found time to hand-make invitations, menus, baskets and bridesmaid's jewelry.