As an agile coach, I am often asked how to evolve teams beyond Scrum and Kanban to improve quality. I recently gave a lightning talk at our booth at the Abstractions conference in Pittsburgh about top technical practices I have seen improve team delivery, including Test Driven Development (TDD), Continuous Integration (CI), and Pair Programming.

Test Driven Development (TDD)
Test Driven Development (TDD) drives quality through a test-first approach. It is a technical practice in which the first step is to write a simple test for a desired function. When run, the test fails as there is no functional code yet written.

Next, just enough code is written to satisfy the tests, and the tests pass. After the tests pass, the code is refactored. Refactoring is changing the internal structure of the code without changing its external behavior. This helps the code stay clean, readable and manageable for others who work on the code in the future.

The steps outlined above are referred to as Red (test fail), Green (test pass), Refactor (clean code). TDD is important and effective because testing and code quality are top of mind. In my previous experience as a developer, I might build a feature and not test until it was complete. When I found any issues, it took longer to go back and fix because now there was a bunch of code, classes and files.

I often hear people say that TDD will slow them down, and when you’re first learning TDD, it might. In the long run, it’s going to not only increase your speed but your quality as well.

Continuous Integration (CI)
Continuous Integration (CI) is the practice of developers integrating their code into a shared repository several times per day. This practice drives quality by eliminating the source of potential conflicts and the pain that comes with trying to fix those conflicts.

A long, long time ago, in a galaxy far, far away, I used to be a developer. Back in those days, we used to integrate our code after several days, and sometimes even weeks. What were we thinking? Well, we certainly weren’t thinking about having better technical practices. When several people had checked out code at different times, we had merge conflicts. It took hours to piece it back together. The task switching, frustration, and lost time was a major setback.

In the discussion at Abstractions, we talked about integrating code as often as possible—even every few minutes can be beneficial. We also talked about the importance of automated testing to complement CI.

Lastly, I used an analogy of Dropbox to highlight the benefits of CI. With Dropbox, you must download a file and then upload your changes, as opposed to versus Google Docs where multiple people can edit a file in real-time.

Pair (and mob) Programming
To conclude, we talked about Pair Programming. Pair Programming is the practice of two developers sitting at one keyboard and one monitor. There is a “driver”, the person whose hands are typing on the keyboard, and a “navigator”, the person guiding the driver.

The navigator may be discussing the goal of the piece of code, offering suggestions, and catching errors before they are introduced. Periodically, the driver and navigator rotate roles to get a different perspective.

At first glance, management may think that Pair Programming is an inefficient use of team time. However, having four eyes on the code increases code quality, readability, maintainability, and introduces less bugs.

Additionally, as team members start to become more familiar with different areas of the code base, there is a greater shared understanding by the development team. Pair Programming is also a great way to build relationships among the team and can be viewed as a form of team-building.

In the session at Abstractions, we also talked about Mob Programming, which is similar to Pair Programming, but it involves more people. It could be the whole team huddled around a desk with a keyboard and the monitor projected onto a large screen. More eyes on the code and more shared learning across the team leads to familiarity with the code and quality output.

This was a brief rundown of some technical practices I discussed at the Pittsburgh Abstractions conference. What technical practices are you and your teams using? How have they helped? What struggles have you seen?