Category Whitepapers and Guides
[vc_row][vc_column width=”1/1″][vc_column_text]In banking technology, many teams are using ‘Agile’ to get releases out to business quickly. Most Agile projects start small scale but, as experience & confidence are gained, (successful experiences in more online sides of the bank) it becomes the more mainstream mechanism.
Business sponsors engage iterative delivery & release far better from the project definition, throughout implementation to ongoing BAU. A downside is that it’s hard to say “no” to ad hoc changes and enhancements mid-Sprint as they come to mind of the business sponsors. This can cause re-prioritisation or the build-up of technical debt.
Has it always worked? No, but no project is guaranteed success, not to mention that definitions of success can be ambiguous! Including Test Automaton as a key part of ‘definition of done’ adds a lot of clarity in decisions on platform risk and ‘go live’ (as well as confidence building with each sprint).
Are robust project Agile controls always seen? Less so I’d say. ‘Heroes’ still save the day working overnight in the financial districts. Programmes with robust checks do really mitigate that situation.
The move to Agile delivery is not always synonymous with ‘baking-in’ quality from Sprint planning onwards. Again, culture change needs to evolve here.
The ultimate value of test automation derived from BDD is still in its infancy. It can be deemed as ‘not possible for us’ by those unaware of how BDD translates into test assets, and how under the UI technical testing gives a solid base for speedy delivery. Without across the board buy-in this can get tricky to deliver.
Many banks remain embedded with overly expensive, less Agile-aligned test automation tools that critically are not used by developers themselves. So, the ability to integrate development and test automation is at odds from the start.
The move to open source test automation tools has grown significantly, mostly due to the major license cost savings and highly mature capabilities on offer now. Just putting that first automated test into the CI is a key step that seems to get the ball rolling.
Certainly the move towards CI with predictable quality (and speedy business delivery) is reliant on technical testers and developers having interchangeable skills, using the aligned tools and fully respecting each other’s technical value.
The holy grail of ‘one team delivery’ is an evolution of experiences that raises the bar collectively. All that is required is an open mind.[/vc_column_text][/vc_column][/vc_row]