Business agility needs Technical agility

Too often you hear teams that crib – does not work for them. They are getting the same results as waterfall or actually they are worse off than before. When you talk to them and dig deeper, more often it would turn out they are focusing primarily on planning/process improvements – refining their Scrum, Kanban or whatever form of Agile process framework they practice. They are missing the most important facet of Agility – .

These agile teams, more often are producing legacy code. The ability to change code is slow. When you can’t make change to the products fast enough, it does not matter what agile process framework you use. The business results will remain elusive. Agility is about having the ability to respond to change fast. If you dont have the ability to change your software fast enough – faster than what your customer or market expects you to change, you simply cannot have agility.

The creators of SAFe put it very beautifully when they said – you can’t scale crappy code.

True business agility requires technical agility. That is the backbone. Now yes, you could be working in a legacy environment and there could be real challenges. No one is denying that or undermining the complexity involved in achieving technical agility in a legacy ecosystem. However awareness about it is the key. Agility in the planning and the processes is very useful. Simplified and Lean processes are definitely required. So it’s great first step to move to Scrum. Congratulations ! However you cannot stop there. A motivated team that has really simplified the way they work and wants to aim for 2 weeks sprint cannot simply do it if their build processes are not fast enough to give feedback. Imagine you check in code that goes into a big system with millions of lines of code and the feedback to the developer can only come after 4 days since that is the frequency at which you can currently do builds. 2 weeks sprint will frustrate this team. They have the will but until they solve the build challenges, agility is going to be hard.

To truly achieve agility on technical front would require work in several areas

The more obvious one is code maintainability. You code needs to be easy to change. That needs the ability to measure and bring down your technical debt. Frequent refactoring is needed. Refactoring will need to be inherent to the way you write code ( and not as a separate line item on the project plan. Actually for starters, that might not be a bad idea either ). Static analyzers will help in pointing you in the right directions, but that won’t probably be enough as good code essentially also comes from good design. Spaghetti code is more often a reflection of inherent poor design.

Now we must remember here the retrospectives prime directive…

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

So the “sin” is not to write bad code that works functionally, but essentially to never go back and improve it. If you want technical agility, you will need to go back more often to fix and improve things.

Of course to be able to refactor more often, you will need the safety net of automated tests. So that needs space as well on your strategy to achieve technical agility. Refactoring on legacy code will take long and will be hard.

Integration is the key. The frequency and ease with which you can integrate code seamlessly in the larger code base – essentially continuous integration is a good indicator of your technical agility. Achieving continuous integration is your first goal. There are items which are more fundamental like how you model the data and name your classes / methods. If they don’t represent the domain that you are building for, its that much harder to maintain the code. Code readability is a key item. Self documenting code is a strategy often used.

The list is pretty long. Most of them are inter-related and fixing them needs an agile way – small chunks, incrementally and iteratively. In legacy environments, it would be a long journey. Scrum as a process could be implemented in days as a concept (real implementations do take time).  Things like continuous integration would require months and probably years and often investments. There would be many impediments that you need to make your way through – technical and cultural. Patience and persistence are good virtues to have.

Achieving technical agility is a key milestone on your journey to business agility. Business agility needs technical agility. It is not optional and there are no shortcuts.

You may also like

Leave a Reply

Your email address will not be published. Required fields are marked *