This time I would like to take a look at how teams support code quality in their software development processes. I will analyze some stages of such processes and check how the explicit presence of individual steps in Kanban Board / Scrum Board can supports the maintenance of Clean Code in teams and organizations.
Below are questions from the years of my observations that are worth asking while looking for answers regarding quality control
- How have you defined concept of quality within each stage of your software development process?
- On what basis do you consider given stage to be completed correctly?
- Did you discuss the term ‘code quality’? Did you agree / announce it?
- Is it easy to bypass quality control within a given Scrum / Kanban board column (also code quality), for example due to urgency?
The simplest board
For almost 20 years of work in several companies and as a trainer, I visited many offices and talked to many teams. In these offices I saw tens of boards visualizing their development processes, e.g. Kanban or Scrum.
Here is an example of the simplest board
But how does the above process support quality? Where is the place to review the code or add missing test cases or Clean Code? Where is the place for refactoring, when the code has ceased to be readable by others after making changes, which will hinder its further development?
I must admit that the teams I worked in many years ago also used similar boards. Many times our managers asked only one question : “is the functionality already implemented?”. It was also common that the person answering it (deciding about it) was tester.
Quality is not hide and seek game
Based on my experience in the above case, things such as adding missing tests, having automated code quality reports, refactoring, adjusting the project architecture to new requirements – if they occur, they will be performed in a hidden way… You will not talk about them officially, only programmers will extend the programming or testing phase to stuff them somewhere …
Steps that are not an official part of this Kanban / Scrum processes can easily be skipped. Alternatively, developers perform such steps outside of the process but this always causes programmers discomfort.
The worst-case scenario is micromanagement based on an incorrect (incomplete) process. When programmers are controlled what they do hour by hour then they will not pay too much attention to Clean Code. If it is not an official part of the process, the team will not adopt it most likely. Perhaps it will take place in the case of programmers aware of the consequences of technical debt and legacy code. But even then as a hidden form of extending the planned implementation time.
The most extreme case I encountered concerned rewarding the manager only for the speed of product delivery. At the same time the developers / testers were the only “responsible” for the number of defects reported by the customer in the following months.
Introducing transparency
There are a few checkpoints in the process for this
- Has the code been reviewed?
- Is the code clean – readable and extendable after changes?
- Is the code covered by component and / or integration tests?
- Did we write unit tests?
The common practice is that if nobody officially evaluates us for something at work, we probably will not worry about it. It may happen that at the same time, team members are only paid for the speed of delivery and are never judged by the number of defects reported by customers. Who in this case receives a payrise? This approach can create an unhealthy atmosphere between programmers working at a higher speed and those who care more about the quality of the code.
Let’s move on to analyzing the next whiteboard
Does care for code quality look better here? Can I skip code review process in this case? In addition, this process emphasizes that no one can test the solution in the integration environment before someone else finished code review check against Clean Code principles.
This configuration sounds more reliable in terms of quality control. Anyway I still saw its different results based on different rules of work organization. Here are two real examples
- At least 2 programmers should review the code change. But who in this case is fully responsible for making this review? It may happen that 2 different programmers performed a cursory review at the same time to speed up the task waiting for final-tests going through “available” quality engineer. Moreover, each of these two programmers could have assumed that the other would review more thoroughly…
- Only one person reviews the code at the same time and takes full responsibility for readability, coverage of test cases, the possibility of extending if they approve the changes made. If such a person has any doubts about the quality, they have the right to submit their comments to the author or the next reviewer for confirmation.
The second approach seems more resistant to “leakage defects.”
Introducing even more transparency
Let’s add one more column to the board.
In the above case, it is very clear that testing performed by Quality Engineers takes place only in an integration environment. You can also clearly see when someone has already reviewed the task so it is waiting for next actions.
[FM_form id=”1″]
Transparency of technical fixes like code cleaning though refactoring
The result of a code review may be that you need to make corrections. Such a correction can be an urgent refactoring, adding missing integration tests. It can also be setting an appointment session to re-discuss architecture because the problem must be discussed at the level of the whole team.
Some teams may think it’s okay and they just put the task into the highest priority into “to do” column. But does this make it possible to distinguish a task with new functionality from a “patch” task? Will this not mean that the conversion tasks will compete with the new tasks regarding the new functionality in the “to do” column? Therefore, another option will be to explicitly add a column where the task goes through additional “fixes”.
Of course developers still omit the rework/fix column if the code review goes well. But its existence emphasizes that making corrections to the code quality on daily basis is perfectly fine. It should happen when the code works as expected, but tests are missing or code is not readable.
Any other transparency
Be agile. Periodically discuss all quality control issues during the retrospectives. Place the most important stages regarding quality control in the process. Make them “legal” and official. Take responsibility for code quality.
Similarly, another example: deployment into production environment – make it visible what exactly happens with each task. You can discuss the benefits of such a column yourself.
Summary – ensure code quality control visibility
If you want to take care of quality, you must create processes and procedures that encourage people to improve quality and discourage people from skipping it. This should be an environment in which people experience the consequences of their decisions regarding the lack of quality but are also entitled to self-improvement of these principles.
Pay close attention to the shape of your process. Make his steps very clear and well defined in terms of quality control. The process should highlight all things related to requirements, such as quality, code readability, scope of tests, refactoring options, perhaps even exchange of technical and business knowledge.
Remember that Kanban / Scrum related procedures and processes ensure psychological safety at work. They constitute guidelines for the performance of our duties and assessment of our work. If we do not define “expected” result clearly , the probability of its occurrence will be low.
To introduce the refactoring habit into Clean Code within your team, please also read:
How to begin refactoring code in a team?
What drives a team to continue refactoring to Clean Code?
Lyndon