have become buzzwords in the industry in the context of "product quality." Senior management has a belief that moving the organization/team to Agile-Scrum will help release a great-quality product. Is that true? No, not at all.
Compared to other methods, like Waterfall or V-model, the Scrum framework definitely helps in implementing better process structure and measurement of success in a short sprint cycle. However, Scrum primarily provides a process framework. It is still up to the team to implement good development practices. If teams fail to improve on a few fundamental development practices, that will lead to a low-quality product.
This is my experience: Without making real improvements to software development practices, expecting a quality improvement is a sin.
There are quite a few practices that can help a team both in being Agile and in releasing world-class quality.
Let me take a little deep dive into two of the fundamental practices: design practices
and coding practices
Evolutionary design versus up-front detailed design
Though the teams execute the project in an Agile-Scrum way, I still see that there is good effort spent on up-front design. Some teams even spend two sprints just on POCs and design. They have a reason to do it; they can estimate better or come up with an accurate timeline for the release. Here, however, is the problem with up-front design.
Look at the picture above. The x-axis refers to project timelines and the y-axis refers to the product knowledge that the team has. At the beginning of the project, the product knowledge or the knowledge about the new features is pretty minimal. During release planning, the team knows in detail about the first one to two sprints and has high-level knowledge about the rest of the features. The team understands at the high level and has high-level estimates. The reason we do high-level estimating (in story points) is that we have only limited knowledge on the future stories. However, by doing up-front design, we come up with a good design for those stories, which are less well known.
Let me know ask this question: How important is the design/architecture of the product? Most experienced developers say that it's a critical aspect in software engineering. I too believe this. Without good architecture/design, we cannot come up with a very stable and reliable product. With up-front design, design is done when the team has minimal knowledge about the product. This doesn't work.
OK, what's the other option? Design when the team knows the entire product? That will be in the middle of the project, too late. So it is inevitable that we focus on evolutionary design, where the design is made in every sprint for that sprint, with a bit of up-front/high-level design during the initial sprint.
Design what you can code
Do detailed design only for the code that you need to write for the sprint. There is additional effort spent on coming up with a generic design and generic reusable libraries. While they are good to keep for future use, it is critical to design only for the sprint's need.
What's the issue with having generic design?
The assumption is made that the future story in the backlog will definitely be implemented. If the story is removed from backlog for some reason, the code written today will be dead code. As time goes by, no one will remember that there is generic code that needs to be removed.
Removing the already written code is a risk that leads to a good testing effort.
Having a dead code unnecessarily creates a bigger code base, which will be difficult to maintain if it grows uncontrolled.
Dead code is also an issue from a security perspective. This code is not tested, so no one knows what its behavior would be if it were to be executed.
So it is not only bad practice to write a code that is not used but it is also dangerous to have such dead code.
The other important aspect of software quality improvement is code quality. Clean code written the first time eliminates a lot of waste. For example, good code doesn't introduce regression defects during testing. Here are few ways to confirm that the code written is of high quality:
Collective code ownership
The team should be able to collectively own the entire code base. This means everyone on the Scrum team should know the code, to at least a certain level. It's OK to have an owner for the code, but it shouldn't be a black box for other developers in the team.
In my experience, the teams with a single owner for code have failed drastically. Having minimal knowledge about other people's code helps create awareness about the overall code base and its quality.
The above point demands that code be simple, well commented, not too generic, very modular, etc. I have seen code that has a comment for every line. For example, a line of code "count++" with a comment "incrementing...." This is explicit; there's no need to add comment. Refactoring helps keep the code simple.
It's essential to "throw the code that you wrote today." OK, let me reword it: It's essential to "refactor the code written today." The developer should refactor the code that was written today to make it clean, simple, thin, and usable.
Review code for finding defects
As per industry information, it is about 10 times costlier to find and fix a defect in the system testing versus finding and fixing it through development practices. It is also proven that 70 to 80 percent of defects can be found through effective code reviews and formal code inspections. Effective code review to find defects helps in writing good code.
The objective of code review need to be well defined. Code review to find test defects is completely different from reviewing for coding standards, coding practices, etc. Code review for finding functional/nonfunctional defects helps the team think about business scenarios while writing code. Repeating this exercise helps reduce defects in the system. Here is a snapshot from a book The Economics of Software Quality
, by Capers Jones and Olivier Bonsignour. It clearly conveys that the formal design and code inspection are more efficient than some system testing practices.
Peer review best practices
I commonly hear from teams that peer design and code reviews don't find defects. I would challenge this statement. The effectiveness of peer review is directly proportional to various factors:
Spending about 10 percent of engineering effort on code review helps in finding 60 to 70 percent of defects. However, spending 2 to 3 percent effort yields only 5 to 7 percent of defects. So the results are exponential. Adjust code review effort for few sprints and find the optimum effort that gives you the highest percentage of defects.
The skill set of code reviewers (architects, cross-functional SDETs, testers) add more and unique value to the review, so don't restrict reviews to only a few developers. The objective of code review should primarily be finding defects.
Frequency of code review has an impact on the number of defects found. Good practice is to review the code that was written on that day, or at least during the same week.
Type of review: Reviews vary from self-review to informal peer review to a very formal code inspection. There is no specific type that yields a better results. Try them, and choose the type of review that yields good results. What works for your team is what you should follow.
Code what you can test
Write only the code that can be tested by end of the sprint. As per Scrum, the sprint scope is locked and everything else can change later. So it's not a good practice to write generic or reusable code that can be used for future requirements. The lesser the code, the fewer the defects and so the higher the quality.
We make these practices part of our story Definition of Done and track them as part of every story. This helps in doing clean design and coding.
Enjoy Agile designing and coding!