There is no silver bullet, there were several actions that we took and we are sure that there are still more actions that can be taken to increase even more. Here is a list of what we did at Locaweb to increase the productivity of the product development team, practices that I later took to other companies.

Measure

First of all, to improve anything, you need to measure it to be able to know if that thing is improving! We made some estimated deliveries per week for the period from September 2015 to February 2016. The calculation was simple: total deploys made in the period divided by the number of weeks. We then started communicating with the entire company about the week’s deliveries.

At Locaweb and Conta Azul, each product manager sent me the week’s deliveries on Friday. I compiled the data and wrote down the weekly quantity, generating this graph. From the moment we started measuring, our level became clearer, and our actions 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 the progress of each team and allowed comparisons with the exchange of experience, that is, something along the lines of “look how interesting your chart, how did you manage to increase this indicator?”.

Kanban vs. sprint

Another point we changed was the change from Kanban to sprint. Before, all teams ran with Kanban. However, in Kanban, when an item has an impediment, it cannot be moved, and the team cannot do anything else, getting stuck. However, sometimes it happened that the team moved an item from “doing” to “to be done” because it was offside and picked up another item to do what shouldn’t be done. Once in “doing”, the task can only go to “done”, it cannot go back to “to be done” as productivity control is lost.

With sprint, the team organizes the next two weeks of work, putting several items to be worked on. That way, if any item has an impediment, the team can start working on another item and, with that, manage to deliver more in the same time frame.

It is important to emphasize that this is not a criticism of Kanban. This happens in 2015. I believe we didn’t have enough maturity and knowledge to get the best out of Kanban, so we chose to switch to Scrum.

Discovery and delivery

What the UX designer and the product manager do can be called discovery: finding out what needs to be done. What engineering does can be called delivery: doing and delivering what needs to be done. This separation of roles seems obvious, but not making it explicit in teams can disrupt the software development process.

Why? For a few reasons. The first is that if discovery is not explicitly seen, it is unclear what is done in this phase nor what motivates certain decisions about what should be implemented in the software. It’s hard to do something without knowing why you’re doing it. The second reason is that when this separation is not explicit, items can go back and forth from delivery to discovery, and vice versa, without discretion.

It was not uncommon to see something being implemented by the engineers in the teams. And when the UX people and the product manager saw their specifications implemented, they wanted to change something in the middle of development. With the clear separation between discovery and delivery, we defined that you don’t move anymore once you go to delivery. If you want to move again, you must go through a new discovery and only then go to delivery.

Delivery size

Our deliveries were quite large in some cases, with work lasting several weeks or even a few months. As has been widely discussed in agile methodologies, the frequent delivery of working software is one of the principles of agility, reinforced by the technique of continuous delivery. Just Google it to find countless examples of top-tier companies deploying multiple times daily, with some deploying hundreds of times daily! :-O

To do this, the deploys must be of small deliveries. You have to break every big story into smaller stories. This is the product manager’s work in conjunction with the UX designer. I’ve been asked if this isn’t cheating; after all, instead of delivering a big story, we’ll deliver the same thing but divided into small stories. It seems to be the same thing, but instead of delivering something big after weeks or even months, we deliver value every day, so our users can enjoy the benefits immediately instead of waiting weeks or months.

Also, by putting it into production daily, we can learn from the feedback and adjust future deliveries. And there is an additional benefit: putting some code into production every day makes this process of putting code into production something simpler exactly because it is done daily.

So delivering a big story over a period of weeks or months is not the same thing as breaking that story into small pieces and delivering a little piece every day. There are clear productivity gains in delivering small chunks frequently.

Also, making it easier for engineers to deploy (and roll back) code will help get code into production faster.

When I left Locaweb, we were starting to experiment with a few more points that had good potential to impact productivity:

First solution vs. simplest solution

It is human nature to want to solve problems. As soon as a problem appears, the first reaction is to think of a solution and implement it to solve the problem. However, the first solution is not always the best, both from the customer’s point of view as well  from the point of view of the person implementing the solution.

For this reason, we have preferred not to immediately start solving every new problem that appears. We first try to check if there are more possible solutions, we analyze all the solutions and only then do we choose a solution to start the solution. Invest more time thinking about other possible solutions, always being clear about the issue to be resolved and why we need to resolve this issue. Knowing why helps you find simple solutions. A simple solution (1 week of implementation) that solves 70% to 80% of the problem is better than a complicated one (1 month of implementation) that solves 100%. Most of the time, solving 70% to 80% of the problem is more than enough. Sometimes the simplest solution is to do nothing!

For example, at Locaweb, the hosting and e-mail service may stop working for reasons external to the service. The domain to which the hosting and e-mail are linked, which is paid annually to Registro.br, may not have been renewed and, when it is not renewed, the services associated with that domain stop working, even if everything is operating perfectly at Locaweb. Recently, Registro.br made available a way for Locaweb to charge the customer’s domain on behalf of Registro.br. At first, the idea seems good, because when we charge, we guarantee that the customer knows that he has to pay for that domain to keep the services in the air. But, looking a little better, we saw that this solution can generate more problems.

The customer will be billed twice for the same thing, the domain registration, as Registro.br would continue to charge him. What happens if he pays both charges? And if he only pays Registro.br? And if he only pays for Locaweb? In addition, implementing a new type of billing, in which we would charge for the third-party service, would be something new for the team and for Locaweb. New processes would have to be designed. So we started to wonder if there weren’t simpler ways to solve the problem of helping our client not forget that he must pay for his domain registration at Registro.br.

As in order to charge for Registro.br it is necessary to access the information that the domain is about to expire, we thought of the following solution: we are going to implement a communication rule with this client, advising him of the importance of paying Registro.br, to guarantee that the service continues to function; it’s a much simpler solution than duplicating the billing process. If Registro.br provides a direct link to charge for the domain, we can send this link in the communication. Thus, the chances of solving the problem increase even more, and a communication rule is much simpler to implement than a duplicate charge.

Choosing the most appropriate tool

Here, the theme is tools for implementing the solution: programming language, frameworks, and databases. Each tool has its characteristics and, depending on them, makes them more appropriate to solve certain types of problems. Choosing the right tool for each problem will impact productivity. This is a topic we are starting to study now.

Today we use Rails for almost everything, but there are some problems with implementing a solution using another framework or language that may be simpler and faster to resolve. Using a single programming language for all your problems is like using a single tool for all the fixes needed. Is a hammer the best tool for tightening a screw? Is Rails the best tool to manage queues?

We are confident that with these two points, which we are starting to touch on now, we can increase productivity by 10x or more! And certainly, there are other points that we haven’t even noticed yet and that, when we realize and treat them, can have an even greater impact.

What impacts productivity

The productivity of a product development team is impacted by several factors. I once found a very interesting article written by the Apptio development team where they show a mind map with all the elements that can positively or negatively impact the productivity of a product development team:

Apptio Mindmap on what impacts productivity

This diagram shows things and activities that affect development speed in some way. Green means an activity increases speed. The more you have, the better. Yellow indicates that some maximum exists. For example, you can accumulate technical debt and increase velocity, but it will significantly slow you down if you accumulate too much. Red shows things that slow down 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 decreasing effect. For example, better development skills decrease system complexity (good engineers create less complex systems).

What I like about this image is that it shows how complex this topic is and how many things can positively or negatively impact the team’s speed. At Conta Azul, we followed up on this topic every quarter at the Product Council, a meeting where we discussed the quarterly planning of the product development team with leadership. There was a slide where we listed all the topics that could impact speed so that we could discuss what we were doing about each of these topics.

Topics that impacted Conta Azul’s product development team