This article is the third part of a four-part series titled How to keep your systems running, reduce risk, and enable growth post-Covid-19. Recent events have caused a change in Financial Markets Technology risks and our mini-series will help you rebalance your budgets to:
- Ensure the integrity of your current services in these unique circumstances
- Simplify and reduce risks as well as medium-term costs
- Develop new products and services to enable growth in line with the new budgeting techniques
New products and services must be built
A new means of budgeting needs to meet the requirement to provide new products and services at a lower cost, shorter timeframes and with the ability to change requirements at short notice whilst the project is in flight. This seems all but impossible, however, the technique already exists and is being deployed by several banks.
Traditional change budgets have focused on projects with defined functionality and timelines. This is easy to measure and therefore calculate returns. However, it offers limited and costly adaptation. The measure of an institution’s IT capability is no longer time and cost to deployment but rather the full profit and loss of the business. It is the client outcome that is important, not the method and style of individual projects. This is respected when we look at digital transformation in all its forms, but in particular with agile-based deliveries. How do these work?
Agile methods are not based on business requirement documents, defined build times, and testing before production. Rather they are based on user stories, squads, sprints, and constant deployment of valuable changes into production as soon as they become available. What does all that mean?
Rather than a business requirements document written by a business analyst, reviewed by several people, and then signed off for development, a user story is a brief description of what feature a user wants and why. They are more like a conversation and in fact, can be written by users themselves or their managers. This “just enough” approach provides a very simple way to describe smaller pieces of functionality that will add value. Over time the many user stories written will turn into a substantial system.
A project manager, two business analysts, eight programmers, an architect, testing staff, and quality assurance people are all needed for projects, right? No longer, not with agile. Instead of large teams of this nature, agile methods use squads which are rounded in nature. They will always include a business-focused person called the Product Owner and can be typically between five and twelve people depending on the size of the work they are to undertake. Several quads are deployed in the same organization and using agile methods with microservices on the cloud they can develop multiple parts of the same system without conflicting with each other. A squad receives a user story and is responsible for deploying that story into production. Their combined skill set provides all that is needed for the delivery. Indeed they will constantly receive and deploy new stories as they are written.
Sprints are exactly what they seem. Short bursts of development, usually in about 2-week cycles, where squads deliver user stories into production. How many stories is set as a target at the beginning of the sprint. However, things may change and it is fully permissible to allow some stories to be delayed to the next sprint or indeed to permit a new story into a sprint whilst it is in flight. The important thing with sprints is to respect the duration of the sprint for the squad but allow the functionality to be flexible. This all but eliminates costly change control and allows the organization to adapt very quickly to changing circumstances.
Constant Deployment can be achieved using the DevOps method of continual integration and continual deployment. This paper will not enter into the technicalities except to say that such a method ensures the organization gets the very earliest possible benefit from technology builds. Ensuring a rapid rate of return for technology spend will be essential in the new world.
From a budgeting perspective this means that budgets should NOT be set for projects, in particular as these are now likely to change in priority and dimension in a short timeframe. Budgets should be set for squads with an organization considering how many squads it believes it should fund for the financial year. For a large bank this could be as many as 200 – 300 of 6 – 10 people each. Other organizations will scale accordingly. The CIO will be held accountable for ensuring he has a process for the appropriate approval of user-stories at a rate and quality sufficient to keep the squads fully occupied for the year.
This mini-series was taken from a paper written by our CEO, Terry Boyland. To read the entire paper, click this link.