I wrote some time ago an article about how to organize product development teams and about some changes we made ​​in the software development teams at Locaweb.

Since last year we have been focusing in productivity, i.e., how our software development teams at Locaweb could produce more without hiring more people and without dropping the quality of the software being delivered.

The chart below shows our numbers. We recorded the number of deliveries per week and, as you can see in the chart, in few weeks we were able to more than quadrupled the number of deliveries per week.

This increase in productivity occurred when the team grew only 10% in number of people, i.e., we cannot credit the increased productivity to the increase of people in our teams.

When there is an increase like the one presented above, besides the natural questioning of whether the increase in productivity is due to the increase of people, another common questioning is about whether there was a decline in the quality of deliveries. One of the quality measurements that we make is the number of rollbacks. As you can see below, despite the productivity increase, the number of rollbacks actually decreased by 40%!

How we did it?

There is no silver bullet, there were several actions we took and we are sure that there are still more actions that can be taken to increase productivity even further. Here is a list of what we did.

• Measure: first of all, to improve anything you need to measure it in order to know if it is getting better! We made an estimated calculation of the number of deliveries per week 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 to communicate the entire company about the number of deliveries of each week. Each product manager sends me on Friday the deliveries of the week of her team. I then compile the data, write down the number of deliveries of the week and generate the chart above. From the moment we began to measure how we were in terms of number of deliveries per week and started to experiment with the process, we began to see results as seen in the chart above. In addition, the teams started using a single measurement tool, Jira , which gave them a better view of each team progress and allowed comparisons between teams with experience exchange, something along the lines of “look that interesting change in your chart, how did you manage to increase this indicator?”.
• Kanban vs Sprint: Another area where we made changes was moving from Kanban to 2 weeks sprints. All teams ran with Kanban. The issue was that in Kanban, when an item has an impediment, it cannot be put aside in order for the team to work on something else. The team was locked. When an item is at the “doing” column, it cannot be moved back to the to “to be done” column so the team could get another item to do. Once in “doing” the task can only go to “done” can not go back to “to be done” column because you lose control of the team productivity. With time framed sprints, the team organizes the next two weeks of work, selecting more than one item to be worked. Thus, if an item has an impediment, the team can begin to work on another item and, therefore, can deliver more in the same time interval.
• Discovery and delivery: what the UX designer and product manager do can be called discovery, that is, find out what needs to be done. On the other hand what engineering does can be called delivery, i.e., do and deliver what has to be done. This separation of roles seems obvious, but not making it explicit in teams can disrupt the process of software development. Why? Due to a few reasons. The first is that if the discovery is not seen explicitly, it is not clear what is done at this stage, nor what motivates certain decisions about what should be implemented in software. It is difficult to do something without knowing why it needs to be done. 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. Often times we saw something being implemented by engineers. Then UX and product manager, after seeing their specs implemented, want to change something in the middle of development. With the clear separation between discovery and delivery, we define that once going to delivery, it cannot be changed. If we need to change, we need to go through a new discovery and only then go to delivery again. 
• Size of deliveries: we have been discussing for a few months ago now about the size of deliveries. In some cases our deliveries were very large, several weeks to a few months of work. As already widely discussed in Agile, frequent delivery of working software is one of the principles of agility, enhanced by the technique of continuous delivery. Just search Google to find numerous examples of world-class companies that make multiple deploys a day, with some making hundreds of deploys a day! :-O To do this, you need to deploy small, very small, chunks of software. We need to slice every big delivery into smaller stories. This is the product manager’s job, in conjunction with the UX designer. I’ve been asked if this is not cheating, after all, instead of delivering a great story will be delivering the same thing only sliced into short stories. It seems to be the same, but instead of delivering something big after weeks or even months, we end up delivering value every day, so our users can now enjoy the benefits immediately, rather than waiting weeks or months. Moreover, by deploying software in production every day, we can already learn from the feedback and adjust future deliveries. And there’s an added benefit, the fact of delivering software daily makes this process simpler by the simple fact that it is done everyday not every week or even worse, every month. So delivering a big story over a period of weeks or months is not the same thing as breaking the story into small pieces and delivering a little bit every day. There are clear productivity gains in deploying and delivering small pieces frequently.

In addition to these points above, we are beginning to experience some additional aspects that will certainly have an impact on productivity:

• First solution vs simplest solution: it is human nature to want to solve problems. Once a problem arises, the first reaction is to think on a solution and get out implementing this solution to solve the problem. The issue here is that the first solution is not always the best solution, both from the customer’s point of view and from the point of view of who implements the solution. For this reason we prefer not to start immediately solving each new problem that comes out. We seek check for other possible solutions, we analyze all the solutions that we were able to gather and only then pick a solution to implement. Spend more time thinking about other possible solutions, having always clear what needs to be solved and why we need to address this issue. Knowing why helps you find simpler solutions. A simple solution (1 week implementation) that solves 70% to 80% of the problem is better than a complicated one (1 month implementation) that solves 100% and in most cases, 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 email services may stop working due to external factors such as the domain associated with the hosting and email was not renewed. Registro.br, the Brazilian registrar for .br domains recently released a new way for Locaweb to charge the customer domain on behalf of Registro.br. At first the idea seems good, since Locaweb billing the domain looks like the easiest way to guarantee that the customer knows that it has to pay for the domain registration to maintain the hosting and email services operational. However, when analyzing a bit better, we saw that this solution can generate problems. The customer will be billied twice for the same thing, domain registration, because the Registro.br would continue billing the domain. What happens if he pays both bills? And if he pays only Registro.br? And if he pays only Locaweb? In addition, implement a new type of billing where we will bill for a third party service is something new to the Locaweb team. New processes have to be carefully designed. So we started to wonder if there would be simpler ways to solve the problem of helping our customer not to forget that he has to pay for her domain registration at Registro.br. Since it would be possible to charge for Registro.br  services, it was possible to access the information that the domain is about to expire. So we thought about the following simpler solution: we will implement a communication sequence with this customer advising him of the importance of paying Registro.br to ensure that the email and hosting services continue to operate normally. This is a way simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send this link information to the customer and the chances of solving the problem increase even further. And a communication sequence is much simpler to implement than a duplicate billing process.
• Choose the most appropriate tool: here the subject are tools for implementing the solution, i.e., programming languages, frameworks and databases. Each tool has its own characteristics and these characteristics make them more appropriate to solve certain kinds of problems. Choosing the right tool for each problem will impact productivity. This is an issue that we are beginning to study now. Today we use Rails for almost everything, but it has some problems for which the solution developed and deployed using another framework or language or database can be simpler and faster. Using a single programming language for all problems is the same as using a single tool for all repairs that have to be made. Does the hammer is the best tool to tighten a bolt? Does Rails is the best tool to manage queues?

We are confident that with the above two points that we are starting to experiment now, we can increase productivity by 10x or even more! \O/

And certainly there are certainly other points that we haven’t even considered yet and that when we start to discuss and treat, may impact productivity even further.

Conclusion

As I said above there is no silver bullet, but there was one specific action taken that had crucial impact here: making productivity an important theme in our conversations. Everybody started to talk about productivity, what impacts productivity and how to address these points. This movement did start several changes and experiments that helped us to greatly increase our productivity. If you also want to increase the productivity of your software development team, put this issue as a central theme of their conversations and make lots of experiments. You’ll see how there is room to greatly improve the productivity of your software development teams.

Product Management: how to increase the success chances of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

• Definitions and requirements
• Life cycle of a software product
• Relationship with other areas
• Product portfolio management
• Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!