For several years, I’ve worked with a Financial Services client that offers consumer and commercial credit to customers world-wide. In 2016, they decided that they needed to transform their credit ecosystem to meet changing market and legal demands. This involved a complete rebuild of the credit adjudication platform in the US as well as rolling that platform out globally. Any project in the financial services space is complicated by compliance requirements, risk management, and a LOT of regression testing. Add the complexity of a global project with a massive scope, and you may wonder, how could you possibly apply agile principles to THAT?
Does Agile Fit a Big Porject?
An “Agile Cinderella Project,” according to Jennitta Andrea, is one where the glass slipper of agile fits perfectly. In this type of project, the team is small and co-located, there is a business SME dedicated to the team to answer any questions, that SME has an end goal for the product, and the domain is either simple or the team has experience in it. But our project had literally NONE of these characteristics.
During the credit transformation project, we took Jennitta’s own approach of a pragmatic middle path. This meant being as agile as we could be while making accommodations to support the fact that we didn’t have the characteristics of an “Agile Cinderella Project.” To accomplish this, we used many tools and relied heavily on the use of visual models.
Project Scope
When I joined the team as the Product Owner, there was one approved project for the credit team – the Australia/New Zealand Expansion (ANZ) and two more major projects planned for the next year – EMEA (Europe, the Middle East and Africa) Re-platform, and US Single Adjudication. Together, all three of these programs represented a complete transformation of the credit system of that time as well as significant changes to business processes globally. The credit ecosystem at that time was very localized—in the US, we had a custom-built system for adjudication. In EMEA, we were using a partner system. In ANZ, we had no adjudication system in place because our credit deals there came through partnerships and we didn’t manage them end-to-end.
The Big Challenges
One big challenge for us in addition to the hodge-podge of credit systems was that the various functions were managed horizontally. This meant that while the credit team owned credit adjudication, they didn’t control the UI that the customers or sales reps used to apply for credit.
Another challenge for our project was that we lacked a dedicated business product owner As an IT product owner, I reported up through the IT organization and had limited decision-making authority. I wrote the user stories and planned out the priority of work with input from the business stakeholders. We had a primary business partner that we worked with. She was very knowledgeable, but she had a day job and couldn’t be on hand to answer every question.
A third significant challenge was the organization’s agile maturity. IT teams were using agile already and delivering smaller increments of work, but our business stakeholders and management weren’t yet as knowledgeable or bought in to agile concepts. They still wanted detailed plans and a big bang go live!
Finally, we had one more major challenge to overcome: mandatory scope and due dates based on contractual agreements. On a typical agile project, the PO can set scope or a date for the team to deliver, but in this case, due to existing contracts at the enterprise level, both of those options were out of our hands. We had to deliver in 20 countries, integrate with 12 credit bureaus, and deliver 3 programs by July of 2018 to be successful!
How We Did It - Workshopping
One of the best things we did as a team was to run a workshop very soon after the engineers were hired for the team. We brought all of our team members from four different countries to the US for a two-weeks-long workshop. During this workshop, the team built trust and camaraderie and also aligned on the technical structure of the product and the internal processes of the system via System Flows visual models.
How We Did It - Visual Models
Once the workshop was over, we used the System Flows at every grooming session. When introducing a new story, I would first open the System Flows and talk about where in the product this story took place. This made it much easier for the team to agree on the story acceptance criteria and size it. Finally, when the deadline to launch was looming, we used the System Flows and another visual model called the Feature Tree to visualize the scope and determine what could be deferred.
How We Did It - Flexible Architecture
In order to alleviate the technical challenge of having multiple teams working on the same code base, we designed the new product with a core and node code structure. This was so that engineers could work on the data sources (nodes) as well as connecting the data sources (core) without conflicting code. As we designed the new system, I documented these technical requirements through various visual models including Ecosystem Maps, Sequence Diagrams, Data Flow Diagrams, and the ever-useful System Flows.
How We Did It - Automate Testing
During the project, it became very apparent that if we were going to successfully deploy to so many countries, we had to ruthlessly automate our testing. When we onboarded a new country, we had to run regression testing of every country already on the credit platform. Without automation, testing would have swamped our teams and threatened our schedule.
How We Did It - Rolling Cut-Over
Additionally, our team worked with the business stakeholders to define groups of countries that could be “turned on” during the year and used upstream controls in the customer system to determine whether a country’s customers would be adjudicated by old or new credit system. This avoided the risks of a big-bang cutover and enabled us to be more agile in our delivery.
Success!
We deployed and it was a success! Then I moved from the credit team and helped establish a product management practice in a new program. This was the next test, could the team’s product knowledge outlive my departure?
A Smooth Transition
To help with this transition, I started work on an idea that I carried over from my engineering days – an “As-Built” document. In civil engineering, when you’re building a bridge or a building, you have design documents that tell you how the structure should be built – rebar at every 6 inches, column placement, etc. However, construction rarely goes exactly to plan, so for every structure, there is an “As-Built” document that says what is really at the site. If the design document called for rebar at 6” but in reality it was 7” or 5”, the “As-Built” document would show that. During the quiet week before the US launch, I went through all of our documentation and created a document that described what the credit system did as of the deployment. It contained all the visual models we had created over the past two years as well as links to mapping documents and anything else that was relevant. This was shared with the incoming PO as well as the existing team.
A year later, the team had developers and Product Owners but was still using the visual models and documents we put in place to onboard new team members and share that product knowledge. Even more exciting, the team is now expanding the credit system to even more countries using the blueprints we laid out. They continue to evolve them, especially on the technology side! We don’t know what the future holds for the credit team and the credit product, but so far, the “As-Built” has proven to be incredibly useful and durable.
Want to learn more about applying agile methods to YOUR projects and products? We’ve helped clients in every type of industry figure it out. Contact us and let’s talk about your challenges!
