Agile Development: Focusing on the Health of Your Code

I often find that during an agile transformation, managers measure the wrong things and therefore don't see where the greatest productivity boosts could be. They try to measure team productivity or individual productivity without really understanding what that means.

What good is it if your team rapidly writes a lot of buggy code that isn't discovered until much later? Or if they write code with a lot of technical debt that prevents the system from being extended in the future? In most other aspects of our lives, we understand the trade-offs between short-term gains and long-term impediments. We eat well and exercise in order to have energy to do the things we want to do, and so on. But we rarely apply the same scrutiny to our work.

Many Scrum teams focus on velocity as a measure of productivity, but this is a poor proxy. Velocity can easily be gamed by doing things quick and dirty, which can cause a project to grind to a halt once too much technical debt has built up. I've seen many Scrum teams experience severe drops in velocity in their fourth or fifth year due to the technical debt they've accumulated.

Colleges don’t teach their students how to write software in an iterative process or how to build code that’s easily extendable. The agile movement has discovered many of these practices, but just because someone calls themselves a programmer doesn't necessarily mean they understand these practices. And in my experience, very few developers actually focus on writing maintainable code.

Being an agile software developer requires special skills that have to be studied and learned. Simply knowing the technology or a set of frameworks does not make you an agile developer. There are many principles and practices that must be understood, but since they’re not common knowledge in the industry, learning them can be challenging.

Scrum is a framework for organizing software development, not for actually doing it. Scrum helps you break down tasks, write stories, and plan development, but for actually doing development, it has always deferred to other methodologies, usually to Extreme Programming (XP).

On the back cover of the book Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, the last two sentences of the description say, “This book shows readers how to use Scrum, an agile software development process, to quickly and seamlessly implement XP in their shop—while still producing actual software. Using Scrum and the agile process can virtually eliminate all downtime during an XP implementation.”

Clearly, according to the authors who popularized Scrum, they felt it was to be used to help you get more from XP—but somehow, we forgot that part. I’ve spoken at several conferences and Scrum Gatherings where everyone is doing Scrum, but when I ask how many teams are doing any of the XP practices, nearly all the hands go down. And there are always several people who have never even heard of it.

In my experience, less than 10 percent of all Scrum teams practice test-driven development, pair programming, or other XP practices. And still fewer are doing these practices well. These concepts aren’t easy, but software development itself isn’t easy, either. Software development is complex, and we must find ways to make it simpler.

Extreme Programming does include the technical practices, but many Scrum teams haven't yet realized they need these practices as well. In essence, they believe that all they need to do is follow the Scrum process and they’ll get good software, but reality does not prove that to be true. Adopting Scrum without also adopting technical practices can be a recipe for disaster. It almost guarantees that the code produced will contain a high amount of technical debt.

In Scrum, there are two main forces that drive development: the product owner and the ScrumMaster. The product owner is all about getting more features: “Gimme, gimme, gimme.” The ScrumMaster is all about the health of the team: “Sorry, PO, we'd love to deliver those additional features, but the team also has to eat and sleep, and no, they will not work overtime three days in a row.”

These two forces are supposed to drive sustainable development, but the problem is there's a third force missing in the formula: the health of the code itself. We often forget that our code is also a member of our team, and we have to be concerned about its health and well-being as much as any other team member.

With the constant pressure to work, work, work from the product owner and to do it sustainably from the ScrumMaster, we often end up in situations where we make compromises to the code and its quality in order to get something out the door. This is bad.

Many teams discover that their technical debt is a real issue and requires a huge effort to resolve. Unfortunately, they typically learn this far into development when they’ve accumulated so much technical debt that it’s hard to get anything done, and by they it’s too late for quick fixes. They have to put a concerted effort into cleaning up their legacy code and paying back some of their technical debt before they can get anything else done. How can we avoid this?

The answer is simple. Just introduce the technical practices to teams early. Scrum says that you should have a trained ScrumMaster and product owner on every team, but the team itself needs training as well on how to use these technical practices for building valuable software.

When I say that teams need training, I don't necessarily mean taking a class. There are great books on the subject, lots of websites out there, conferences, and other sources of information, and we have to draw on them all. Software development is a new discipline, and we're constantly learning better ways to do it. We just have to keep up with what our industry is learning.