How Does Code Refactoring Come into Play with Agile?

Learn how code refactoring impacts your agile journey.

It’s a scenario I see frequently in my travels as a consultant. After years of struggles with deadline and budget, a company or enterprise program decides to “go” agile. They then undertake something usually called an agile transformation.

To understand what happens next, we have to differentiate between theory and practice. In theory, the organization hires consultants and staff to shepherd all people involved toward a new way of doing something. These people then coach, train, and lead by example. Slowly but surely, with improved project management, the enterprise achieves predictability in their efforts. Then they start hitting deadlines and delivering on budget. So goes the plan, anyway.

In practice, things tend to go less smoothly. In fact, things often get downright rocky. Experts come in, coach, and certify staff. But it confuses the rank and file people who often don’t understand the point of the exercises. To them, it just seems like a different set of meetings and a different venue for organizational politics. Resentment builds. Then the organization divides itself subconsciously into two camps: traditionalists and agile adopters.

While the personnel go this route, the projects lumber along as they always do. The organization continues to miss deadlines and deliver behind schedule. Then leadership feels mystified. What went wrong?

What Is Agile, Anyway?

I’ll get to what probably went wrong in a moment. But before I do that, let’s take a brief tour through the history of agile software development.

Back during the pre-agile 1990s, software development was growing perpetually more complex. The traditional method of building software involved treating it like building construction. You plan extensively up front, go into a protracted “build” phase, integrate everything at the end, and then have a ribbon cutting ceremony on shipping day. People generally refer to this practice as the waterfall approach. And with the rise in complexity of software, this approach succeeded less and less frequently.

Concomitantly, a group of seasoned and talented consultants was experimenting with alternative methodologies. In 2001, some of these folks got together and created the Manifesto for Agile Software Development (often called the “Agile Manifesto” now). This laid the foundation for the agile software movement.

Sixteen years later, the movement has coalesced around one particular agile methodology. But many people don’t realize it wasn’t always so. In fact, the manifesto’s signatories had a variety of approaches that shared common principles.

Now, if you’ve seen things like the agile landscape map, you might object to my categorization that one methodology carried the day. What about SAFe, LeSS, and the like? Well, I’d argue that all of those build on the single methodological approach of Scrum. They just scale it to the enterprise.

Scrum and the Resolution of Our Mystery

Today, in 2017, when an organization declares that it’s “going agile,” you can safely assume that it will adopt Scrum. It’s going to start having 2(ish) week “sprints” and daily stand up meetings. It will kick sprints off with planning meetings, and it will end them with demos and retrospectives. The team will assign the roles product owner, Scrum master, and team member. This is Scrum, and Scrum is synonymous with agile now.

If you go read the Scrum guide, you’ll find a document that suggests team workflows and interactions. It defines roles, protocols and the rules of engagement. And it leads with the values that undergird these suggestions. But it really only speaks to project management concerns.

And that brings us to where enterprises stumble out of the gate with their adoption.

They assign different roles to people and they have different meetings. But in terms of their actual approach to the software, they don’t realize they should start doing things differently. They don’t recognize that becoming an agile shop requires a different approach to project management but also a different approach to the architecture and the code itself.

This happens so commonly and predictably that manifesto signatory Martin Fowler gave it a cheeky name.

Remember the Agile Practices

We can look to another, too-often-forgotten methodology for answers. Where Scrum speaks mainly to processes and protocols, eXtreme Programming (XP) speaks directly about technical practice. In fact, it lays out some very clear rules. For instance:

• Code the unit test first (TDD)
• Pair program.
• Setup a dedicated integration computer (build machine).
• Run acceptance tests often.
• Refactor whenever and wherever possible.

If you’re thinking that XP and Scrum sound perfectly compatible, you’re right. They work so well together that agile software development shops often adopt both simultaneously. But this is unfortunately counterintuitive. One naturally assumes that, since they’re both methodologies, you would pick one or the other.

And so organizations pick Scrum (or its more enterprise-y cousins, like SAFe), causing them to forget about the practices.

Agile Process, Agile Software

Agile methodologies demand fast feedback loops. With waterfall projects, you plan extensively, build extensively, and deliver all at once, in a big bang at the end. With agile projects, you actually deliver a slice of the eventual finished product every two weeks or so. This has the advantage of getting you in front of users early so that you can incorporate their feedback as you go. To understand the value of that, think of how many times you’ve seen something delivered according to spec, but that doesn’t thrill its prospective users. “Sure, I guess that’s right, but it looks… different… than I thought.”

When you build in a waterfall paradigm, you have certain leeway. For example, you can focus on code, leaving integration for the end. And, since you theoretically have the entire spec up front, you don’t have to plan for change.

With the agile promise, those luxuries go away. You need a sophisticated enough delivery pipeline to ship every couple of weeks. You have to integrate constantly. And, most importantly of all, you have to bet on your “spec” changing constantly with user feedback.

Adherence to an agile process requires you to construct agile software. And that is what generally sticks in the craw of enterprises adopting only the project management aspects of Scrum. The project slows to a crawl over time because they still build things the waterfall way.

Code Refactoring for the Win

This brings me to conclude by answering the question posed in the title. When listing the XP practices, did you note that I italicized the refactoring edict? I didn’t do that by accident.

Code Refactoring is a practice where you alter the internal structure of software without changing its behavior. In other words, refactoring focuses exclusively on getting the code into a desirable state for the development team. And I would argue that this is the single most important technical practice for having success with an agile adoption.

Why? Well, left to its own devices, software rots as it grows. It gets more complex, harder to understand, harder to maintain, and harder to change. Refactoring offers the antidote to this poison. As the software evolves, refactoring lets you modify it constantly in response to inevitable change. This is the only way that you can continue to deliver software at the same blistering pace as your codebase grows and changes.

In the end, I’d strongly encourage any company to adopt an agile methodology and an agile mindset. But you can’t just have different meetings and expect better results. You need to build flexible, adaptable software. And to do that, you need code refactoring on a constant basis.