Continuous attention to technical excellence and good design enhances agility.
Agile is all about uncovering better ways to develop software and the Agile Manifesto makes some clear value propositions:
- We value individuals and interactions over process and tools;
- We value working software over comprehensive documentation;
- We value customer collaboration over contract negotiation, and;
- We value responding to change over following a plan.
A key element of the manifesto, however, is that there is value in process and tools, documentation, contract negotiation, and following a plan, just a lesser value than the values on the left side of each of those proposition statements.
When we step into developing some kind of software – or even broader engineering efforts – it’s very easy to take this approach of let’s just break down the work we need to do, let’s find out what the next step is, and just tackle that. Here, you’re following the basic idea of responding to change and delivering working software. If throughout this approach, however, you forget to pay attention to technical excellence and good design, you’re probably setting your team up for failure down the road.
We have to think about design, and we have to think about what is technically correct, and what is actually going to save us effort in the future. If we don’t think of some of that up front, and if we don’t continuously think about technical excellence and good design through a process of reflection and improvement, we’re going to lock ourselves into corners with tons of re-work.
Since we should value responding to change over following a plan, we will never reach a place where we are giving 100% continuous attention to technical excellence and good design, nor should we. Iif our focus is always on technical excellence, good design, and planning ahead, we’re never going to get anything done.
Of course, teams do fall into this trap of overplanning. On one project I worked on, there’s an app that’s been in development for more than eight years and all of a sudden every single decision to try and improve the product requires the entire engineering department to agree to it because nothing is owned by any smaller team. The entire team needs to stop what we’re doing to agree to a plan, even for small changes.
When iteratively delivering high-quality, working software through experimentation, reflection, and continuous improvement starts to take a backseat to getting entire engineering teams together to approve making improvements to your software, that’s a huge sign that your architecture and design has slipped away from you.
Fortunately, if you fall into this dilemma, there are some steps you can take to get back on track. First, think about where you would be with your product if you could plan everything up front with no constraints. Then, once you know where you are and where you’re trying to go, break that down into smaller chunks of manageable work. This will allow you to start delivering working software now, while also keeping in mind the overall scope of what you’re working towards. By keeping in mind your future goals, you will take steps now through technical excellence and good design that will save you time and heartache in the future.
I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.
