Closely linked to part three of our series on how to practically implement Agile by delivering often, this is part four, Technical Excellence. For this post, we’ve asked Nick McKenna, the CEO of McKenna Consultants to explain more.
We Pride Ourselves on Technical Excellence
McKenna Agile Consultants was born through practicing what we teach through the software development side of our business, McKenna Consultants. McKenna Consultants improve our clients’ businesses through the appropriate use of digital technology, assisting companies across various industries for 15 years and developing their digital systems. Our digital innovations have enabled our clients to become more competitive and more adaptable in a dynamic environment.
Tips to Achieve Technical Excellence
Test, test, and test some more
If you don’t have more test code than production code, you aren’t trying hard enough. You’ll never have enough money or time to do all the testing you want to do. You just have to choose what is important for your software. You could do unit, integration, security, UX, UI, simulations, exploratory, alpha, beta, performance, load, soak and many more.
In the modern world, everyone is a tester, and so computer programmers have become more adept at automating the testing process with all manner of tools. Once you start generating large numbers of automated tests, you’ll need to run them often to catch problems as early as possible. Once you jump on the testaholic bandwagon, you should see fewer problems cropping up in production.
Integrate early and often
Even in the 21st century, integration is often left until the last minute, and it far too often still focuses on teams exchanging Word documents. This transactional model of integration fails because it over-simplifies the problem with different parties to the integration making conflicting assumptions.
Instead, make integration the first task on your backlog. Work out all the problems and eliminate the integration dead ends before you write lots of code based on flawed assumptions.
Deploy to production early and often
Building on our tip on integrating early and often, get your code out to production early and often. You can even ship incomplete features if you implement a simple toggling system – the benefit here is that you’ll shake out any incompatibilities and integration problems nice and early.
Production environments are frequently subtly different from dev and test environments. Just because it works on the test system doesn’t mean it will work in production!
Automate as much of your workflow as possible
In software development, we should never do the same thing twice. If you have a manual process for deployment, integration, programming etc, get it automated. It will smooth out your workflow and reduce stupid errors. This means you’ll be able to get your work done quicker and more reliably without sacrificing quality.
Read the documentation
But wait! The Agile Manifesto says that documentation isn’t important, right?! Well firstly, that’s not what it says, it is a common misconception.
What we’re talking about here is documentation written about the software you are using where you don’t have a direct line to the author. More and more, computer programming is about utilising and connecting third party APIs.
Reading the documentation beforehand is a great step to success. There may be Wiki pages, readme files, code samples, Postman collections and other artefacts that will all save you time later if you read them before you start hacking out code.
What’s Next?
Before summarising and bringing our Being Agile in Practice blog series to a conclusion, we have one more element of practical Agile coaching to discuss – Part 5 – Speed to Decision.
Previous posts in this series focused on healthy backlogs, stable teams, and delivering often. Make sure you go back and read those if you missed them.
