By Asgard Team | Engineering
(Filipa, José, Hugo, António, Samuel, Sara and Nelson)
As discussed in the first part of this blog, remote work presented new challenges for our team, particularly in collaboration and communication. However, we found that the tools we introduced in our ceremonies effectively increased participation among all team members.
In part 2, we’ll discuss how we created a healthy work culture within our team while effectively using our work time.
Extensive Plannings
Our team is currently assigned extended features that may take several months to complete.
After receiving the functional requirements from the product team in the form of an FRD (Functional Requirements Document), we attempted to plan the entire feature at once.
This caused very long planning sessions, which brought other problems such as:
- lacking task details
- the doubts were few, but in the development, there were many because some details were not discussed in the planning
- the delivery flow was low
A change of strategy became imperative 💪🏽
To solve these problems, we started to adopt the following strategies:
- Refinement: Our planning meetings will last an hour. During these meetings, we will determine the next set of tasks to be planned and analyse them thoroughly, asking as many questions as possible to clarify any doubts.
After a few sprints, we noticed that our planning meetings could have been more productive. We identified the tasks planned during the previous sprint to optimise our time.
- We limited planning to one hour, scheduled on a rolling basis and have no fixed recurrence in the calendar. This means we plan as much as possible during one hour, in as much detail as possible. We schedule a new plan only when the planned work is nearing completion.
- Requirements analysis: Our technical documentation was only created at the end of development. This documentation, although essential, needed to be supplemented. So we started to develop documentation under analysis to support the FRD discussions instead of being made only at the end of each Merge Request (or Pull Request 😜)
- Added acceptance criteria: All team members help write them to help QA in testing and developers during development.
Our main objective is to divide the tasks as much as possible during planning.
By maximising our focus during the planning meetings, we achieved a degree of detail and division of labour that allowed us to increase our delivery flow considerably.
| Refinement | Planning |
| Analysis of the following tasks to be developed | Writing the acceptance criteria together |
| The division into sub-user stories | Separation into sub-user stories for all those that are scored with 13 or more complexity points |
Estimation in Days vs Story Points
One reason we tried to plan the features all at once was partly how the estimates were given to the product team, as we needed to see how long the development would take.
We used the story points from the planning for these estimates. After developing some features, we noticed the delivery dates were never met.
With feedback from our Engineering manager and after reading Story Points Revisited, we decided to change our estimation method because the story points should represent the effort needed to complete the task, not the development time.
Story points are used only to divide tasks and identify doubts that may arise during planning.
Estimates are done macro-style over several days through the superficial analysis of the user stories (US) provided by the product team. The follow-up is done sprint by sprint, and the estimate is readjusted if necessary.
Development 🖥️
Infraspeak‘s teams are multidisciplinary and divided into three functional areas:
- Frontend (FE) — responsible for interface developments
- Backend (BE) — responsible for API development
- Quality Engineer (QE) — responsible for testing the developments produced.
Multiple FE and/or BE tasks constitute a user story, which QE tests.
As a team, on a day-to-day basis, we identified some problems:
- A lack of collaboration between team members caused an increase in development time.
- Functional areas dependencies: we had to wait for the development or action of other team members or other teams.
- Some user stories were sent to QE and couldn’t be tested because they depended on user stories that hadn’t been developed yet.
After some further discussion, we found three possible improvements to maximise our collaboration on the existing process:
- Tested BE tasks before testing the US as a whole. To progress with both BE and FE tasks simultaneously within the US, we try to work on them in parallel. However, we sometimes need to give BE tasks a head start due to their complexity and because FE needs data from them. When the BE work is “finished”, and while the FE is still in development, we send some of these tasks to the QE to test the API endpoints using the documentation created during development.
- We set a time limit for opening and closing the US. We try to have the US open for a maximum of 3 days.
- Anticipated some features that could create dependencies from another team and created a Jira issue for them.
- We have created a soft rule of having no more than two US open to ensure that we close the job before starting a new task. We learned that if we don’t do this small control, we will quickly find ourselves with an uncontrolled WIP (Work In Progress). This way, the team ends up getting together more often to help each other because a Developer’s job is not always to make code but also to review code, for example, produced by colleagues, to help close open tasks if there is some doubt or blockage, through pair programming / pair review.
- The team’s developers do a quick test in the test environment where the code was integrated before sending the US to the QE. This way, we can help the QE in the testing process and ensure the US can be tested.
The idea is to run more in-depth tests than to try to catch the most obvious scenarios quickly and get them fixed. This became our standard process.
This process has also helped us between team members because, in many cases, there was frustration on the QE side.
QE and Developers can be friends 💛
Social 🎢
After stabilising the team, working on our micro-culture to build general well-being among team members became essential, as this is a big step towards success.
So, we decided to adopt some strategies:
- Daily use of Discord: this way, the team is in constant contact when necessary. We also value the use of mute and deafen a lot
- Team
bullying(building): We find it very important to maintain interactions between team members, whether remote or not. So, we decided to make team buildings frequently:- Remote: our Asgard Gamers. Every Friday, at the end of the day, the team gathers to play an online game.
- Non-remote: on retro days, the entire team goes to the office.
We also make some less frequent team buildings, like barbecues, karts, cinemas, dinners, awards, etc.
Face-to-face events are significant to improve the interactions between team members 🤼
Learnings
Infraspeak highly values our learning and development, so we also adopted some strategies to maximise it:
Mob Review (MR)
One way of performing a code review while promoting team interaction is the practice of Mob Review. Reviewing our colleagues’ and other teams’ work is part of a development team’s job. Mob reviewing is a software development approach in which the whole squad reviews the same thing simultaneously, in the same space, and “on the same computer.” Since we mainly work remotely, we opted to do this via video call. We usually conduct multi-functional mob reviews involving Backend and Frontend Developers when we have many open Merge Requests or when someone on the team requests them. This way, we can transmit knowledge to other people from involved function areas that don’t work together daily, providing more excellent knowledge inside the team and building trust for discussions in different contexts, like our planning. This practice became much more frequent in our team and spread to other teams at the company.
Study group
As the team interaction grew, we discovered that some of us had exciting knowledge that could be useful for the entire team. So we created the Study Groups, which now happen once a week, where we approach specific topics to be presented, explained and discussed between all team members, contributing to our interaction growth and knowledge sharing. Some information gathered through sharing between function areas, like the Backend and Frontend was integrated into our code base, making it more efficient and compliant with best practices.
Pair programming
Many people working on software development had already heard of pair programming, but only a handful had adopted it. Many didn’t realise its importance, and so were reluctant to allocate “unnecessary” resources to the same task, but in our team, we saw it made sense to adopt this methodology. We use pair programming daily to solve complex tasks or in situations where a developer holds much more knowledge than the others in a particular piece of code, in which it’s essential to share such knowledge.
Conclusion
We became a synchronous team by implementing initiatives that drastically improved our collaboration. Our team members are much more united now, and our relationships flow better.
As a running joke, our current motto is: We have no problems, only solutions.
Results
As you can see in the chart below, the improvements are significant.
The green dots represent the multiple issues the team solves during our sprints, and the blue line represents the rolling average of development time. Take a look:
As we can see in the left portion of the chart, there was a significant disparity in development time between issues, which caused unpredictability in our delivery time and inaccurate estimates.
As we implemented the solutions we discussed in this blog post, our development became faster and more efficient, which helped us achieve a much better predictability of delivery time.
Our current team KPIs speak for themselves:
- Our MR review time is under our defined goal (< 2 days)
- Our number of bugs in production is under our defined goal (< 1 bug)
- Our lead time is outstanding (<5 days)
It’s also important to state that no perfect and universal recipes work for every team. It’s essential not to be afraid of trying and failing, sprint after sprint because a team’s identity can only be found through trial and error.
And this is how the Asgard team did it! 😉
