Sixteen years ago, a group of seventeen people met at the Snowbird Ski Resort and came up with the Agile Manifesto in order to create better ways of developing software, while helping others do it too.
However, while it did work for a while, it wasn’t long before people started abusing the Agile term and methods. Today, there are literally thousands of self-proclaimed Agile experts spreading the methodology without even having a background in coding.
Many more reasons followed for Agile projects to fail and it’s now clearer than ever that Agile is doomed as a methodology and that it’s time for it to be improved.
In this article, we’ll cover some of the reason why Agile has been dying for a while, as well as how Code Review can help revive Agile to become better for everyone.
Scrum Masters With No Technical Background
To implement Agile, teams had to be transitioned towards using the Scrum Methodology, all in order to help software developers fulfill the four basic principles Agile was built on – Collaboration, Trust, Accuracy, and Improvement.
The main problem is that the Scrum Master courses are open for anyone, and most of the people enrolling in such courses have no technical background at all.
This means that Agile as a methodology is used by people who are not software developers, which creates a problem when it comes to coding. While non-IT SMs are perfectly capable of leading the team there are times when a technical background would come in handy. The definition of scrum masters is:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
Should SMs have a technical background or not is a matter of personal preference, however, as it can be seen in the definition above, it is not a requirement according to Scrum guide.
Code Quality and Technical Debt
The main problem with Scrum teams is that they are usually assembled on short notice. People who have never worked with each other all of the sudden have the responsibility to deliver the code, which often leads to multiple problems.
While the project is in its starting phase, team members will usually think about code quality and refactoring, but as the project gets to the next stage and tasks start piling up it gets messier. A lot messier. That’s when cracks start to show in the code, which is never good for the software.
The biggest threat software developers face today is technical debt. The technical debt term was coined by the creator of the first ever wiki Ward Cunningham. The underlying concept of technical debt is that implementing poor or simple code in place of a more complicated, but long-term solution causes additional work in the future. Cunningham says:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.“
With code review, however, the possibility of falling into technical debt is reduced to a minimum.
What is Code Review?
Code review is a process where programmers would systematically check each other’s code for any mistakes, errors, or messy code. Programmers would still be dedicated to their parts of the code, but each programmer would check the code of the next one, thus accelerating and streamlining the whole process of software development.
Here are some of the reasons why we should always employ code review in software development:
- It Protects the Client – Software code is a product just like any other, so it needs quality control if you’re to satisfy the needs of your clients. Potential problems like bad dependency management or poor architecture need to be reduced to a minimum, which is exactly what code review is for.
- Skill Improvement – Reviewing code of your fellow programmers and vice versa will create a debate, which in turn means sharing the knowledge about code and how you all perceive it. This knowledge sharing is bound to increase the understanding of the code of the whole team.
- Architecture Synchronization – With many programmers being allowed to implement their own architectural style into the code, you might end up with a lot of fragmented ideas in your code base. This is why Picnet IT services and alike employ code review to create a single, synchronized style of code.
The Importance of a Technical Leader
Agile has been often interpreted as if all the software developers working on a certain project should have equal rights when it comes to committing code and decision-making.
This creates a weird situation, one that sometimes can become a dead end – because there’s no leader to give the final word.
Almost every field that employs teams of people to work on a project always has someone in charge. Restaurant kitchens always have a head chef to control the overall quality and to lead the team towards a single goal. Orchestras always have a conductor.
This is why software teams should also have a technical leader, a person who will overlook the software development process and actually have the time to read the code.
That way, there will always be that one person to have the final say, while also being responsible for the code quality.
Conclusion
The original Agile was created with a noble goal in mind – to help software developers reconnect with businesses. But once no-tech background developers started to pile in, to become Scrum Masters, the whole methodology started to suffer from messy code and poor architecture.
This is why, if Agile is to move on to another phase, it’s imperative to implement a system of inspection and code control. Code review might be just the answer, but even if it can’t solve all of Agile’s problems, it will at least improve the code that is being implemented in the software around the world.
Agile is still present in many organizations worldwide and it will take time for it to either evolve or perish within those organizations. This post is not meant to present agile in a dismissive way, but to point out some of its shortcomings and more importantly the shortcomings in agile implementation.