Scrum’s framework lends itself to high-quality solutions, but many loyalists need clarification on how to address that goal in the daily use of Agile methodologies.
In Part 1 of this blog, I explained two key ways to prioritize quality through Agile Scrum:
1. Use a cross-functional Scrum team to reduce external dependencies.
2. A Development should have a Definition of Done (DoD) so they know when an increment is in fact “done”.
Now, I’ll introduce the concept of developer feedback loops and several handy practices to add to the foundation of your Agile Scrum practice.
3. Shorten Developer Feedback Loops
In order to shorten developer feedback loops on a Scrum project, tools and practices must be in place. For clarity, a feedback loop in this context is a heightened awareness of the positive or negative effect of change to a system. There are many ways to improve these loops, so let’s take a look at them.
Version Control
A modern version control system is necessary for collaboration. It provides a central repository for Scrum teams to work and frequently merge code. There are many systems available and some are even free. It’s unacceptable to not have a unified source control system available to your Development team.
On the topic of version control, branching is evil. The more branches you have, the more complex your merging problems will be. If you’re unable to avoid branching be hyper-aware of the integration consequences you may suffer.
Continuous Integration (CI)
CI is the act of integrating code into a shared environment several times a day; preferably on code check-in. As a developer into source control, an automated build verifies that no new integration issues have been introduced. This practice helps Development teams understand integration issues early in the process, so individuals that “break the build” can address problems immediately.
CI should be executed at near light speed to keep the feedback loop as quick as possible. Don’t make the mistake of using thousands of tests to execute – the feedback needs to be almost instantaneous.
Continuous Deployment (CD)
CD is taking a build and deploying it immediately to an environment. This deployment doesn’t have to go to production; that’s considered continuous delivery.
Once a CI build is successful, a great practice is to deploy it immediately to a lower level environment. This has many benefits and can be your first step towards continuous delivery. Unforeseen problems that a CI build didn’t find can then be found through additional test automation that may take longer to run, or through manual exploratory testing.
The aim should be to build, test, and release software as frequently as possible. Implementing CD is the next step in a developer understanding whether or not they’re releasing something with a negative effect into the environment.
Code Coverage as a Metric
Code coverage tells us what percentage of the system under test has been exercised by tests. This metric helps Scrum teams to understand where they have gaps in unit test coverage. It’s a great tool to identify areas of the application that may benefit from additional coverage.
As with any metric, it must be treated delicately and not weaponized. Even if a system has 100% coverage, there’s no guarantee that the system has been properly exercised by good testing. Code coverage should not be part of a DoD. It can turn into a vanity metric that causes developers to simply write tests without focusing on which tests matter – and which ones don’t.
4. Implement Development Best Practices for Scrum
Now that we’ve covered ways to achieve high-quality solutions through feedback loop improvement, let’s examine Scrum practices your team should use. There are an infinite number of practices development teams can adopt to heighten quality on a Scrum project, but these 3 Extreme Programming (XP) practices are still my top choices today:
Test Driven Development (TDD)
TDD is the practice of first writing a failing unit test, writing code that satisfies that unit test, and then refactoring the code. This loop can happen over and over until a good solution has been developed. Its origins are in XP and it has many benefits including higher quality software, faster development, improved system design, and built-in system documentation.
Building an emergent architecture requires the ability to safely refactor code. Using TDD, refactoring is exponentially safer since you can run negative and positive tests immediately in your Integrated Development Environment (IDE) to better understand implications. In the same vein, your test suite can be attached to CI builds and deployments.
Pair Programming
Pair programming is the act of two developers working simultaneously on one machine to produce code. There are two roles: the pilot and the navigator.
-
- The pilot is the person with their hands on the keyboard and mouse punching out the code
- The navigator is the person at full attention observing the code being written and offering feedback
*The pilot and navigator will frequently switch roles.
Increased quality is an undeniable outcome to this practice as four eyes are better than two. Additional benefits include knowledge transfer, skill development growth, and cohesiveness of code practices across the Scrum team.
Some organizations frown at this practice because they feel they’re not getting the “bang for their buck” but practice to increase quality and throughput.
Write Clean Code
There’s a lot of information available about how to write clean code, whether that be through using design patterns or a set of principles for object-oriented design like SOLID. Regardless of the approach, emphasis should be placed on writing code for readability and maintainability. Remember to always follow industry standards for naming conventions and practices.
No matter how hard you try to write clean code, refactoring is a reality. Safely refactoring is not something that should be placed in your product backlog. It should be a practice that consistently takes place as developers modify existing parts of the application. Refactor is not a bad word. Developers should always leave code they are touching in better condition than how they found it.
Be conscience of technical debt (the eventual consequence of poor architectural decisions) and tackle issues head-on without delay. Lastly, don’t get yourself into a situation where you’re managing bugs. You want to instead confront them and view them as unacceptable.
Scrum methodology is an incredible evolution in product development, both culturally and from a productivity angle. Whether you’re observing the benefits of a cross-functional Scrum team, the power of DoD, the need for swift feedback loops, or the capacity to which you can improve or add to your practices, one thing is certain: quality sits at the core of impressive projects.
Building the notion of technical excellence into your Agile culture is the only path to becoming a hyper-performing team. Teams without a sense of urgency and focus may develop more quickly in the beginning, but they’ll ultimately drown in technical debt and diminished productivity.