Scrum improves software development quality

07.08.2018

After implementing scrum for Droptica's Drupal developers, we observed outstanding results in terms of the quality of our projects. In our opinion, scrum not only helps with maintaining quality – it simply enforces it. How does it do it? It puts emphasis on testing as early as possible. Writing good code that can be developed becomes a necessity. It supports automatic testing and automation of the development process. It reduces unnecessary costs and increases business flexibility. Don't believe it? Be sure to read this article and tell us what you think!

Quality

If we asked a large group of people what they associated with the quality of the project, we would certainly get many different answers. Personally, I like Joseph Phillips’ definition the most, since he believes that “quality is the potential of a project to meet the requirements expected and defined by the client. Quality is an asset, a value and a source of profit drawn from the proper implementation of the project.”

This statement may be quite general, but it boils down to a simple thing – good quality software should do exactly what the client and end user expect of it. We can extend these definitions and say that quality software should not do anything unexpected, either.

What is scrum?

Scrum is an iterative and incremental way of running a project, based on the principles contained in the Agile manifesto, that is:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

If you would like to learn more about scrum, I would recommend reading the Scrum Guide or following our blog, as there will probably be a few more articles about it in the near future.

How does scrum help maintain quality?

In scrum, like in other agile methodologies, there is a lot of emphasis on quality. But does it really help in improving quality? I hope that the following arguments will convince you that this is the case.

Frequent releases require good code

At the end of each period, there needs to be a version that can be deployed and shown to the end user. Imagine that you are writing poor quality code. After a number of releases, the technological debt starts to grow higher and higher, to the point that maintaining such an architecture will start to be an obstacle to further development – you can be sure that your client won’t be happy about that. The scrum model requires you to write a code that is easy to maintain and develop.

Testing from the beginning of the project

In scrum, the project is divided into sprints (from weekly to maximum monthly periods), which end with delivering a working piece of code. This requires testing from the very first sprint and as early as possible in order to be able to present a proven solution for the customer. This changes the role of a tester, who is no longer a bouncer who stands at the final gate and rejects ugly solutions. Instead, they become a player in the development team, whom he helps in ensuring the quality of the project. Testers cease to be a separate role, instead, they are a part of one team that pursues the final goal of a given sprint before it ends.

Even during sprint planning, testers’ perspective on the project and their understanding of how the system will behave in certain situations can be really useful.

Another interesting solution may be writing tests even before the code is created, forcing the testers to think about use cases and ask about the ones that the developer could not predict when developing a given feature.

Less costly mistakes

In the traditional business model, the development team is provided with a specification, according to which the project is developed. It is easy to imagine a case in which a well-prepared specification is used to develop a project that is fully compliant with all the requirements listed there. The development takes six months and after that, it is presented to the end user, who hates everything that the designers came up with. It would seem that the quality of the delivered project is excellent since it was consistent with what the customer wanted; however, the market won’t remember this as one of your successes.

In scrum, at the end of each sprint, we provide a working feature which – if the customer wants – can be implemented and shown to the end user. Thanks to that, if we go in the wrong direction, we lose one sprint’s worth of work at most.

Quick delivery supports automation

On the one hand, every sprint must result in a new fragment of a working website, while on the other, new features cannot break the ones already in place. As a result, the number of things to test starts to grow at such a rate that without automating the process, we would have to increase the number of people who would check the website before it is deployed. Since the responsibility for the quality of the project is borne not only by testers but by the entire team, developers are more eager to help and implement a testing framework.

Communication, communication, communication

Daily meetings of the development team, including testers, support communication within the team. If a bug is found, the entire team is aware of it and can react quickly.

In scrum, not only does the team have to communicate with each other – it is also necessary to talk to the customer’s representative (Product Owner). This is important because the team not only informs them about the progress of their work but also gets answers regarding any ambiguities and doubts, for example about how a specific function should work.

Of course, the client usually speaks the business language, while the developers speak technical, but our experience shows that during subsequent meetings, they start to communicate better and better. This eliminates cases in which the developers have to guess how the system is supposed to work and cases in which the client would like to know something about the progress of the work but doesn’t know whom to ask.

Respond quickly and grab opportunities

As I mentioned earlier, in agile (and thus also scrum) projects, we try to deliver versions of the projects that are ready to be deployed and shown to the end user as often as possible. This allows us to test our business concepts faster than in the traditional methods and start reaping the benefits of them earlier.
The same applies to the changes that the market is imposing on us. Since our project must be created in a way that makes it easier to modify, we can quickly adapt our project to new conditions.

I think that the arguments given here are enough to make you think about whether it is worth trying a scrum project for once. If you want to learn more about scrum, you should definitely check out our other articles on this subject:

I also encourage you to follow our blog, because this is certainly not our last article regarding this subject.

I would like to conclude this article by quoting the motto of the Gucci family: “Quality is remembered long after the price is forgotten”. This is not supposed to say that only expensive projects are good – the point of this is to remind you of the fact that if you do not take care of the quality of the project, your users will not be quick to forget it. So, let's always try to think about good quality in the context of your projects, and your customers will certainly appreciate that approach.