How did we improve our delivery velocity at Side?
I have been working at Side for almost two years now. I arrived as a back-end developer and have had the opportunity to be part of a lot of evolutions that led me, today, to be a product owner. One particularly challenging evolution was the increasing number of people in the team, which pushed us to adopt a squad organisation based on sprints. Today, each squad is attached to a business issue and is composed of tech, data, product management and design. The idea is to mix different sets of expertise in order to provide the best possible answer to our users.
We’ve tried different things in terms of organization, always iterating when something does not fit our team and context anymore. The last one we tried before migrating to an agile organisation was Basecamp’s six-week roadmap. The six-week roadmap model ended up being too strict, because the projects were scoped to specifically fit into this roadmap. So after a few iterations, we agreed that this model wasn’t matching our needs and challenges because we needed the flexibility that one-week sprints provide us today. We needed to be able to say, “Next week we are going to pause this project because we need to work on this project,” and that’s exactly what the one week sprint allows us to do.
At Side, implementing a new workflow goes through several steps. The objective is to have a system that makes people autonomous and responsible. We usually begin by understanding where we can put in place a framework. We try to see what works and what needs to be improved, the idea being to iterate as soon as necessary.
Bug tracking
One of the biggest processes we have in the product team is also one of the oldest — a project on Asana called “Bug Tracking”.
This project is where we gather all our bugs. It was created three years ago and we kept iterating on how we handle it. One year ago, I became the owner of this project, which is now part of my daily routine.
This project is important in many ways:
First, it is where all members of all teams can report any product malfunction. Anyone can create a new task and assign it to me. Then I label it in order to dispatch it to the right person.
Besides the obvious benefit of needing to be aware when a bug is discovered, it’s a way to make sure that we follow up on bugs as well as on users impacted by the bugs.
My responsibility is to quickly identify the criticality of a bug and to make sure that it is quickly solved, if possible; bugs are ordered by priority and each priority is handled differently.
We cannot necessarily fix all bugs and we sometimes have more urgent things to handle, so the bug priority field helps us plan those fixes.
As soon as the bug is fixed, we put a small description of what happened and how we fixed it, so that we can keep a record of the situation and alert users that the bug was fixed.
So for instance, if we get a P0 (a very critical, obstructive bug impacting a lot of users), the developers who are in charge of fixing the issue will stop what they are currently doing in order to work as a team and fix the problem. P1 are important bugs that impact fewer users, and so only the person in charge of the bug will fix it. P2 and P3 are less serious bugs that we either plan to fix during a sprint or that we tackle during one of the bug fixing weeks we do from time to time.
When developers are assigned to a bug, they have all the information they need because it has been evaluated and labeled upstream. They know which platform is concerned, who is impacted and if it is obstructive or not.
Another benefit of this system is that it gives us a general overview of our stability and lets us react quickly when any member of the Side team encounters an issue.
Cherry on top, since Asana has a task-followers system, we can add any person affected by the bug so that they can follow interactions and progress.
From discovery to delivery
At Side, the difference we make between discovery and delivery is the difference between being a product manager and being a product owner as well.
Product managers are in charge of defining the problems we need to tackle, aggregating different solutions they collect from all stakeholders, and managing the debate so we find the best outcome. Product owners, on their side, have to make sure that the delivery is going well. Product managers and product owners need to work together. The product owner is here to help during discovery, determining what is technically possible in terms of implementation by giving rough estimations (and aided by developers), and the product manager can help clarify any fuzzy points during the implementation.
Our processes during this phase of pre-implementation are as follows:
First, we have squad meetings during which product managers and designers are present. Once per sprint we have a “grooming” meeting which involves presenting or discussing a feature (depending on where we are in the discovery process).
Then, when everything is validated, the product owner writes out the tasks that developers will be working on during the sprint. These tasks are put on Asana using a standardized, structured approach: “Why are we doing this?”, “What is the corresponding design?” and “What are the rules?”
Concerning task definition, as product owners, we need tasks to be structured enough to quickly identify specific things like “How long is this task supposed to take”, “Is it a back-end or front-end task”, etc. Thanks to Asana, we can standardize this data with custom fields applied on a task, which also allows us to frame and unify the way we work.
The last step before the implementation is the “sprint planning”. The tasks that product owners have written are put into an Asana project called “Backlog”, one per squad. Then, during the planning, we prioritize what we want to tackle with product managers. Once that is done, we estimate what we are going to do during the following week. At that point, we are ready to begin a new sprint.
The implementation
As product owners, we have to follow up with the implementation of features so that we can help and make sure that all squads are achieving their goals.
One of the main issues we’ve had was visibility. It was hard, especially for the other business units, to know what feature was being worked on. At the beginning, we were a small team so it was easier to communicate. With a bigger team, it is now necessary to have more explicit visibility since it is impossible to be aware of what 25 other people are doing all the time.
We rely on Asana during the implementation as well. When we migrated to this agile organization, we began by creating a board for each squad with columns like “To do”, “In progress”, “Code review”, “Released”, etc. The idea was to have clear tasks that each developer could refer to during implementation. Besides giving each person a basic organizational structure, it also gives visibility for the people who need it.
We create reminders in order to make people autonomous, using mainly Slack and Google Calendar. Product owners also frequently sync with developers and their daily work, checking in with them on how they’re handling their tasks, helping them when needed.
During the sprint, tasks in the squad boards are like contracts between developers and product owners. This ensures that problems like bypass, special requests and ghost tasks don’t happen anymore. It also ensures that we can really plan and focus on what is important for the whole team.
Tracking our efficiency
With the product team growing, performance tracking became harder and harder. For managers, it began to be difficult to have a clear view of what subjects each person is working on, in order to understand any potential deviations. Working with four squads at the same time makes it harder to keep an eye on our deadlines and tell other business units when a specific feature is going to be released.
Since we use Asana for the bug tracking and all our squad workflows, we developed scripts via its API. The idea is to retrieve information on tasks and insert them into a database. From there, the data is consumed by visualization platforms like Looker.
We mainly track two things today:
- Our velocity during the week, week after week, for Insiders (employees of Side) and for squads.
- The evolution of bugs created in the bug tracking project.
Once the migration to a sprint organization was done, we were able to see our efficiency while also tracking and acting on any deviations.
For example, if during the first week of implementation of a feature, we see that the percentage of estimated hours completed is low, we can discuss the problem during our retrospective meeting (which happens on Monday) in order to get any obstacles that we did not spot during the week. We implemented this new organization step by step, and we wanted to be sure that what we were doing was working well. We had to iterate week after week to arrive at an organization that fit the existing roles in the product team.
Positive changes
The changes we made to become a more agile organization made us improve our workflows and invent new ones. Being more organized in our daily work allowed us to track our own efficiency and improve it week after week. All of this brought a lot of positive changes to the product team. One good measure of success is the roadmap completion we achieved during the first quarter of 2019. We had a very long roadmap and managed to get everything out in time, finishing the seven big projects we planned to do.
Whether on a personal level, a squad level, or the team level, it was quite satisfying, even if there is always room for improvement.
The more we grow, the more we need smart frameworks; but one thing remains certain — having a strong and adaptable team that strives forward together is the most important part.
And today, we know that we have a better and smoother delivery than before.
Asana is a task management platform: https://asana.com/
