How to deliver quality?

Architecture with a team

Our team had grown rapidly. We had to learn the client's business logic and respect time constraints. Under these circumstances, it was easy to accumulate a technological debt. Over time, we felt that this was becoming an obstacle and that we needed to address this problem before it became more serious. We had to find a way to coordinate several teams to move them in a common direction. That's how our grooming architecture began.

This workshop takes place a few days before the start of a new sprint. The developer team gets together and looks at the content of the next team sprint. Each of the stories will be read and explained to the team to make sure they understand their objective. Next, the team will look at the architectural requirements. What will be the technical challenges? What part can be made into a reusable component? Do we have time to rework the code to erase a technology debt, and what solution can we implement in the time available? Once these questions have been answered, the work to be done will be clear to each team member. The technical solutions found will come from the common knowledge of the team, resulting in solid solutions.

To ensure that the work is well coordinated between the teams, our Architecture Owner will participate in each team's workshop. His role is to advise the teams and ensure that the architectural vision of the project is respected. But it remains the role of the team to find the solutions. The Architecture Owner will also have to bridge the gap between the teams. He will have to communicate and explain as needed the solutions that the other teams will implement during the next sprint.

Finally, following the review of the sprint with the Product Owner, we do an architectural review. The technical work will be presented to the Architecture Owner and the other teams. We present the reusable components that have been created, the patterns that have been introduced, and any other relevant technical information that needs to be conveyed.

With these new ceremonies, the team is more aware of the architectural work and the technical challenges of the system; both those that have been completed and those that are still to come. 

Peer Quality Assurance

It's never pleasant for a completed story to be reopened by the quality assurance team, and we found it problematic when this happened too often. In addition, the reopened story could be from a previous sprint because the QA team was overwhelmed with work up to that point. Our solution to this situation was to introduce peer quality assurance.

When a developer has finished his story, the code review has been accepted and he has done the necessary testing, but before he pushes his changes in the source code, he will have to give them to another developer. This second developer will have to compile the changes on his workstation. This prevents the compilation of the source code from being broken by the changes, either by a file that has been forgotten to be added to the development code, or by a configuration on the development workstation that does not conform to that of the compilation machine. Once the compilation has been successfully completed, the second developer tests the story to ensure that there are no flaws or omissions in the business logic. When the second developer is satisfied, only then can the development branch be put into the source code.

With this extra step, many of the problems that would have been made visible by the automated compilation machine or by the QA team are found by the second developer. These problems are found and fixed more quickly and the team's confidence in a finished story is increased.

Team Quality Assurance Session

It's hard to be satisfied as a team with the work we do when the sprint review seems to turn into a debugging session. But a story delivered in the first week of a sprint can sometimes be impacted by changes made near the end of the sprint. That's why we introduced team quality assurance sessions. 

We started these sessions on the eve of a delivery, to intensively test everything that had been done as a job. Every time we did such a session during a sprint, the number of defects or business rules not followed was higher than in other sprints. By introducing this session at the end of each sprint, two days before the review, we can clearly see the work done and the problems that might have escaped us during the sprint. The next day, we take the time to make any corrections that can be made. If a major problem has been found in a story and the team considers it unacceptable to deliver it as is, the story can be taken out of the source code and the patches will have to be made at the beginning of the next sprint. This can delay its delivery, but we make sure the quality is there.

This allows the team to avoid any unpleasant surprises during the review and also increases confidence in the work that has been done. A team session also allows for better communication and understanding of what other developers have done as work in the sprint.

A cumbersome process?

We consider each of our teams to be made up of reasonable people who have enough judgment to know when it is possible to skip a step. Our methodology is a guide, not a rigid structure. Correcting a syntax error does not require the same effort as rewriting the core logic of the system. Our teams are dedicated in their work and they do not want to give our clients a poor quality deliverable. So we maintain flexibility in the process. A team member may at any time not take a step if he or she feels it is reasonable to omit it. This avoids slowing down development unnecessarily.

In spite of this, since the implementation of these steps in our work methodology, we have questioned the time involved. Is it too cumbersome and costly?

What we have found is that it affects the velocity of each of the teams and that the work takes a little longer. On the other hand, the quality is greatly improved. The stabilization period before a delivery has been much shorter and the teams have a greater level of confidence in the deliverables.

After delivery, the customer finds fewer defects, and the severity and impact of these problems are less, avoiding the need to make quick deliveries for emergency fixes.

It is easier to predict the effort required during delivery development. We reduce the amount of work required for delivery and post-delivery. Higher code quality makes the work easier, making it easier for teams to work together and evaluate new features.

In the end, the team and the client are confident in the deliverable that is delivered. Also the evaluations are closer to reality and there will be less maintenance effort after a delivery.