Transfeera - which is a fintech company based out of Brazil, automating the B2B payments - uses Typo to identify and fix blockers in the PR flow and analyses the spends & effort into their R&D process.

Rafael, who is the CTO of Transfeera, started noticing bottlenecks that were slowing his team down. He wanted to know the cause of these issues and what the team is working on.

Problem Statement

In the midst of swift expansion, Transfeera came across several novel teams and team members. Rafael aimed to swiftly identify the sources of problems and their underlying causes. The longer it took to fix the issues, the more it would affect the team's productivity.

Typo’s unique solution

Rafael used Typo to see that the time it took for reviews to be done had gone up to almost 2 days, when it's usually less than a day. This review time is one of 4 steps in a PR cycle that shows how well the software teams are doing, according to DORA's research.

When Rafael checked his team's data in Typo, he saw that 2 teams took longer for reviews than the rest.

When he looked at the PRs causing concern, he found 33 PRs that took more than 8 days for reviews on average. Rafael saw on Typo that some of the PRs were much bigger in size than others, and that's what was slowing down the review process. With an increase in PR size, the number of useful comments decreases. Due to delay in the review process, it is recommended to have smaller PRs for better quality & faster delivery.

He also saw that a few teams were spending unusually long time coding, which was also making the whole cycle take longer.

Actions taken

Rafael knew that the next really important thing was to talk to the team and work together to figure out what to do next. When he talked about the big PRs and long review times, the team talked and found out they had different ideas about how PRs should be written. To make everyone agree, the team decided on two important changes:

(1) They decided to make a rule to write shorter PRs. (2) They also made rules in their guide for code reviews. They said how notifications should work, how fast people need to reply, and how to give feedback, all to make the review times faster.

Outcome

After implementing the standards set above, the teams started to respond more quickly to review requests, thus reducing the Review time by 70%.

It directly impacted the time to merge across teams at an average of 30%.

Going forward

Typo gave Rafael the answer he wanted - what's making the review times for PRs go up? Is anything causing problems with the type of work or tasks assigned to the team?

To make his team work better, Rafael could look even deeper to check if the Time to Merge changes based on the kind of tasks the team is doing. This checking shows how much of the team's effort goes into fixing problems and dealing with technical stuff, compared to making new things.

These kinds of findings help teams know how different kinds of work affect how they work. This helps them choose what's best to do with their time and what resources to use.