How a Quality Assurance Policy Should Actually Work

The quality assurance policy is not just a nice document that describes the mission and values of the company. This is a huge underlying system, which, for example, our company has been creating for more than 10 years. If it is not followed, unexpected situations may arise. Let's consider what happened during the implementation of our internal project.

The quality assurance policy often emerges as a "rework" that a team performs based on their own experience or to avoid repeating other people's typical mistakes.

Let's consider such mistakes on the example of an internal project that our company worked on at the early stage of our growth many years ago.

Where It All Began

The project was launched a long time ago, the scope of work was known and planned as large and small sprints. A hard deadline was scheduled to one of the most significant dates for the company: it was necessary to implement an important functionality, on which the tasks of various departments depended.

Usually, the team worked steadily, its members were constantly changing, as employees temporarily released from commercial projects were involved in the project implementation. That day, as usual, the team checked the task tracker and began to perform the current tasks slowly but surely.

The morning did not promise any problems until we received a chat message: "Guys, we have problems, we will not have time to release on time." When they realized that they would not meet the deadline, they urgently called in an expert who was supposed to help analyze the situation and find out what went wrong.

What We Found Out

Background: The release involved a two-week sprint. The team consisted of a PM who was involved only occasionally, three developers and one QA specialist. The estimation was 150 hours, taking into account the diversion of experts to other projects.

The study found:

• By the middle of the sprint's first week, when transferring the project from one PM to another, they forgot to explain part of the feature implementation logic. The roadmap was not updated for a long time, and the description of tasks in the existing document was insufficient. When they recalled of this feature, which didn't happen until the middle of the second week of the sprint, it added another 60 hours of development and retesting.
• At the end of the first week of the sprint, the most knowledgeable developer was pulled away from the project, and a new one was brought in without any onboarding. At the end of the second week, the lead developer returned to the project and rewrote the newbie's code. The result was extra 40 hours of development.
• When changing the QA manager, it also turned out that they did not prepare documentation for that internal project. As a result, the new QA manager spent another 25 hours to understand the logic.

Our Findings

Instead of 150 hours of development, the project required 275 hours — more than the planned two weeks. The budget was exceeded twice. And these are only the most obvious problems that were revealed on the project.

How to avoid such problems Experts of our Quality Assurance Service share their recommendations. So, in this case, you need the following:

• prepare and harmonize the project transfer regulations,
• appoint persons in charge for internal projects, who will be the most knowledgeable on the project,
• implement a task setting template (which is always a plus) to simplify the work,
• introduce a mandatory minimum for documentation, including a document on onboarding of new employees.

Very often we can say something like "the project is simple, then why complicate something there, because it is faster to just finish it off than to comply with the rules and standards." In most cases, such a project is unlikely to be completed successfully. Minimum principles and standards that must be followed must always be in place, even in the company's internal projects.

Our Conclusions:

• Even in the simplest project, you need to work on the customer expectations, even if the customer is your own company, and create requirements on their basis.
• Introduction of engineering practices (code writing standards, Code Review and others) will take time, but it will reduce the time required for future support.
• All the best practices of Scrum: demos, daily meetings and retrospectives are important to adapt to the tasks of a particular project and to the internal development culture.

We have another article that deals with implementing the development culture to avoid chaos in the project and improve your chances of achieving the desired results.