Have Source Code in Scrum Reviews

It is a widespread opinion that source code makes no sense in Scrum review meetings. A number of circumstances makes me believe that this is wrong. I think it is important to also look at source code when holding a Scrum review.

What Matters

You might have heard this saying:

"Doesn't matter how it is called as long as it works"

This is a quite destructive statement. It enables developers to solve problems in any way that comes to their mind, even if standardized solutions are available. Imagine a developer that creates a dedicated sort algorithm instead of implementing the Comparator interface. Don't believe they won't do such, they will, because → no one wants to see source code!

When it doesn't matter how source code looks, temporary workers will hack down any problem in record time. You lose code reusability, readability, maintainability. To be clear: this is not about code formatting (spaces, tabs, line lengths, ...), this is about writing code for humans, not machines.

Names matter, readability matters, reusability matters!

All of that can be assured only in review meetings: package names, class names, field names, method names, parameter names, even algorithms and design-patterns must be accurate and understandable. Don't allow acronyms and abbreviations unless they are really common.

Common Language Sense

Common Sense is at the center of Scrum. A good team is one that has a common sense over all project aspects. Source code is a project aspect, moreover it is the actual asset of software production.

Pull-request code-reviews are not enough, such is done by just two developers. The whole Scrum team must see the source code. Criticism and discussion must be possible. Developers must not hide behind their reputation as experts, they must present, explain, and convince the team. (Could require management preparation to avoid formal disputes about indentations.)

It is not acceptable that one developer works in object-oriented style, one in functional style, and the third one just reached structured programming level. They must agree on a common way to implement things, even if this takes time.

Polyglot environments allowing different programming languages are not helpful either, they much more promote the "Doesn't matter" attitude. Freedom of expression is not useful in software development.

If your software product is implemented in English, Hindi, Chinese and Spanish, you will not be able to maintain your source code without the authors. At most you could allow one language for technical solutions (English) and one for business solutions (native), but no more.

All of this must be verified in reviews with the whole team!

Read It Like a Book

Robert C. Martin stated this, referring to Grady Booch:

Clean code reads like well-written prose

Developers are responsible for simple and readable source code within their programming paradigm, be it object-oriented, functional, or structured. And, as stated above, you should not allow to mix all programing paradigms. Thus all developers must understand what their colleagues implement!

How could this be achieved when not in Scrum reviews before the whole team? When it is not readable, not understandable, not arguable, decline the source code, have it rewritten!

Framework Libraries

If the project goal is a framework library, having the source code in review meetings is an absolute must, because the library API will be the result of the project.

Management

Source code quality will affect software maintenance, which makes up 70% of all production efforts. Unfortunately quality assurance tools like Sonar will detect only a certain kind of code duplications, surely no logic duplications. And they can not verify the accuracy of class-, method- and field-names.

When the project management accepts sayings like "Doesn't matter how it is called as long as it works", it will also state "Source code doesn't matter" itself, and this is nothing more than a commitment to throwaway code. When you know how expensive these things are, you may also suspect what gets thrown away here.

Maybe the problem aren't the developers alone? How about demanding sustainability from the management?

Resume

Source code is what we live on in the long term, it's the actual asset of software. Would you dare to trade things without being assured of their sustainability? When no, demand to see source code in Scrum reviews.