I’ve focused the past few posts on how we dealt with a major obstacle this sprint, writing about how Agile processes helped us both to catch the problem and to address it successfully.  We’ve reworked our approach to the feature set and are now back to making good progress on development.  But this issue isn’t the only thing we’ve been paying attention to this week.  Our scrum team multitasks, and here I want to share some of what we’ve been doing in another part of our sprint.

One of the core principles of Agile is this: “Continuous attention to technical excellence and good design enhances agility.”  Our company has an entire team of folks focused on the good design and technical excellence of our underlying architecture (not to mention the fact that all of our coders and testers view maintaining and enhancing an excellent codebase as one of their main responsibilities).  As a company we strive for an intentional balance between the development of new products and features on the one hand and the maintenance and improvement of our existing code on the other.  I’ve talked about this in earlier blog posts and plan to write more about it at some point in the future because I think it is such a crucial part of why Agile works so well for us.  Each sprint team works closely with one member of this architecture team – both to make sure that on-going development adheres to our commitment to technical excellence and to look for ways to improve the evolving code of our existing applications.

Some people might think that an Agile approach – in which a team is frequently releasing new fixes and features and constantly open to reprioritizing what aspects of a product get worked on when – might lead to a messy code base with random elements bolted on and inefficiently changed to address newly discovered needs.  My experience is quite the opposite.  Our team pays close attention to the quality of the code behind our product.  We use the best techniques and technologies we know of the first time we build something.  But we routinely reexamine our existing code – especially when we are adding new features – to see if there are more streamlined ways to accomplish the original goals.  As a team and as a company we are committed to excellence in the design of our code and our wider architecture, and this pays off in clear ways for us.

First of all this gives us a generally cleaner code base, with less technical debt piling up that might come back to haunt us in the future.  Second it tends to make our applications faster because we focus on finding the best infrastructure beneath our visible features. Third, our commitment to technical and design excellence allows us to take advantage of new (and new to us) technologies that our inquisitive developers discover in their continual search for best practices. On top of all this, I also think it provides a more enjoyable work environment for our development team, knowing that excellence is truly valued and that their endeavors to streamline our codebase will be appreciated even when they aren’t easily visible. This shows in the ways the development team blogs about what they are learning, shares new insights with colleagues over lunches, and enthusiastically explores new ideas during our regular innovation weeks (which I intend to blog about myself at some point soon).

This sprint, even as part of our team has been reworking our approach to one of the core features we are creating, other members of the team have been diligently refactoring older pieces of code to make them more efficient, implementing better approaches to data management and service calls, and introducing processing techniques and web rendering approaches that will dramatically speed up our product.  A lot of this work happens below the surface and doesn’t directly translate into getting new features into the hands of clients.  But this invaluable effort makes everything else we do much stronger and more stable.  From my perspective, attending to these less obvious improvements provides incredible value to our product and those who will use it.  In the rush to release more and more features to an eager market it might seem like investing heavily in these codebase improvements should wait until we have the luxury of catching our breath.  Of course in truth it’s not that simple.