Measuring and managing quality

In 2015, we decided to extinguish the Quality Assurance (QA) function of our Locaweb product development team. We had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the QA role, some of the QAs became devs, while others took on the role of system administrators. The reasons that led us to extinguish Locaweb’s QA function were:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the functionality is ready, now it is in the QA phase”, which denotes a cascading product development culture. This culture can considerably increase development time and negatively affect the quality of the software.
  • When there is a QA function separate from the software development function, it is also common to hear phrases like “why didn’t QA detect this bug?”, Which denotes a culture of finding the culprits. This culture can be very detrimental to the engagement and motivation of the team and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of a person or team, it should be the concern of everyone working on creating the software.
  • Quality is a non-functional requirement, that is, it specifies a criterion to evaluate the functioning of a digital product, while a functional requirement specifies a behavior of the software. Performance, scalability, operability, monitorability are some examples of non-functional software requirements that are just as important as quality. Even so, there are no defined functions to guarantee performance, guarantee scalability, guarantee operability and guarantee monitorability. Why is quality the only non-functional requirement that has a specific dedicated function to guarantee it?
  • Quality control focuses on ensuring the quality of the software development process. If a separate function is needed to guarantee this quality, why is there no need for a separate function to guarantee the quality of the product management process, the design process, the product marketing process, the sales process, the finance processof a company?
  • There was a concern that, if the engineer himself now had to test, deliveries would take longer to be ready. This concern existed because the engineers considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, the engineer’s definition of ready is incorrect, as he has just passed the story on to the next phase, the test. From the user’s point of view, the story is only ready when the user can use the new feature. Therefore, the time that the delivery remains in quality control is still development time, even though it is no longer in the hands of the engineer. And that time gets even longer when the story goes through quality control, but it is rejected and needs to go back to engineering.

When I joined the Conta Azul, they had also just extinguished the role of QA, and the ex-QAs became business analysts, mainly helping product managers.

I saw other companies also discussing the need for QAs, and in some cases, a heated debate emerges around this topic. However, having or not having QAs should not be the focus of the discussion. Having or not having this function is the solution to a problem, usually referred to as “how can we improve the quality of our product?”, And that problem should be the center of the discussion.

How can we improve the quality of our product?

A simple Google search for software quality will yield tons of definitions typically related to meeting functional and non-functional requirements. When the software does not meet a functional or non-functional requirement, it has a defect, a bug. Therefore, to improve the quality of a software product, we need to work on two things:

  • reducing existing bugs;
  • not generating new bugs.

A good way to track this is to have a weekly measurement of your bug inventory and new bug creation per week and discuss this every week with the team. We did that at Gympass. We define at the beginning of each quarter what the target is for the bug inventory and the average new bugs per week.

Total amount of bugs at Gympass

The image shows the evolution of our bug inventory during the 2nd quarter of 2019. We started the quarter with 215 bugs in our stock and we aimed for a target of less than 166 at the end of the quarter, a reduction of almost 23%. We ended the quarter with an inventory of 136 bugs, a reduction of 36%. We did this by focusing not only on resolving bugs in our inventory, but also on controlling the number of new bugs per week.

Number of new bugs detected per week at Gympass

In the first quarter of 2019, we had an average of 26.2 bugs created per week. During the second quarter, we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. This is a 33% reduction in the number of new bugs per week.

That looks like a pretty good improvement, right? But there is a lot of room for improvement there. Let me explain the math of bug management:

If we were able to reduce our bug stock from 215 to 136, it means that we have resolved at least 79 bugs. However, we created 226 new bugs (17.4 new bugs per week x 13 weeks) during the quarter. So we solved 79 + 226 = 305 bugs during the quarter, a lot of bug fixing work. If we had generated 90 new bugs during the quarter, an average of 6.9 new bugs per week, instead of the 226 new bugs, we could have zeroed out on the bug inventory.

An additional aspect of the bug resolution to be measured is the SLA (Service Level Agreement) resolution, that is, how many days the team took to resolve a bug from the day the bug was first identified. For this, we classify the bugs by their severity, which is the impact it has on users and the business. The most serious bugs are those that we need to resolve on the same day; high severity errors, in 7 days and average severity, in 14 days. The following chart shows how we were at Gympass in the fourth quarter of 2019.

Gympass bug resolution SLA

This is not the ideal way of viewing this info because it shows only an image of the moment, and not an evolution. To understand the evolution of any metric, you need to see how it did at different points in time.

As soon as I joined Lopes, I started bringing this topic up for discussion with the teams. One of the things we noticed is that 50% of deployed items were bug fixes. I was informed that “these bugs were caught before going into production, which is a good thing”. In fact, it is a good thing that these bugs did not reach the production environment and appeared to our users. However, they reached pre-production and needed to be corrected. Wouldn’t it be better if these errors didn’t even exist, not even in pre-production?

The OKRs we defined to help us with the quality theme were 3 additional KRs in order to Increase the cadence of deploys in production that I mentioned in the previous chapter:

  • KR: Reduce the number of new bugs to 5% in pre-production.
  • KR: Reduce the number of total bugs to 10% in pre-production.
  • KR: Keep the number of total bugs below 5% in production.

