If you’ve worked at an early-stage startup, you’ve seen a system break down before. There’s a process in place. It works (or the team thinks it works). It breaks. The team keeps using it because they don’t have time to fix it. Eventually, the team accepts that it has outgrown the system. They build and adopt a new one.
I knew that the project management process wasn’t working, but I wasn’t sure why. I needed to fully understand the problem before I could even consider solutions. I spent time looking over the system and trying to figure out exactly where it was breaking.
I discovered four major flaws that were causing the existing system to behave ineffectively:
Once I understood the problems with the process, I was able to set four concrete goals for the new system.
I decided to treat these goals as KPIs. With my goals in hand, I began to research existing solutions.
I sat down to research how other teams were approaching project management and what technologies they were leveraging to do it. I paid close attention to the tradeoffs those teams were making when they chose a platform.
I had used Pivotal Tracker in the past and found that while it offered in-depth analytics, it paid the price in usability and flexibility. Github Projects linked with Github but the engineers never wanted to use the Kanban board feature and often forget to close their issues. Keeping track of who was working on what began to take up 80% of my day.
Jira, a favorite of big engineering teams, felt too heavy for our small engineering team. Google Sheets would have made sense to our stakeholders but required too much upkeep for our needs.
Finally, we settled on Asana. The UI is pleasing, I could create both lists and Kanban boards, and it felt flexible.
Once I felt I had done enough research, I picked the smallest and most well-defined piece of the process that I could think of: the engineering workflow. I designed an MVP that we could test almost immediately. I started out with two “features:” a Backlog and a Sprint Board.
The Backlog was a prioritized list of tasks.
The Sprint Board, on the other hand, was a Kanban board that had 4 columns. Ready, In Progress, In Review, and Done.
And that was it! Once I confirmed that everyone on the team had bought into the adjustment, we went ahead and started to use the process. The key was that I immediately began asking for feedback, especially around the goals I was measuring the process against.
My team was happy to give feedback. One of the most important suggestions came from one of the engineers on the team. He asked if we could add more columns to the Sprint board. In my attempt to keep process as minimal as possible, I had allowed for too little complexity.
After some back-and-forth, we added two more columns to the board––Ready for Release and Live. This change made it easier to see what people were working on at a glance and it reduced in-person conversations about tickets.
As the number of projects we were taking on multiplied, my team also brought up that it became difficult to understand which tickets belonged to which project. We began to add the name of the project to the beginning of the ticket’s name.
For example, if the ticket was named
refactor scheduler feature we would change it to:
[CMS] refactor scheduler feature. That meant that the ticket was associated with our CMS, rather than our Alexa skill.
This small adjustment allowed us to remain flexible while still fitting in with our core value of minimal process. We could still use one board to work on multiple projects, instead of creating a different board for each project and having to check every single one of them.