Serengeti’s team of 10 developers has worked for more than 10 years in the banking sector and has wide domain knowledge about the industry requirements and regulations. All developers have the technical expertise of technologies used in the bank system.
Preparation for the project started more than three months before the beginning of the actual project. We have analysed the system and estimated the amount of work that needed to be done. After that, the necessary size of the team was defined, and it was agreed that it would be necessary to provide 24/7 support for critical products for which we have agreed to provide passive overtime standby.
To prove that our team is ready for a job like this, we have completed a pilot project. It was a medium-sized change request that had an impact on several of the bank's products. This project went smoothly, and after it was implemented, we started to maintain the entire system.
Step by step process
The first part of our job is system maintenance through handling user requests. There are two main types of requests. The first type is called a Service request, and it is usually a request for information about a specific situation or a quick fix of a problem that can be done manually by the user, but it would be time-consuming. Service requests can be categorized as low, medium, or high priority. Our team solves about 90 service requests per month.
The second type of user request is called Incidents, i.e., problems that affect the bank’s business and must be solved quickly. Incidents are categorized on a scale from low to major, with low being the isolated problem that affects only one client and major affecting the whole bank. The latest is very rare but it must be solved in the shortest time possible, regardless of the working hours. We have defined an SLA response and resolution time for all types of incidents. Our team solves about 40 incidents per month.
The second part of our job is development of new functionalities through change requests. For this we use the Waterfall methodology and Microsoft Team Foundation Server to track the status of the request.
At the beginning of the process, in the user requirements definition phase, we work with business users. Our architects, who are business domain experts, consult them and propose the best way to solve a problem. After the completion of the functional specification, we have the presentation meeting between the bank’s business analysts and our developers, after which we start working on high-level estimation.
When the estimation is done, business unit that requested the change must decide if we should do the request or not. If we get the confirmation, the phase of detailed estimation and writing of technical specifications follows.
When the technical specification is done, we present it to business analysts and the business unit that created the request, to ensure we understood each other correctly. The development phase follows, and after the development is done, we do factory testing on provided test cases. If needed, we can add more test cases. In the user testing phase, we provide support to the testers and solve defects in the shortest possible time. Deployment is done through custom deployment software that the bank uses. We have monthly releases, but it is possible to schedule additional releases if needed.
After the stabilization period, maintenance is done through service requests and incidents.
Handling unforeseen circumstances with Shadow Developers
What happens when everything is not going according to the plan? In April 2020, the national bank, in response to the COVID lockdown, mandated several rules which had to be implemented very quickly to the core banking system. Deadline was very short which meant we had to ignore waterfall SDLC and work agile, directly with business users. There was no functional or technical specification before the development we wrote those documents after the job have been done. Testing was done directly with business users because there was no time for factory testing. In the end, we have managed to implement all the changes in time.
However, it would not have been possible to do this with just our core team of 10 developers. While defining the team for this project, we have anticipated that circumstances like this might arise, so we have formed a team of 10 developers with additional 3 shadow developers who were in standby mode from the beginning of the project. They were junior developers who sat with our seniors who worked on the project and learned from them. When the COVID crisis came, they were ready to help with real tasks, so we have easily expanded our team.