And we add the following OKR:

  • Objective: To improve the quality of the deliveries to the squads.
  • KR: Review 100% of new stories to find poorly defined and / or ambiguous requirements.
  • KR: Perform a 25% review of the Pull Requests of the squads.
  • KR: Measure the Pull Requests volume of the squads.

Another example of bug tracking

At Conta Azul, we doubled the product development team in a period of 8 months between November 2017 and July 2018. This growth was aimed at increasing the team’s productive capacity.

Number of deliveries and people per week at Conta Azul

In addition, we divided the quantity of deliveries by the total number of people on the team to assess whether we were managing to increase our productivity individually.

Number of deliveries per person at Conta Azul

However, with the increase of people on the team, it ended up increasing the amount of bugs. So much so that the team that had already had 40% of its deliveries as a bug fix ended up having to increase this proportion to 60%. That is, despite having increased individual and total productivity, this increase in productivity was not being felt by the user, as it ended up being used for bug correction.

Percentage of bug fixes at Conta Azul

To control this problem, we increased our focus on fixing these bugs within the SLAs, which were:

  • 85% of tickets resolved within 7 days
  • 98% of tickets resolved within 30 days
7 day bug fix SLA at Conta Azul
30 day bug fix SLA at Conta Azul

See that the quality has worsened and the customer suffered from it. But, after some time, we managed to return to the defined SLA levels. We looked at this metric weekly and, whenever we discussed this metric, we agreed that the best way to comply with the SLA was not to create bugs!

Quality is not just bug control

In addition to bug control, there are several other aspects that impact the quality of the digital product that we deliver to users. Performance, scalability, operability, monitorability are some examples of non-functional requirements.

When I joined Gympass, on my second Monday the system went down for users around 7 pm. I started asking people on the team what was going on and the answer was that Mondays are peak days in terms of gym visits and that the system could not handle the volume at all. As there was no monitoring, we were not alerted that the volume was higher than usual and we were unable to prepare properly. Two months later, when Rodrigo Rodrigues joined Gympass as CTO, he dubbed the event “Black Mondays”. To address the problem, we started to monitor and implement an infrastructure that could handle Monday peaks. And we set OKRs for uptime, successful HTTP requests and backend response time.

Uptime – Gympass
Successful HTTP requests – Gympass
Backend response times – Gympass

Why is quality so important?

Any user prefers to use a good quality product that behaves as expected. This is a sine qua non condition to provide a good user experience.

In addition to the user experience, there is another important aspect to consider when we talk about quality and bugs. Whenever someone needs to work on resolving a bug that was found in a digital product, that person needs to stop working on whatever they are currently working on in order to resolve the bug. This is an interruption in the workflow. If that person were able to deliver the software without that bug, they could continue to work on new things without interruption, which would make them more productive.

The relationship between productivity and quality

I had the opportunity to participate in an MIT course on how to create high-speed organizations. The course was taught by Professor Steven J. Spear, author of the book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. This is one of those very dense courses, full of content, but which can be summarized in one paragraph:

High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

A high-speed organization works by following the 4 steps ahead:

  • Be prepared to capture knowledge and encounter problems in your operation.
  • Understand and solve these problems to build new knowledge.
  • Share the new knowledge with the entire organization.
  • Lead to develop skills 1, 2 and 3.

The classic example is Toyota, with lean manufacturing and the concept of stopping production whenever there are failures, correcting them and using them as a learning opportunity so that they no longer happen. This ability to learn from failure is what gives Toyota the ability to stay ahead of its competitors for so long.

Another good example is Alcoa, which had a work incident rate of 2% per year, which was considered normal. Alcoa has more than 40,000 employees, so 2% of work incidents per year means that 800 employees per year have some type of work incident. This is a very impressive and worrying number.

To combat this problem, they implemented a zero error tolerance policy. Before implementing this policy, mistakes were seen as part of the job. Employees are now encouraged to report operational errors within 24 hours, propose solutions within 48 hours and report the solution found to their colleagues to ensure that knowledge spreads throughout the organization.

This caused the risk of incidents to drop from 2% to 0.07% per year! This reduction in the incident rate meant that fewer than 30 employees per year had any work incident problems after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to that of Toyota.

Fail fast vs. learn fast

An important factor in the Toyota and Alcoa examples is that recognizing and learning from failures must be part of the company’s culture. This is somewhat more common in the culture of technology companies, but not so common in traditional companies. During the MIT course I shared a table with a Brazilian executive from Grupo Globo, the major TV company in Brazil, a Spanish executive from AMC Networks International (Walking Dead, Breaking Bad and Mad Men), a German project manager living in Azerbaijan who works for Swire Pacific Offshore (oil and gas industry) and an MIT postdoctoral student in solar energy from Saudi Arabia.

All of my table mates were from more traditional industries. I was the only one at an internet company. The executives at Globo and AMC were there because they saw Netflix with its streaming video on demand and YouTube with its huge catalog of user-generated videos as major threats, stealing their audience very quickly and they wanted to understand how they could defend themselves.

