Product delivery: agile ceremonies in the pandemic
It was March 12, 2020 when our quarantine began very abruptly as in most of the companies. Work from home was not allowed at Red Ventures, so we had no clue of what would happen.
Fortunately, our tech-based work was not very affected by the home office. Almost all we did to build the product in the office could be done from home. To give you some context, I work as a Product Manager at iq, a fintech under Red Ventures´ portfolio. Our squad has 8 members besides me: 2 software engineers, 3 front-end engineers and 3 designers.
At the beginning, the impact was not felt. However, two weeks later we started feeling communication and collaboration issues. To rely less on goodwill and make sure everyone is aligned, we followed a path to strengthen some agile ceremonies.
In this article I´ll go through what we have been doing to improve efficiency and quality of our squad´s work during the quarantine. I´ll try to dive into the tactic level to be more concrete about it.
Sprint structure
Below you can see how the two-week sprint cycle works for us.
Daily
We didn´t do dailies before the pandemic and I thought it would be great to start doing it for alignment issues. Usually, only the squad participates, and it takes 10–15 minutes.
Change by bits
To avoid radical changes in a delicate moment, we started doing twice a week via Zoom. Then we tried three times per week, two days via Zoom and one day via Slack, using a bot integrated with Slack called Standup Alice.
Written dailies
I felt that the written daily had almost no value. The purpose of communication was seriously damaged, since almost no one read the others check ins. Besides, in the middle of a pandemic it is good to talk live to people and see how everybody is doing.
Final structure
After 3–4 weeks, we expanded the frequency to every day, apart from the Tuesdays and Wednesdays that we did the Grooming and the Planning.
Benefits
This ceremony has a huge impact on the productivity and communication of the team.
Some members entered the company after the pandemics had started, so it was important for them to build the confidence to reach out other team members to solve issues with code, business or design quickly.
Dailies also avoid that a team member develops a task in the wrong direction for too long. In a context in which you are not collocated, that is the difference of wasting 4h or 4 days of work.
Grooming
The Grooming took too long with never ending discussions. The fist step we did to solve this issue was to write the tasks more carefully and we managed to do that by ensuring that every task had the following fields filled:
- Description: what the task is about with pictures and elements to help with the understanding;
- Problem: what problem we are trying to solve with that task;
- Value: what value we expect to achieve with that task;
- Metric: what business metric we are impacting with that task (not applied to every task, for example: tech debt).
The second step was to separate the ceremony into three different pieces: Pre-Grooming, Grooming and After-Grooming
Pre-Grooming
It starts thirty minutes before the Grooming, and it is a moment for each developer and designer look carefully alone (not a real meeting) at the tasks pre-assigned for the following sprint and eventually create new tasks. It is a prep for the Grooming in which everyone must not only have the knowledge of what is on the plate, but also prepare questions and suggestions.
Grooming
The Grooming used to be led by the Product Manager. We shifted that, now the designers and developers tell what they understood and what questions or suggestions they have. That way is easier for them to grasp what is the problem that we are trying to solve and engage in meaningful discussions.
After-Grooming
By the end of the Grooming, everything is aligned and understood. The After-Grooming consists of every team estimating the story points by themselves or together, eventually with a tech/design lead.
At the end, there is a meeting with the Product Manager, if necessary, to solve any questions that came about during the estimation process and issues are discussed and solved.
Benefits
The improvement in the way tasks were written gave more context to the team and required a deeper reflection by whom was writing and reading the task, “Will we get this value if we solve this problem?”, “Will this metric be affected?”. That improve the level of the discussions and help the team align with the strategy.
The Grooming time was reduced from 1h30 to 45min. Besides, the meeting became more collaborative, which led to a better understanding of the tasks´ purpose and of the big picture.
Planning
Our old Planning worked almost like a second grooming, with a lot of discussion and tasks getting in at the last minute. With the Grooming reformulation, the sprint planning became what it is meant to be: the moment for team commitment of what we are delivering in the sprint.
The meeting went from 1h to 15 min. We did a spreadsheet to measure the velocity of the team and set up the number of points equal to the median of the last 3–4 sprints.
Then I aligned with the team if the amount allocated could be delivered or not and that´s it, quick-off, next sprint is on.
Benefits
The process of giving context, estimation and commitment lead to two main benefits:
- Objectivity: when you anchor the amount of work the team will do to its historical pace, it is easier to avoid discussions and get commitment.
- Predictability: we all know that startups are chaotic and very difficult to predict. However, that´s why we do short-term cycles in agile: to have control and predictability of a small amount of time. With this process, we are able to get more frequently to the end of the sprint with every task done and deployed.
Review
The Review is a huge success and one of the most celebrated moments of the sprint cycle. It is constantly evolving and the way we divide it at the time of writing is this:
- Demos: members of the team, usually designers or engineers, showcase what they have been working on in the past two weeks.
- OKR´s update: we analyze our current numbers in each OKR, what we are doing now and what are the next steps.
- Delivery revision: we show the burndown of the last and current sprint (Jira burndown chart). The developers are encouraged to speak up about the difficulties they faced and what led to the shape of the burndown line.
- Customer quotes: I gather customer feedback of many different channels: email, Facebook, App/Play Store, bits of usability tests sessions and recordings of customers calls. By far the most appreciated part.
Benefits
The Review is a very special moment for celebrating the work done, see how we are doing and get closer to the customer.
- Visibility: the developers and designers present demo their work to the upper management getting more visibility;
- Customer empathy: bringing the customer perspective to this meeting is very humbling for everybody, specially for developers and for the upper management, who have little contact with customers. When developers and designers see customers in pain, they get eager to solve the problem. It is a very powerful way of enhancing a customer centric culture.
Retrospective
The retrospective is done every two sprint-cycles (every month in our case). We use a custom FunRetro board to conduct the discussions. Everyone has 15 minutes to write positive and negative aspects in each category with further discussion of each comment.
After the meeting I send an email with the following template for every one of the team.
Benefits
Retrospectives are key for team development. Many changes for the better that we did, were firstly discussed in the retrospective.
Final takeaways
Being disciplined with process was essential to leverage our performance as a team. The key is to reflect and be flexible to change if something no longer makes sense or if there is a better way.