There is No Agility Without Technical Agility

"Continuous attention to technical excellence and good design enhances agility" – the ninth principle from the Agile Manifesto.

Had you asked me two months ago what is the main benefit of technical agility, I would have talked about understanding how today’s decisions impacted yesterday’s deliverables; I now realize it is much deeper than that. Technical agility enables us to respond to any type of change, be it how we work together, the systems we work on, or the outcomes we desire. Given how much of a capstone I feel this principle is, I think it warrants a deeper look into its meaning.

Continuous Attention

Have you ever gotten home from work, pulled into the driveway and think to yourself that you didn’t even remember driving? That is called pattern recognition, and our brains are wired for it. We take some new stimuli and look into our memory bank for an expected outcome. For example, when I drive south in afternoon rush hour traffic, I end up at home. There are other things we do everyday that draw our attention away from our objectives and we don’t even realize it. A fair amount of us are guilty of context switching just so we can show progress on several important items. Of course, the monotony of being singularly focused can drive you mad, so it is about finding the right balance. Take advantage of Work in Progress (WIP) limits to help force you to focus, and if you do find yourself distracted, step away from your desk and walk around the building or block.

to Technical Excellence

These two words have been the driver of their own agile frameworks with specific practices, while other frameworks don’t have any practices designed to address this. But make no mistake, it is our responsibility as professional software teams to address this need. Technical excellence is defined by our ability to deliver high-quality software faster, and this has nothing to do with knowing the difference between a method, function or class. Your preference for Camel, Snake, Pascal or architectural patterns doesn’t drive excellence, we are talking about craftsmanship! When I think of technical excellence, there are two things that come to mind. Clean code that is easy to read; after all, we spend far more time reading other people's code than we do writing our own. Second is a test-first mindset, whether it is TDD, BDD or just a good conversation between tester, developer and requestor.

and Good Design

If technical excellence is driven by a personal desire to be a craftsman, then good design is where we take advantage of all that experience. Understanding how to refactor code is important, but identifying which code needs to be refactored is critical. We can talk about emerging design all we want, but if we don’t architect a solution with flexibility and extensibility in mind, we are still forced to solve for all problems when we build it for the first time.

Enhances Agility

I don’t know if I agree 100% with this last statement. As I wrote and reread the previous three parts of this principle, I have come to realize that technical excellence and good design doesn’t just enhance our agility, they enable it. It is through this intentionality that we grow as a team. It is the attention to detail that allows us to embrace change and not fear it. After all, agility is the long-term consequence of delivering software with the highest possible quality!

Most new agile organizations gravitate towards Scrum, but Scrum is a framework that doesn’t have any explicit practices to drive our technical excellence. I don’t usually preach about best practices, but there are some that the most successful teams I have worked with adopt.

SMART Tasks

SMART is an acronym that stands for Specific, Measurable, Achievable, Relevant and Time-boxed. If you’re a team that tasks stories, then the tasks should represent the implementation plan required to deliver the outcome requested. Getting specific drives inclusivity and helps us progress as a team. Through the exercise of tasking, we can identify areas where we can swarm or attack the problem in parallel, and because they are time-boxed, we can easily identify a teammate struggling. Just as important, with small specific tasks, we get to do code reviews on smaller units of work, we have quicker feedback loops and ultimately have higher quality.

Test First

When working with new teams, I think of a Shu, Ha, Ri hierarchy. I wouldn’t expect a team to start out with writing unit tests before any code, but rather think of writing acceptance criteria to support Gherkin (Given-When-Then). Commit to writing unit tests (Before or After) for all new code and any defects that get fixed, then drive the scope of each individual story down and ensure tests are written before code. Ultimately, we wouldn’t want to deliver a story without a failing acceptance test, and we wouldn’t want to do a task without a failing unit test.

Pair Programming

Pair programming is another area where the idea of Shu, Ha, Ri fits well. Pair programming at its highest level is akin to a Rally car with the pilot and navigator. But to get to that level of trust, we must grow a little together. Use Peer Programming as an opportunity to do real-time knowledge transfer, then treat it as the code review and point out concerning patterns as they are created. Get the size of the tasks smaller and challenge the driver to solve problems faster knowing the navigator is there to protect them from catastrophic decisions. Before you know it, you will realize the benefits.

Code Clinics

A code clinic is an item that could extend beyond the team, but the idea is to formalize a time for developers and testers to bring code in front of a larger audience looking for guidance and feedback. This in turn expands our understanding of our best practices and offers more seasoned developers a chance to explore their leadership capabilities.

As with most things, I think you will find a bit of a J-curve when you try to implement some of these ideas, and that should be expected. The payoff comes when these activities become part of our culture, our DNA as an organization, and when the next opportunity comes to pivot on a dime, you will reap the rewards you have sown.