Although the theme is somewhat obvious for internet companies, especially with the culture of technology startups that value fail fast. That’s what makes Netflix and YouTube a threat to traditional media companies like Grupo Globo and AMC Networks. However, even though this is part of the culture of internet companies, sitting and discussing it with people from more traditional companies was a great opportunity to reflect on the relationship between failure, failure recognition, learning and high speed:

  • Recognizing the flaws and using the flaws as a learning opportunity must be well rooted in the organization’s culture. If people are not careful, as a company grows, it may lose the ability to accept failures as learning opportunities. It is very common for companies, as they grow, to become more and more averse to failure and to create a culture that ultimately encourages people to hide mistakes and failures.
  • Another important aspect of learning from failures is to make this process a company standard. There is no point in failing, acknowledging the error, stating that you will no longer make that mistake and, some time later, making it again. This learning process with failures must be part of the company’s culture. Whenever a fault is identified, learning should happen as quickly as possible to prevent it from happening again. If the same failure happens again, something is broken in the learning process with the failure.
  • Even in Internet companies, I realize that learning from failures is more common in the product development team, as retrospectives and continuous learning are part of the culture of agile software development. In other areas of the company, learning from failures is less common. This ability to systematize learning from failure must permeate the entire company.

Even though we hear a lot about the culture of internet companies to fail fast, talking about failing fast diverts our focus from what is really important, learning fast. We must put our energy into learning, not into failure itself. It is the learning process that makes people and companies evolve. And it is the ability of an organization to learn fast, especially with its failures, that will allow it to move at really high speeds.

Summing up

  • Questioning whether or not product development should have a dedicated QA team is not the right question.
  • The problem you are trying to solve is how to improve the quality of your product.
  • A good quality proxy metric is the bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team must have all its members following these metrics and taking action to improve them.
  • Managing bugs is not enough to manage the quality of the digital product. Performance, scalability, operability, monitorability are some examples of non-functional requirements that directly impact the quality of the digital product.
  • Quality is at the forefront to provide a good user experience. In addition, it is essential to increase the speed of your product development team. The less bugs a team has to fix, the more time it has to focus on new things.
  • High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

In the next chapter we’ll see a little more about metrics.

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

Measuring and managing productivity

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.

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 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.

Amount of deliveries per week at Locaweb in 2016

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%!

Number of rollbacks per week at Locaweb in 2016

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.

Amount of deliveries per week at Conta Azul in 2017

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.

Amount of deliveries per week at Gympass in 2019

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.

Number of deploys per week at Gympass in 2019

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.
Number of deploys per week at Lopes

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:

http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed-in-software-development/

The mind map is this one:

Number of deploys per week at Lopes

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.

Themes that impact the speed of the Conta Azul product development team

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.

Summing up

  • 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

QA or no QA? That’s NOT the right question…

Back in 2016, I wrote an article about the reasons that motivated us at Locaweb to extinguish the QA function in our product development team. At Locaweb we had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the role of QA, some of the QAs became devs while others have taken on the role of sysadmins. The reasons that motivated us to extinguish the QA function at Locaweb are:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the feature is ready, now it is in the QA phase”, which denotes a waterfall culture. This culture can considerably increase development time and negatively affect the quality of the software.
  • When there is a QA function separate from the software development function, it is also common to hear phrases like “why didn’t QA catch this bug?”, Which denotes a culture of finding the culprits. This culture can be very harmful to the team’s engagement and motivation and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of one person or one team, it should be the concern of everyone who is working on creating the software.
  • Quality is a non-functional requirement, that is, a requirement that specifies a criterion to assess the operation of a software product, which is different from the functional requirement, which specifies a behavior of the software. Performance, scalability, operability, monitorability are some examples of non-functional software requirements that are just as important as quality. Even so, there are no defined functions for performance assurance, scalability assurance, operability assurance, and monitorability assurance. Why is quality the only non-functional requirement that has a specific dedicated function to ensure it?
  • QA focuses on ensuring the quality of the software development process. If a separate role is needed to ensure this quality, why is there no need for a separate role to ensure the quality of the product management process, the UX design process, the product marketing process, the sales process, the financial process of a company?
  • There was a concern among devs that, if the dev herself will now have to test, deliveries will take longer to get ready. This concern existed because the devs considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, this dev’s readiness concept is incorrect, as she just passed the story on to the next phase, the testing. From the user’s perspective, the story is only ready when the user can use the new feature. So the time the delivery stays in QA is still dev time, even not being in the dev’s hand anymore. And this time gets even bigger when the story goes through QA but is rejected and has to go back to development.

When I joined Conta Azul, they had also just extinguished the QA role, and the former QAs became business analysts, mainly helping product managers.

I’ve seen other companies also discussing the need for QAs and in some cases a heated debate emerges around this topic. However, having or not having QAs should not be the center of the discussion. Having or not having this role is a solution to a problem, normally stated as “how can we improve the quality of our product?”, and this problem should be the center of the discussion.

How can we improve the quality of our product?

A simple Google search about software quality will yield tons of definitions normally around meeting functional and non-functional requirements. When software does not meet a functional or non-functional requirement, it has a defect, a bug. So, to improve the quality of a software product, we need to work on two things:

  • reducing its existing bugs;
  • not generating new bugs.

A good way to control this is having a weekly measurement of your bug inventory and new bugs per week and discuss this every week with the team. We did this at Gympass. We defined at the beginning of every quarter what’s the target for bug inventory and average new bugs per week.

