Use case - LBG
In 2017, as technical lead, I took over a troubled project at Lloyd’s Banking Group Digital twelve months into development.
During the introduction meeting with the project director, she described it as “the race we must win, despite our wheels falling off”. We had to deliver 35 new digital products in 12 months. They were already a year into the project. There was a lot of business analysis and architecture work, but everyone was worried about the technical debt. Three teams of developers were hard at work, but they had yet to show even an MVP of a single working product in the integrated environment. Stakeholders were getting nervous, and time was running out. To complicate things further, an outsourced team in India was writing the back-end code, and Lloyd’s was in the middle of switching outsourcing companies.
I talked to every team member with pen and paper in my hands. I asked them a single question: in their opinion, what didn’t work, and how could it be improved? I found out the primary reasons why the project wasn’t moving forward. I got the green light from the program director and set out to fix them.
Establish the proper CI/CD processes
There was no development server. A significant amount of code was piling up on the front and back end, but nobody ever saw them work together. Setting up the development server became my major priority. We faced a mountain of defects once it was up and running, but we could start fixing them now. The testing team was now hard at work, and the ticketing system came alive.
Create clear lines of communication
I quickly became aware of the complexity of Lloyd’s development and deployment processes. It is a vast organisation. Digital security and stability are a must, so the complexity of the operations was a natural by-product. I knew that if we were to develop and deliver a project of this size in an agile and rapid manner, I had to establish clear lines of communication across all the departments. I walked many miles between various buildings in the City of London, introducing myself, explaining what we were doing, and establishing personal relationships with people that would be instrumental to our success.
Right people in the right place
Front end code was in React JS. There was a team of five onshore developers working on it. During the regular code review, I realised that an alpha male developer was an unelected team leader. His confidence knew no bounds, without any practical foundation. His code was late and chaotic, and he had no idea what other team members were doing. At the other end of the office, in his corner, always deep in thought, sat a shy developer whose code was brilliant. We rarely heard his voice, but he would regularly develop good designs and more straightforward solutions. After consultations with him and with the program director, I promoted him to the head of the front-end team and moved the alpha developer to the other end of the office. Front end code started sparkling. After a while, no code review was necessary.
The source of truth
You should always face the most complex problems first. Create a simple prototype that will unmask the size of the complexity and allow you to solve it gradually. There was one product that everyone was afraid we wouldn’t be able to deliver. Business analysts individualised over 120 different screens that depended on user choice. All teams had to be perfectly synchronised to deliver it quickly and effectively. We needed a single source of truth, something everyone could use as a reference.
In lengthy consultations with the technical architects, I realised it had to be the data structure. We had to come up with the broadest possible data structure that would accommodate all the data provided by the users, depending on their choice. Once we created the proper JSON structure and made it readily available to every single developer, the speed of development multiplied.
Think out of the box
here was one element of the highly complex product I worried about. Users' data had to be transformed from JSON to SOAP and posted to a module supported by a separate team outside of the organisation. The module would return an HTML string to send to a PDF production software produced by a third party. There were too many moving parts. We had to purchase software licences, configure third-party modules, and write code. I realised that splitting the work among separate team members would provoke task switching and slow down the well-oiled machine we had built. I took it upon myself to coordinate, configure and write code for this final phase so that the other development teams could proceed with their work without losing focus.
Don't be afraid to break the rules if you must
Rules are there for a purpose. I compare software development to flying aeroplanes. If you don't follow the rules, things will go wrong. However, there are times when you have to break them to deliver a project. We made it in the nick of time, but we had to omit writing tests for the last module that had to go into production. We knew it was working. The developer responsible for it was reluctant. Backed by the programme director, who trusted me completely, I took responsibility and pushed the module into production without tests. The developer would write the tests for the next release cycle.
The project at Lloyd's was the most demanding, time-sensitive, and challenging project I have ever worked on. I would never have succeeded without the trust of the people I reported to and the willingness of the whole team to learn and improve daily. We gathered around a cause. Failure was not an option. We knew what was wrong and worked hard at fixing it. We knew where we wanted to get and the road we would take. There was no stopping us.
I talked to every team member with pen and paper in my hands. I asked them a single question: in their opinion, what didn’t work, and how could it be improved? I found out the primary reasons why the project wasn’t moving forward. I got the green light from the program director and set out to fix them.
Establish the proper CI/CD processes
There was no development server. A significant amount of code was piling up on the front and back end, but nobody ever saw them work together. Setting up the development server became my major priority. We faced a mountain of defects once it was up and running, but we could start fixing them now. The testing team was now hard at work, and the ticketing system came alive.
Create clear lines of communication
I quickly became aware of the complexity of Lloyd’s development and deployment processes. It is a vast organisation. Digital security and stability are a must, so the complexity of the operations was a natural by-product. I knew that if we were to develop and deliver a project of this size in an agile and rapid manner, I had to establish clear lines of communication across all the departments. I walked many miles between various buildings in the City of London, introducing myself, explaining what we were doing, and establishing personal relationships with people that would be instrumental to our success.
Right people in the right place
Front end code was in React JS. There was a team of five onshore developers working on it. During the regular code review, I realised that an alpha male developer was an unelected team leader. His confidence knew no bounds, without any practical foundation. His code was late and chaotic, and he had no idea what other team members were doing. At the other end of the office, in his corner, always deep in thought, sat a shy developer whose code was brilliant. We rarely heard his voice, but he would regularly develop good designs and more straightforward solutions. After consultations with him and with the program director, I promoted him to the head of the front-end team and moved the alpha developer to the other end of the office. Front end code started sparkling. After a while, no code review was necessary.
The source of truth
You should always face the most complex problems first. Create a simple prototype that will unmask the size of the complexity and allow you to solve it gradually. There was one product that everyone was afraid we wouldn’t be able to deliver. Business analysts individualised over 120 different screens that depended on user choice. All teams had to be perfectly synchronised to deliver it quickly and effectively. We needed a single source of truth, something everyone could use as a reference.
In lengthy consultations with the technical architects, I realised it had to be the data structure. We had to come up with the broadest possible data structure that would accommodate all the data provided by the users, depending on their choice. Once we created the proper JSON structure and made it readily available to every single developer, the speed of development multiplied.
Think out of the box
here was one element of the highly complex product I worried about. Users' data had to be transformed from JSON to SOAP and posted to a module supported by a separate team outside of the organisation. The module would return an HTML string to send to a PDF production software produced by a third party. There were too many moving parts. We had to purchase software licences, configure third-party modules, and write code. I realised that splitting the work among separate team members would provoke task switching and slow down the well-oiled machine we had built. I took it upon myself to coordinate, configure and write code for this final phase so that the other development teams could proceed with their work without losing focus.
Don't be afraid to break the rules if you must
Rules are there for a purpose. I compare software development to flying aeroplanes. If you don't follow the rules, things will go wrong. However, there are times when you have to break them to deliver a project. We made it in the nick of time, but we had to omit writing tests for the last module that had to go into production. We knew it was working. The developer responsible for it was reluctant. Backed by the programme director, who trusted me completely, I took responsibility and pushed the module into production without tests. The developer would write the tests for the next release cycle.
The project at Lloyd's was the most demanding, time-sensitive, and challenging project I have ever worked on. I would never have succeeded without the trust of the people I reported to and the willingness of the whole team to learn and improve daily. We gathered around a cause. Failure was not an option. We knew what was wrong and worked hard at fixing it. We knew where we wanted to get and the road we would take. There was no stopping us.
