Despite conservatism and a general aversion to risk, big money center banks are starting to adopt agile techniques to their software development efforts. The American Banker, a daily trade newspaper and website covering the financial services industry, has identified two of the leaders as JP Morgan Chase, the largest bank in the US by assets and BBVA Compass, the second largest bank in Spain. Why banks that enormous would embrace agile is an interesting story.
Part of the reason is that as banks are creating more of their own customer-facing technology they need to adapt code more quickly to market changes. At the same time, they see some of the deeper benefits of agile as giving them a competitive advantage over smaller banks, especially when challenger banks are emerging to reshape the mobile banking landscape.
Agile has many layers and some of the most productive are just below the surface. By now, most software developers are generally aware of the pattern of agile development – sprints, daily standups, retrospectives, etc. – even when they do not resort to the use of them. But most are not aware that even more powerful concepts lie at the heart of agile.
One of these concepts is to get it done right the first time. Like much agile thought, getting it done right the first time was borrowed from lean manufacturing. How this is applied to software development is described by Jeff Sutherland in his seminal book SCRUM: The Art of Doing Twice the Work in Half the Time.
In his book Sutherland describes a conversation he had with the software development people at Palm. Palm, unlike most companies, had automated testing to the point where they were running tests on development code every day. One of the many things they measured was how long it took developers to fix a bug after it was discovered in both real-time and CPU time.
Everyone makes mistakes, but no one likes to be reminded of them. In consequence, when confronted with a bug the reaction of most developers is not to go back and fix it right away but instead to promise to fix it at a more convenient time. In most companies, testing doesn’t even happen on the same day. It usually takes weeks or even months before all the code is tested and only then are the problems discovered.
Since Palm performed automated tests every day, across code written by hundreds of developers, they could analyze how long it took to fix a bug right away versus fixing it a few weeks later. Sutherland writes about what they discovered at Palm:
“It took 24 times longer. If a bug was addressed in the day it was created, it would take an hour to fix; three weeks later it would take twenty-four hours. It didn’t matter if the bug was big or small, complicated or simple – it always took twenty-four times longer three weeks later.”
This makes sense when you think about how the human mind works. If we fix a problem that has been identified while we are working on the code, we don’t have to recreate the context much later. Evolution has not optimized our minds to remember things after the fact. We can really only concentrate on one thing at a time and once this concentration has been broken, it is hard to recreate it. Twenty-four times as hard to be exact.
In a DevOps environment where developers are expected to maintain the code they write and ship quality code as fast as they can, getting it done right the first time has extra advantages. There is no experience quite like being called urgently in the middle of the night to fix the code. Not only is it disorienting, but it can be hard on relationships. Many DevOps operations would benefit from daily automated testing and fixing bugs as they arise, yet this is a concept even mature agile environments have been slow to adapt.
Getting it done right the first time is the type of thinking that money center banks like JP Morgan Chase and BBVA Compass hope to leverage to give them a competitive advantage in the future. Hosted automating testing platforms, like Bitbar Testing, can make this a quick and secure transition to a new way of developing code agilely.
Learn how to properly adopt DevOps approach for your mobile team and get the most out of it.Download