Image for post

The image above shows the evolution of our bug inventory for Q2 of 2019. We started the quarter with 215 bugs in our inventory and we aimed at a target of less than 166 by the end of the quarter, a decrease of almost 23%. We were able to end the quarter with an inventory of 136 bugs, a 36% decrease. We did this by focusing not only on resolving bugs in our inventory, but also controlling the number of new bugs per week.

Image for post

In Q1 2019 we had an average of 26.2 bugs created per week. During Q2 we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. That’s a 33% decrease in the number of new bugs per week.

This looks like a very good improvement, right? But there’s plenty of room for improvement there. Let me explain the math of bug management:

If we were able to reduce our bug inventory from 215 to 136, this means we solved at least 79 bugs. However, we created 226 new bugs (17.4 new bugs per week x 13 weeks) during the quarter. So we solved 79 + 226 = 305 bugs during the quarter, that’s a lot of bug correction work. If we had generated 90 new bugs during the quarter, an average of 6.9 new bugs per week, instead of the 226 new bugs, we could have zeroed the bug inventory.

An additional aspect of the bug resolution to be measured is the resolution SLA, i.e., how many days the team took to solve a bug from the day the bug was first identified. To do this, we classified the bugs by its severity, which is the impact it causes to the users and to the business. Highest severity bugs are the ones that we need to solve in the same day. High severity bugs in 7 days and medium severity in 14 days. The chart below shows how we were at Gympass in Q4 2019.

Image for post

This is not the ideal visualization because it only shows a picture of the moment, and not an evolution. In order to understand the evolution of any metric, you need to see how it performed in different points in time.

Why quality is so important?

Any user prefers to use a product with good quality, i.e., that behaves as expected. This is front and center to provide a good user experience.

Besides the user experience, there’s also another important aspect to consider when we talk about quality and bugs.

Whenever someone needs to work on solving a bug that was found in a software product, this person needs to stop working on whatever she is currently working to be able to work on the bug. This is an interruption in the workflow. If this person were able to deliver the software without that bug, she could continue to work on new things without interruptions, which will make her more productive.

Summary

  • Questioning if a product development should or should not have a dedicated QA team is not the right question.
  • The underlying problem you are trying to solve is how to improve the quality of your product.
  • A good proxy metric for quality is bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team should have all of its members following these metrics and acting on how to improve them
  • Quality is front and center to provide a good user experience. But it is also key to increase the speed of your product development team. The fewer bugs a team has to fix, the more time it will have to focus on new things.

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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

We can’t stand it, we need to rewrite everything…

This article was originally published in Portuguese in June 2017.

I have heard this phrase several times throughout my career. Software developers know that invariably comes a moment when this kind of discussion comes up, which usually has phrases like: “it’s getting harder and harder to deal with the code”; “if it were to do it from scratch, it would be much faster”; “if we do not rewrite, it will become increasingly slow and dangerous to deal with the code”.

At Locaweb, we had an Email Marketing product for sending and managing email marketing campaigns, which used MongoDB as a database, a nonrelational database known for its ability to store large databases. However, probably because of our limited experience in software development using this type of database and in managing non-relational databases, as the database grew, the system became slower and slower.

So, it was necessary to rewrite the product to use PostgreSQL. We designed this rewrite to be transparent to customers. That is, the client would not be migrated from one database to another, thus avoiding going through a period of unavailability or possible data loss. The rewrite was a success. The entire rewrite process, including putting all existing clients (over 15,000 at the time) into the new database, allowing the MongoDB database to be shut down, took six months, a reasonable time for such an initiative.

However, during these six months, the team delivered nothing new to the customer. No new features. To lessen our customers’ frustration, we decided to hire a third party to build iOS and Android apps on top of existing product APIs. This enabled us to deliver new functionality to our customers while the product team focused on rewriting. If this option did not exist, we would have to find other ways to deliver user value that did not depend on the engineering team.

If you are a software developer, rest assured that if you have not experienced this situation in your career, you surely will. The problem with rewriting software is that by rewriting it, the team stops doing new things for its user, as I showed in the example of Locaweb’s Email Marketing product. From a business standpoint, when software does not evolve, customers see no evolution, may lose interest in using the product and will start looking for better options in the market. Therefore, I would like to make some considerations on the subject.

1) New and better technologies will always appear. In the past, systems were developed with everything in the same code base. Then it was the MVC concept (model, view, controller) separating software code into layers according to their function. More recently, the concept of microservices was created, breaking the application into small, loosely coupled applications, preferably done via APIs and facilitating maintenance. If with every new technology that comes along we are going to rewrite the software, we will certainly do nothing but rewrite software.

2) Software rewriting must have a clear business motivation, ie it must somehow meet the strategic goals of the software owner company as it fulfills a user’s need or solves a customer problem. If there is no clear business motivation, the recommendation is not to rewrite.

