How can we deliver faster? How can we deliver more with the same team? Why do we have the impression that the team is slow? When the team was smaller, it seemed that it could deliver more. These are very common questions and statements that I hear about product development teams. Every company that has a digital product development team would like this team to be faster. In this chapter, I will show you the two essential tools to achieve faster and more productive teams.
There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and have it measured.
In my last year at Locaweb, we were focusing a lot on productivity, that is, on how Locaweb’s product and software development teams could produce more, without having to add more people to the teams, and without dropping quality levels.
The following graph shows our numbers. We count quantities of deliveries per week and, as you can see, in a few weeks we were able to more than quadruple the quantity of deliveries per week.
This increase in productivity happened when the team grew only 10% in number of people, so it is not possible to credit this increase in productivity to the increase in number of people in the teams.
When there is such an increase, in addition to the natural question about whether the increase in productivity is due to the increase in the number of people in the teams, another question that exists is whether there was a drop in the quality of deliveries. One of the quality measurements we had was the number of rollbacks. As you can see below, even with the increase in productivity, the number of rollbacks was reduced by 40%!
At Locaweb we made estimated calculations of deliveries per week from September 2015 to February 2016. The calculation was very simple, total deployments made in the period divided by the number of weeks. We then started to communicate the entire company about the week’s deliveries.
After I arrived at Conta Azul, we decided to implement the same type of control of weekly deliveries and ended up also achieving a good increase in productivity.
Both at Locaweb and Conta Azul, each product manager sent me the deliveries of the week on Friday, I compiled the data and wrote down the quantity for each week, generating these graphs. From the moment we started measuring, it became clearer the level we were at, and the actions we started to take in order to increase productivity began to show results on the graph. In addition, the teams started to use a single measurement tool, JIRA, which gave them a better view of each team’s progress and allowed comparisons with the exchange of experience, that is, something like “look how interesting your graph is, how did you manage to increase this indicator? ”.
At Gympass, as we scaled the team very quickly, we decided to control the number of deliveries per person per week. We considered people who joined 2 months before since people need 1 to 2 months after they joined Gympass to become productive. In one quarter, we managed to increase our productivity per person by 16%. The number of deliveries was extracted directly from JIRA.
At Gympass, we also measure the number of deploys, both in our core, aka monolith, and in microservices. We also achieved a considerable increase in one year.
At Lopes, as soon as a deploy was done, an email was sent with a list of deployed items. One of the first things I did when I joined the company was to compile these reports in a spreadsheet to build the chart below. Hence it was easy to notice that the deploys did not happen every day. They happened once per week on average. As soon as we noticed this, we defined OKRs to increase the frequency of deploys, which has been yielding results. The OKRs we defined were:
- Objective: Increase the cadence of deploys in production;
- KR: Increase the number of deploys per week to at least 3 (the more the better);
- KR: Reduce the maximum number of new features per deploy to a maximum of 10.
What impacts productivity
The productivity of a product development team is impacted by several factors. I once found a very interesting article written by Michael Dubakov, founder of the company Targetprocess where he shows a mind map with all the elements that can positively or negatively impact the productivity of a product development team. This article is no longer available, but thanks to the Wayback Machine website (http://web.archive.org), you can access it at:
The mind map is this one:
This diagram shows things and activities that affect the speed of development in some way. Green means that the activity increases speed. The more you have, the better. Yellow indicates that there is some maximum. For example, you can accumulate technical debt and increase speed, but if you accumulate too much, it will significantly delay you. Red shows things that slow development, the less you have, the better. The green arrow indicates an increasing effect. For example, focused work increases the speed of development. The red arrow indicates a decreasing effect. For example, better development skills decrease the complexity of the system (good engineers create less complex systems).
What I like about this image is that it shows how complex this theme is and how many things can positively or negatively impact the team’s speed. At Conta Azul, we followed this topic every quarter at the Product Council, a meeting where we talked about the quarterly planning of the product development team with the leadership. There was a slide where we listed all the topics that could impact the speed to discuss what we were doing about each of these topics.
Place the topic of productivity at the center of the discussion
There is no silver bullet, with each team I’ve worked on there were several actions we took and we were always sure that there are always more actions that could be taken to increase productivity even more.
The only silver bullet that exists is we made productivity into an important topic in our conversations. Everyone started talking about productivity and what we could do to improve it.
This movement made us initiate several changes and experiments that helped us to increase our productivity considerably. If you also want to increase the productivity of your product development team, place this topic at the center of your conversations and experiment a lot. You will see how there is room to greatly improve the productivity of your software development team.
Another important point: be sure to discuss the topic of productivity frequently. My recommendation is that you do it weekly. Creating a weekly cadence will give you the opportunity, each week, to experiment with something new and discuss the results with the team.
- There is no silver bullet to increase the productivity of a product development team. However, there are two essential tools to help achieve this goal.
- The first tool is measurement. There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and its measurement.
- The second tool is to bring the topic of productivity to the center of the discussion. Everyone on the product development team is responsible for the team’s productivity. Therefore, by bringing the topic to the center of the discussion, everyone will be able to collaborate to improve productivity.
In the next chapter we will see another metric that has a direct impact on productivity, quality.
Digital Product Management Books
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:
- Startup Guide: How startups and established companies can create profitable digital products
- Product Management: How to increase the chances of success of your digital product
- Leading Product Development: The art and science of managing product teams