Scrum is the most popular agile framework, and part of what I like about Scrum is that it is elegant in its simplicity and does a great job of making things visible. And after years of seeing Scrum implemented in various organizations and talking to others in the industry, it’s clear that technical excellence is too often neglected by Scrum teams. As an Agile/Scrum Coach, I think it’s important to talk to teams and managers about more than what Scrum alone defines–we must have conversations about other practices and ideas to address the stuff that Scrum has made visible. Technical practices must be in those conversations, regardless of our own technical backgrounds.
It seems like teams can create technical debt faster in agile than they did previously if they are not following good technical practices. Practices that ensure we are building the code right so it is “rigid in the right places and flexible in the right places.” This is important because successful software may suffer from performance punishment: it did well, so now it needs to do more. Which means that the initial benefits provided by Scrum can come to a screeching halt months or years later if teams are not continuously focused on technical excellence. If Agile is about “embracing change,” then an Agile codebase needs to be able to “embrace change.”
Our July Dallas meetup was titled, “Technical Excellence Doesn’t Just Happen-Igniting Craftsmanship Culture.” Mike Rieser and I co-presented our experiences with Flaccid Scrum and shared how we partnered as coaches to help an organization through a technical turnaround with some tips for others who need to do the same. In our experience working with multiple teams in a single codebase, developers can feel victim to a legacy codebase if only a few people are writing clean code or refactoring; guiding them on how to decrease technical debt while delivering their projects helps “unstuck” their other agile practices. If you’re interested in learning more, tweet Allison or Mike.