3) If rewriting is unavoidable (are you sure?), it is important to think about this rewrite initiative from a business perspective, that is, what is the impact of this rewriting on customers and the software owner. Understanding this is the responsibility of the product manager. Some questions to help you reflect with your team on this impact:

  • What will this rewrite look like?
  • While rewriting is going on, will new features be delivered?
  • How will the new system coexist with the old system?
  • When new features are implemented, will they be implemented on the new system and the old system, or only on the new system?
  • When can new clients be installed on the new system?
  • When will existing customers be migrated to the new system?
  • If there is a proposal to make a synchronizer, so that customer data exists simultaneously on the old system and the new system, what is the cost of this proposal compared to not making this synchronizer?
  • If the difference between the old system and the new system can be perceived by customers, how will this difference be communicated?

There you go, some considerations about software rewriting, a very important topic for any product manager.

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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

The relationship between product engineering and product management

How should the product manager relate to different areas of the company? Engineering, UX, product marketing, project management, operations, sales, legal, finance, customer service, human resources, and general management.

Recalling what I said in the article Main characteristics of a product manager, the most important feature every product manager needs to have is empathy, that is, the ability to put oneself in someone else’s shoes to understand their desires, motivations, needs, and problems. This feature should be used not only with the customer of the product but also with people from different areas of the company.

As said, the product manager must understand the impact his product has on legal work: have legal issues increased due to some new functionality in the product? And what about the sales, support, operations, finance, marketing staff, did the new product complicate their lives so much? And for the product team, the engineers and UX analysts who are part of the product core team, how do your product decisions impact their functions?

This is what we will see in this new series of articles!

Product engineering and product management

I will start by talking about the relationship between product engineering and product management.

Definition

Product engineering is responsible for developing the product and keeping it operating. With the business vision brought by the product manager, plus the solution design made by UX people – based on an understanding of the customer’s need or problem – product engineering “builds” the product.

To build it, they must not only do the programming but also define the technical architecture. That is, what infrastructure it will run on, which programming language is most appropriate, which database is most appropriate, how to ensure the non-functional requirements of this product (response speed, availability, scalability, etc.). It is also important to validate with the product manager whether the cost of this infrastructure fits his business model.

No alt text provided for this image

The fact that the product manager is responsible for defining the product to be made may give the impression that product engineering reports to product management. However, this view is incorrect, and if areas behave in this way, the chance of product failure increases because those who perceive themselves subordinate have less commitment to the outcome.

Product engineering, product management, and UX are one team, there is no subordination relationship between any of these groups. They should function as partners, each with their own expertise and responsibility, collaborating to produce the best product possible.

Innovation

In the previous diagram, product engineering brings the available technology. As I explained in the article Innovation: what is it?, to innovate is not simply to know the latest technology. You need to know not only this, but all available technologies, and how to use them. This is the role of product engineering. The opportunity and potential for producing an innovation lie in knowing the technologies available and knowing how to use them to solve a problem or meet a need of a group of people.

Practical Advice for Product Managers

To make life easier with the product engineering team, here are some practical tips:

  • Don’t get into the technical solution unless you have earned the right to meddle. A product manager should have some technical knowledge of your product, but this is not your area of expertise. The experts are in the product engineering team. Therefore, avoid presenting technical solutions to the engineering team unless this team is open to receive your suggestions, and even so, the more time you spend thinking and discussing about the technical aspects of your product, the less time you will have to learn about your companies’ objectives and your clients’ problems and needs.
  • Take engineers into conversations with customers and users. As part of your daily life as a product manager, you should always talk to your customers and users to understand how your product solves their problems or meets their needs, and how you can make your product look even better. Engineers love to go to these conversations very much. It is a very cool experience for them to see real people using software they have developed. They will be even more engaged in the mission of making a better product.
  • Always make data-driven decisions. Whether it’s data from your product access and usage, or data from your customer and user conversations, use data to make your decisions and present it to the team. This will give more consistency to the items you will place on your product roadmap.
  • Learn to take out the excess. Always look for the minimum product or the minimum functionality, ie try to implement as little as possible to achieve your business objective.
  • Be present. It is critical to be with the product engineering team or at least as accessible as possible to the team. During product development, doubts will inevitably arise and if you are not present, either the team stops, or they will implement as they think it should be, which may differ from what you had planned.
  • Provide the team feedback about the product. You, as a product manager, know how your product is doing, how many users it has, what these users are thinking of it, how this product is helping the company achieve the goals. Tell this periodically to the product engineering team. As a result, you will be giving context and purpose to the team.
  • Negotiate the rewriting and maintenance stories. The engineering team, if it is a good team – attuned to good software engineering practices evolution and always following what’s new in the software development industry – will always find better ways to implement each piece of the product. If it is dependent only on the engineering team, the product backlog will only have stories about technical improvement. This is good, it shows that you are working with a great engineering team. However, you should use the previous item to provide the team with product context, ie to show that there are certain definite goals for the product that you as a team have to achieve, and therefore you should always release new features in it. There must be a balance between maintenance and rewriting stories, and new features. I’ve read in many places something like: “define X% of the time for maintenance and rewriting stories”. I don’t like to make this suggestion because I believe that every moment of the product requires a different balance, and it’s up to the product manager and his engineering team to talk and mutually agree on this appropriate balance at each stage. Remember the importance of finding a good balance, as this will avoid the famous technical debt that, as it grows, will slow down the product engineering team.

Oh, and there’s one more thing!

