It is not just Agile as values and principles that made into the mainstream with all sorts of product teams and even non-product folks such as marketing and communications. With Agile starting from the world of software development, it is unsurprising that so many of the techniques and tools we use still today started there as well.
Of course we know how the Scrum framework has reached wide acceptance among the masses. And how Kanban boards are widely used in all sorts of projects, including personal projects.
But this post is dedicated to shedding some light on Agile techniques that go beyond software development, and that I believe should be adopted more widely. I have particularly used most of these as a software developer and coached teams outside of software development on how to benefit from them.
These 3 techniques I chose are heavily used in XP (eXtreme Programming) and therefore have been tested and evolved for many years in all sorts of complex product development.
TDD
That acronym stands for Test Driven Development. A lot is said in Lean and In Agile about bringing quality to the forefront, quality is not an afterthought, etc. Yet, most testing is conducted at the end of a development cycle.
What TDD proposes is that we test beforehand. Testing before things are even done.
Bear with me. While it might seem wild, it is actually a very sensible idea. We should be considering what are the functionalities or pieces of the product we do intended for. What is not in scope? How many characters are accepted? What range of colors is displayed? Can you click that button many times? How slow is too slow? Through all of this, we are creating the requirements as we design and code. So the tests are the requirements.
You are defining the boundaries, you are defining the quality to be accepted. If this is code, you code the tests first and then create code to pass the test. If this is a book, maybe you create the shell of the most important chapters first, with subsections next (as in developing for interfaces, from Object-Oriented Programming).
And the beauty in TDD is how flexible it is. If colors and visuals are more important, you start defining those for your product and testing. Testing can happen via machine or it can happen via showing prototypes and sketches to people and capturing their insights.
You are still testing more at the end, but you started from quality first.
While there is more technicality to be considered if you are adopting TDD for software (when and how to code those tests, for example), I hope at least in the concept you can transpose it to any type of team. Start anything from the user perspective first and work backwards to satisfy that perspective.
Pair programming
It is literally about two people creating code in pairs. As the technique got adopted outside of software, the name Pairing became more largely used. In Pairing both people work on an item, on an activity, a task, 100% together.
Pairing is the ultimate exercise of “two heads are better than one”. You are getting more ideas at once. You are adding quality because the pair is critiquing each other’s ideas as they experiment with them. It is a great review-in-the-moment technique. Makes not only for more quality, but for more efficiency in the end. It definitely beats the “I do now, you review later”.
Not only that, Pairing is twins with the idea in XP that the ownership of the product being developed (code, back then) is collective. The whole team owns it. Therefore, it is everybody’s fault and everybody’s glory. Everybody is invested and pitches for improvements. It’s not the first idea in the head of a lonely person working late on a Friday night that wins. Pairing invokes collaboration and negotiation from the two parties. That is very conducive to better results.
Take the next complex activity that needs doing in your team, and do it in pairs. I am sure that all the disagreements and awkwardness of the beginning will be a huge payoff in the end for the product.
Refactoring
While not invented in XP, it was definitely a rule of thumb in XP. Refactor often. Refactor is not rework; it is a necessary element and a technical implementation of continuous improvement.
Refactoring is constantly (re)assessing design, performance gaps between today and the desired state. You leave the visible parts intact, interfaces untouched, and improve the hidden pieces, where there is logic or the ugly elements the customer doesn’t see. Improve the system without disturbing the service to the customer.
While it is about iterative development, it is not about adding bells and whistles. Refactoring is about the structural elements of the product. You know, when Uber started they probably designed their database for a certain number of users. From thousands to millions you have to adjust infrastructure. From millions to tens of millions as well. Adding a map and saving trips after the first release all required revisiting what the internals of the product looked like. So you add the new stuff without breaking what is already present in the product.
Factor in the changes in your product. Factor in new customer habits and how that might change things internally for you. When Zappos started they were buying the shoes in person and shipping them to their customers. Eventually, they were sourcing those shoes automatically. The interface for the user? It stayed the same, at least for that time.
You can steal the idea, no need to be original. Maybe you service a team in your organization and the behind-the-scenes is manual and you want to switch to some automation. Or maybe you remain manual but you improve your internal process steps. If you do it continuously, you are constantly refactoring.
In conclusion
Agile is continuously evolving, including technical Agility. And the practices that work on code sometimes can work outside of that space because they are about quality, collaboration and iterations. Keep your curiosity high and your mind open!
Have you been using techniques and frameworks that you know comes from technical software agility… with a twist? If you have not, what are you excited to try?