Some product engineers end up becoming great product managers. It’s important to be able to figure out when an engineer is looking for “something else to do” and give him that career choice.

At Locaweb, we have (and had) great product managers who were product engineers. In some cases, they became product managers of the product in which they were engineers. On the other hand, there are some product engineers who have tried product management and disliked it.

For those who are used to measuring their productivity by features delivered, it may be strange at first to lose that productivity benchmark. As we have seen, a product manager’s day to day life is made up of a lot of talk with the various people involved in it, and that lot of talk can “scare” the engineer who is used to working focused on feature development. So, you have to leave the door open so that she can be a product engineer again, without any harm to her career.

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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

A importância do contexto no desenvolvimento de software

Nesse artigo quero propor um experimento mental. Vamos usar da empatia, principal característica de um gestor de produtos de software, para nos colocarmos no lugar de um desenvolvedor de software que recebeu do gestor de produtos do seu time a seguinte história para ser implementada:

Quando chegar em 39, deve soar um alarme.

Apesar de parecer ter informação suficiente, quando você começar a implementar, verá que está faltando informação. O que são esses 39? Quando chegar em 39 vindo de 38 ou vindo de 40? Ou nos dois sentidos?

Vamos agora ver a mesma história, só que com o devido contexto:

Estamos fazendo um sistema que monitora temperatura corporal e esse sistema deve soar um alarme quando a temperatura subir e passar de 39ºC.

Com o contexto fica bem mais fácil de entender o que são os 39 e porque foi pedido para soar o alarme. Sabendo disso fica bem mais fácil escrever o software certo.

Por isso, em sua próxima sessão de planejamento com o time, invista um tempo em explicar o contexto das histórias. Com isso você aumentará as chances de sucesso de seu software!

Não dá mais, tem que reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão com frases como: Está cada vez mais difícil mexer no código. Se fosse fazer do zero, seria muito mais rápido. Se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de email marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que a base de dados crescia, o sistema ficava cada vez mais lento. Por isso foi necessário reescrever o produto para usar PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes, ou seja, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000 clientes) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho. Contudo, durante esses seis meses o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado no reescrita. Se essa opção não existisse, teríamos que encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrever software, o time deixa de fazer coisas novas para o usuário do software, como mostrei acima no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso eu gostaria de tecer algumas considerações sobre o tema:

  • Tecnologias novas e melhores irão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (_model_, _view_, _controller_) separando o código do software em camadas de acordo com sua função. Mais recentemente foi criado o conceito de microserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs, facilitando a manutenção. Se, a cada nova tecnologia que aparecer, formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
     
  • Reescrever software tem que ter uma motivação clara de negócio, ou seja, deve de alguma forma atender os objetivos estratégicos da empresa que é dona do software e deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
     
  • Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, ou seja, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
    • Como será essa reescrita?
    • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
    • Como será a co-existência do sistema novo com o sistema velho?
    • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
    • Quando novos clientes poderão ser instalados no sistema novo?
    • Quando os clientes existentes serão migrados para o sistema novo?
    • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
    • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicado?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Quadrupling software development productivity without increasing team size and without quality loss

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!

Como quadruplicar a produtividade de desenvolvimento de software sem aumentar o time e sem queda de qualidade

Escrevi há algum tempo atrás um artigo sobre como organizar times de desenvolvimento de produto e algumas mudanças que fizemos nos times de desenvolvimento de software da Locaweb.

Temos nos focado bastante, desde o ano passado, em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb podem produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico abaixo mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver no gráfico, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.

produtividade_800

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, ou seja, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como dá para ver abaixo, mesmo com o aumento de produtividade, a quantidade rollbacks foi reduzido em 40%!

rollbacks_por_semana_800

Como conseguimos isso?

Não há bala de prata, foram várias ações que tomamos e temos certeza de que ainda há mais ações que poderão ser tomadas para aumentar ainda mais. Aqui vai uma lista do que fizemos.

  • Medir: antes de mais nada, para melhorar qualquer coisa é preciso medir, para poder saber se essa coisa está melhorando! Fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos então a comunicar toda a empresa sobre as entregas da semana. Cada gestor de produtos me manda na sexta-feira as entregas da semana, eu compilo os dados e anoto a quantidade de cada semana, gerando esse gráfico mais acima. A partir do momento que começamos a medir, ficou mais claro o nível em que estávamos e as ações que passamos a fazer começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, ou seja, algo na linha de “olha que interessante no seu gráfico, como vcs conseguiram aumentar esse indicador?”
     
  • Kanban vs sprint: outro ponto que mexemos foi a mudança de Kanban para sprint. Antes, todos os times rodavam com Kanban. Só que no Kanban, quando um item tem um impedimento, ele não pode ser mexido, e o time não pode fazer mais nada, o time fica travado. Contudo, às vezes acontecia de o time, por estar impedido mover um item de “doing” para “to be done” e pegar outro item para fazer o que não deveria ser feito. Uma vez em “doing” a tarefa só pode ir para “done”, não pode voltar pra “to be done” pois perde-se o controle da produtividade. Com sprint, o time organiza as próximas duas semanas de trabalho, colocando vários itens para serem trabalhados. Assim, se algum item tiver impedimento, o time pode começar a mexer em outro item e, com isso, consegue entregar mais no mesmo intervalo de tempo.
     
  • Discovery e delivery: o que o designer de UX e o gestor de produtos fazem pode ser chamado de discovery, ou seja, descobrir o que é preciso ser feito. Já o que engenharia faz pode ser chamado de delivery, ou seja, fazer e entregar o que tem que ser feito. Essa separação de papéis parece óbvio, mas não deixar isso explícito nos times pode atrapalhar o processo de desenvolvimento de software. Por quê? Por alguns motivos. O primeiro é que se o discovery não é visto de forma explícita, não é claro o que é feito nessa fase e nem o que motiva certas decisões sobre o que deve ser implementado no software. É díficil fazer alguma coisa sem saber porque se estáfazendo aquilo. O segundo motivo é que quando essa separação não é explícita, itens podem ir e voltar de delivery para discovery e vice-versa sem critério. Não raro a gente via nos times algo sendo implementado pelos engenheiros e UX e gestor de produtos, ao verem sua especificação implementada, desejarem mudar algo, no meio do desenvolvimento. Com a separação clara entre discovery e delivery, definimos que, uma vez indo para delivery, não se mexe mais. Se quiser mexer de novo, deve passar por novo discovery para só então ir para delivery.
     
  • Tamanho das entregas: uma discussão que temos já há alguns meses é sobre o tamanho das entregas. Em alguns casos nossas entregas eram bem grandes, trabalho de várias semanas ou até alguns meses. Como já amplamente discutido em metodologias ágeis, a entrega frequente de software funcionando é um dos princípios de agilidade, reforçado pela técnica de entrega contínua. É só procurar no Google para encontrar inúmeros exemplos de empresas de primeira linha que fazem múltiplos deploys por dia, com algumas fazendo centenas de deploys por dia! :-O Para fazer isso, é preciso os deploys sejam de entregas pequenas, bem pequenas. É preciso dividir toda história grande em hostórias menores. Isso é trabalho deo gestor de produtos em conjunto com o designer de UX. Já me perguntaram se isso não é trapacear, afinal, ao invés de entregar uma história grande estaremos entregando a mesma coisa só que dividido em pequenas histórias. Parece ser a mesma coisa, mas ao invés de entregar algo grande depois de semanas ou até mesmo meses, a gente acaba entregando valor todo dia, e assim nosso usuário já pode usufruir dos benefícios logo, ao invés de esperar semanas ou meses. Além disso, ao colocar em produtção todos os dias, já podemos aprender com o feedback e ajustar entregas futuras. E ainda há um benefício adicional, o fato de colocar em produção todo dia algum código faz desse processo de colocar código em produção algo mais simples, exatamente pelo fato de ser feito diariamente. Então, entregar uma história grande num período de semanas ou meses não é a mesma coisa que quebrar essa história em pequenos pedaços e entregar um pedacinho todos os dias. Há ganhos claros de produtividade em se entregar pequenos pedaços com frequência.

Além desses pontos acima, estamos começando a experimentar mais alguns pontos que certamente têm impacto na produtividade:

  • Primeira solução vs solução mais simples: é da natureza humana querer resolver problemas. Assim que um problema aparece, a primeira reação é pensar em uma solução e sair implementando essa solução para resolver o problema. Só que nem sempre a primeira solução é a melhor solução, tanto do ponto de vista do cliente, quanto do ponto de vista de quem implementa a solução. Por esse motivo temos preferido não começar a resolver imediatamente cada novo problema que aparece. Buscamos antes verificar se há mais soluções possíveis, analisamos todas as soluções e só aí escolhemos uma solução e partimos para a solução. Investir mais tempo pensando em outras possíveis soluções, sempre tendo claro qual a questão a ser resolvida e porque precisamos resolver essa questão. Saber o porquê ajuda a encontrar soluções simples. Uma solução simples (1 semana de implementação) que resolve 70% a 80% do problema é melhor do que uma complicada (1 mês de implementação) que resolve 100% e, na maioria das vezes, resolver 70% a 80% do problemaé mais do que suficiente. Às vezes a solução mais simples é não fazer nada!
     

    Exemplificando, na Locaweb o serviço de hospedagem e de email pode deixar de funcionar por um motivo externo ao serviço. O domínio ao qual a hospedagem e o email estão ligados, que é pago anualmente para o Registro.br, pode não ter sido renovado e, quando ele não é renovado, os serviços associados a esse domínio deixam de funcionar, mesmo que tudo esteja operando perfeito na Locaweb. Recentemente a Registro.br disponibilizou uma forma de a Locaweb cobrar o domínio do cliente em nome da Registro.br. A princípio a ideia parece boa, com a gente cobrando a gente garante que o cliente sabe que tem pagar esse domínio para manter os serviços no ar. Só que, analisando um pouco melhor, vimos que essa solução pode gerar mais problemas. O cliente vai receber duas cobranças pela mesma coisa, o registro de domínio, pois o Registro.br iria continuar cobrando o domínio. O que acontece se ele pagar as duas cobranças? E se ele pagar só a da Registro.br? E se ele pagar só a da Locaweb? Além disso, implementar um novo tipo de cobrança, onde iremos cobrar pelo serviços de terceiro, seria algo novo para o time e para a Locaweb. Novos processos teriam que ser desenhados. Começamos então a pensar se não existiriam formas mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar por seu registro de domínio na Registro.br. Como para poder cobrar pela Registro.br é necessário acessar a informação de que o domínio está para expirar, pensamos na seguinte solução, vamos implementar uma régua de comunicação com esse cliente avisando-o da importância de pagar o Registro.br, para garantir que o serviço continue funcionando, solução essa bem mais simples que duplicar o processo de cobrança. Se a Registro.br fornecer tb link direto para a cobran;ca do domínio, podemos mandar esse link na comunicação e as chances de resolver o problema aumentam ainda mais. E uma régua de comunicação é bem mais simples de implementar do que uma cobrança duplicada.

  • Escolha da ferramenta mais apropriada: aqui o tema são ferramentas para implementação da solução, ou seja, linguagem de programação, frameworks e bancos de dados. Cada ferramenta tem suas características e essas características as fazem mais apropriadas para resolver certos tipos problemas. Escolher a ferramenta certa para cada problema vai impactar a produtividade. Esse é um tema que estamos começando a estudar agora. Hoje usamos Rails para quase tudo, mas tem alguns problemas para os quais a implementação de solução usando outro framework ou outra linguagem pode ser mais simples e rápido. Usar uma única linguagem de programação para todos os problemas é como usar uma única ferramenta para todos os consertos que tem que ser feitos. Será que o martelo é a melhor ferramenta para apertar um parafuso? Será que Rails é a melhor ferramenta para gerenciar filas?

Temos confiança de que com os dois pontos acima, que estamos começando a mexer agora, conseguiremos aumentar a produtividade por 10x ou mais! \o/

E com certeza há ainda pontos que sequer percebemos ainda e que, quando percebemos e tratarmos, podem impactar ainda mais.

Conclusão

Como disse acima que não há uma bala de prata, mas tem uma ação específica que fizemos que tem impacto crucial nesses resultados: transformamos produtividade em tema importante em nossas conversas. Todos passaram a conversar sobre produtividade, o que pode impactar e como endereçar esses pontos. Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento, coloque essa tema como tema central de suas conversas e experimente bastante. Vc verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

ThoughtWorks finally moves “product over project” from trial to adopt!

ThoughtWorks is a well known software development company which is always one step ahead of the rest of the software industry. Many people who contributed and continue to contribute to our industry are – or were – ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo are just a small sample of people who work – or worked – there and have contributed a lot for the evolution of the software industry.

Since 2010 they publish a document called Technology Radar where they talk about their view on techniques, languages, platforms and tools for software development. This view is based on the experience from their consultants who work on a variety of software development endeavours from customers all over the world. They classify the techniques, languages, platforms and tools in four main categories:

  • Hold: when placed in this band, the item may be of interest to ThoughtWorks and others in the industry. However it is their opinion that the item is not ready to invest significant time and resources in which to build experience.
     
  • Assess: a technique, tool, language or platform that moves into the assess band of the radar is something that they believe is worth exploring with the goal of understanding how it will affect the technology impacted dimensions of your enterprise.
     
  • Trial: having established a radar item as something worth pursuing, it is important to understand how to build up this capability. Enterprises should look to trial the technology on projects that have a risk profile capable of taking onboard a new technology or approach.
     
  • Adopt: is the final stage that is of interest to them on the radar. Here they feel that the industry has begun to move beyond the trial phase and has found the proper patterns of usage for an item. An item may also appear in the adopt band if they feel strongly that the industry should be adopting a radar item now, rather than going through a more gradual adoption approach.

In May 2015 I was quite pleased when May’s Technology Radar edition brought “Products over Projects” as new technique and already recommended it as TRIAL. This showed that ThoughtWorks started to believe that software development should not be viewed as a project with a clear start and finish, but rather as a product, developed to support business processes of the owner of the software. This software will have a long life cycle, so long as the life cycle of the business processes it supports. For this reason, software development should not be viewed as a project with a predictable end, but rather as a product, a tool that will support the business processes for as long as the business processes exist.

I wrote about the differences between a product and a project back in 2011 and the more I work with software development, the more it get clearer to me that we should manage software development as a product, with a long lifecycle, with an unpredictable end. For this reason product management is so important for software development.

From trial to adopt

When I saw the November 2015 Technology Radar edition I was even more pleased when I saw that ThoughtWorks decided to move “products over projects” from trial to adopt. Doing so they now consider software product management as a technique that they feel strongly that the industry of software should be adopting in order to increase the chances of success of their software. Here it is in their own words:

We’ve long been championing the idea that thinking of software development as a project – something budgeted and delivered during a limited time slot – doesn’t fit the needs of the modern business. Important software efforts need to be an ongoing product that supports and rethinks the business process it is supporting. Such efforts are not complete until the business process, and its software, cease to be useful. Our observation of this products over projects approach, both with our own projects and outside, makes us determine that it is the approach to use for all but exceptional cases.

Certainly this will help people all over the world in creating better software, which will meet the needs of their customers while helping the software owners reach their objectives.

This is a great step forward for the software industry! This is great step forward for software product management! \o/