In 2016, Dell Financial Services decided to transform its credit ecosystem. This involved a complete rebuild of the credit adjudication platform in the US as well as rolling that platform out globally. Fast-forward two years and we have done that. We replaced the US platform and launched the new credit engine to 20 countries globally. How? By using agile principles, building solid teams, and using visual models. Join us on an adventure of the ups and downs of the credit world including: working with multi-national credit bureaus, dealing with distributed business team members with often conflicting needs, and coordinating across two multi-continent teams on a single code base.
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 what do you do if your project has none of those characteristics as almost all financial services projects do? Add to that a horizontally structured enterprisehere each team only holds one piece of the puzzle, along with mandatory compliance requirements, and the quandary becomes even more complicated.
During the credit transformation at Dell Financial Services (DFS) from 2016 to 2018, 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.
Candase’s Background: To really understand my journey with the credit team and their transformation, we have to go back, all the way back to college. I went to school to be a structural engineer with dreams of seeing my name on amazing buildings and bridges. However, life took some twists and turns along the way in the form of the recession and a move to Austin. Instead, I ended up at Seilevel and in product management, naively thinking that project management and product management must be similar and thus Seilevel would provide good experience I could take back to engineering. Alas, I learned that product management is NOT like project management at all, but that was OK, I loved my work. For several years, I bounced around various clients learning about agile and waterfall and how to write good requirements and user stories in general. But it was all very user/UI centric. Most of the projects were around the customer experience and writing user stories from the user’s perspective, which came easily to me.
During this time, I also learned a lot about visual models. In a general sense, visual models are just any way to show information visually, but, for Seilevel, they reference our 22 requirements models. We use visual models to break down large amounts of information into digestible chunks, show the big picture and ensure that we’ve covered alternative paths. One model I used a lot during my early projects was a Process Flow which shows the user’s steps to accomplish a goal- usually through a system, see Figure 1 below.
Figure 1. Example Process Flow from ANZ Credit Project
Cárlon’s Background: I have always had a passion for all things crafted with precision. Software engineering is one of them and is what I’ve worked with since I started college. In Brazil, many university students work during college – my classes were in the evening. So by the time I graduated, I had already accumulated almost 4 years of work experience, mostly in software development for Internet content publishing, B2B integration and financial services. I graduated in 2001, and was hired by a consulting company where I worked with custom development and packaged enterprise software implementation for customers in Brazil and in the US. I joined Dell in 2005, and have since then built and managed a number of software engineering teams in Brazil, India, US and Romania. I am currently an IT Director for Dell Financial Services.
I met Candase during a phone interview in the summer of 2016. At the time, I had just been selected and relocated for a new role in the US as the IT leader for credit systems in addition to other responsibilities.
The credit space had a lot of work on its roadmap for the next few years, but not many team members. This was because, in previous years, there had been another huge initiative that, while it was a success, was followed by reassignments of core engineering resources, which caused gradual reduction of team size and the loss of application domain knowledge. I was in charge of rebuilding the credit IT team in the US as well as expanding the engineering practice to Romania. It was in this context that I was interviewing Candase for the Product Owner role of the new credit team.
2.1 Project Background
When I (Candase) joined the team as the Product Owner in September 2016, there was one funded project for the credit team, Australia/New Zealand Expansion (ANZ), and two more major projects planned for the next year: EMEA (Europe, Middle East and Africa) Replatform, 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, a partner system; and in ANZ nothing at all as ANZ was a non-captive region (meaning that all deals came through partnerships and the DFS didn’t manage the deals end to end).
In addition to the hodge-podge of systems for credit globally, the teams and systems at DFS were managed horizontally. This meant that while the credit team owned credit adjudication and communications with the credit bureaus, we did not control the UI that the customers or sales reps used to apply for credit. This impacted our team in two ways. First, we had additional dependencies to work through with the upstream teams to ensure that end-to-end, the process worked. Secondly, there was very little actual user interaction with our system. Everything was API based, so it put a challenge on me as a PO to both gather and write the user stories when there were no users involved!
Furthermore, while agile had started to become the mode of project and product delivery, this transformation was not the most ideal circumstances for agile. The IT team had bought into using agile and delivering smaller increments, but the business and management were still learning about agile and so weren’t fully bought in. They still wanted detailed plans of when we would have one big bang go live!
On the business side, we also had no dedicated business product owner. I was an IT product owner and an outside consultant to boot. As an IT product owner, I reported up through the IT organization as opposed to the business (which had different reporting structures) and had limited decision-making authority. Nevertheless, I wrote the user stories and planned out the priority of work with input from the business stakeholders who had the ultimate authority on what would be built. We had a primary business partner that we worked with and she was very knowledgeable, but she had a day job and couldn’t be on hand to answer every engineering question.
Outside of these, the credit IT team had two main challenges: limited existing product knowledge on the team as most team members were both brand new to the company and to the subject matter and the diverse locations and time zones of the team. We were spread out on 4 continents: North America (US), South America (Brazil), Europe (Romania), and Asia (India). Cárlon additionally had one other impediment to overcome—hiring two full teams of 8 engineers each, mainly in Romania, where DFS did not have a large presence at the time. This involved onboarding multiple vendor partners and many, many interviews to find the right people!
Finally, we had one more set of challenges to overcome: mandatory scope and due dates based on contractual agreements. On a more typical agile project, the PO can set scope or a date for the team to deliver to, but in this case, due to existing contracts at the enterprise level, both were out of our hands. We had to deliver 20 countries, integrate with 12 credit bureaus, and deliver 3 programs by July of 2018 to be successful!
For Phase 1 (ANZ), since we were taking a country captive from a partner bank (previously all deals went through the partner bank and once we took it over, all deals would go directly through our systems and not the partner banks), we had 6 months from the day we announced our intentions to the bank to go live and take over the portfolio. Failure to do so would result in huge daily fees from the partner bank. For Phase 2 (EMEA and US), since in EMEA we were using a vendor’s tool to manage credit, we had a hard deadline of May 31, 2018 to either get off the partner’s legacy platform or be charged to upgrade to their new version of the tool (over $1M in upgrade fees alone).
3. PHASE 1: AUSTRALIA AND NEW ZEALAND
For the first phase, the most important part was building knowledge of both the current and future state credit system so that we could expand it to the new countries. Since knowledge of the existing code base and functionality was limited, we instead focused on what we knew: the current state for EMEA and what the future state should be. I worked for several weeks with business stakeholders to understand the current EMEA business processes to create current state process flows. Using those, I then elicited the changes that they wanted for the future in ANZ to future state Process Flows. Additionally, we both spent weeks with the two developers on the team who understood the current product and the solution architect to understand the technical side of the new credit system and what we wanted it to be.
Figure 2: Ecosystem Map of the systems impacted by the three credit programs
Gathering this knowledge quickly was probably the biggest challenge for me because of the steep learning curve on APIs, XML, JSON, Business Object Models, and database design in order to document and write stories for this very technical product. As the organization was split horizontally, our credit product would receive API requests for a credit decision by the integration layer (which in turn got requests from the customer management system or the UI where a customer or sales rep requested credit). Our product would then communicate with our business rules engine (the system that would render the final credit decision), any sources of credit data (mainly credit bureaus but could also be internal data on the customer) and store all the credit data per the retention requirements (since this was commercial credit, we needed transactional access to the credit decision for 90 days and reporting access effectively in perpetuity). See Figure 2 above for the Ecosystem Map of the credit space.
The team worked on the design of 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, and Data Flow Diagrams. However, the model that proved most effective with the team was a System Flow. A System Flow shows all steps and decisions a system makes internally from an external trigger (in this case the API request). We had a System Flow for searching for the customer at the credit bureau so we ran credit on the correct commercial entity as well as multiple flows for rendering the credit decision and updating the credit decision (see Figure 3 for an example).
Figure 3: System flow of part of the internal credit decisioning process
This set of System Flows helped in several ways. First, while reviewing the features and processes with business stakeholders, we could show what the credit system was doing internally and how that would meet their expected business features. Secondly, it helped tremendously to get the team on the same page. One of the best things we did as a team/program that helped us be successful, was run a workshop in November of 2016 very soon after the final engineers were hired for the team. We brought all of our team members from Brazil, India and Romania to the US for a two-week-long workshop. During this workshop, the team built trust and camaraderie (we were no longer just voices on the phone), but also aligned on the technical structure of the product (code branching, deployment strategies, etc.) and the internal processes of the system via the System Flows.
Once the workshop was over, we used the System Flows at every grooming session. When introducing a new story, I (Candase) would first open the System Flows and talk about where in the product this story took place. This made it much easier then 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 model called the Feature Tree (see Figure 4), which shows all the features for a product or program in a tree shaped layout, to visualize the scope and determine what could be deferred to Phase 2. In this case, we agreed with the business that New Zealand customers would have their credit manually run until Phase 2.
Figure 4: Feature Tree from ANZ program
The result of all this was that while we did have to defer some scope to Phase 2, we were able to clearly see what scope we could defer that would still meet our overarching goal and deadline to take ANZ captive. And, after all was said and done, we did deliver on time!
4. Phase 3: Europe and the US
As we started to wrap up ANZ, Candase left the current team and program to a Product Owner in Romania and started focusing on the next phase of the credit transformation. This second phase of the credit transformation consisted of two programs: EMEA Replatform and Single Adjudication. To support both programs at once, Cárlon needed to build a new development team mainly in Romania, which also interacted with individuals in Brazil, US, and India. Candase moved over to be the IT Product Owner for the newly built team. For the most part, the team that started on ANZ moved on to work on EMEA Replatform (Team CodeXtreme) since the business requirements for both regions were very similar. Two of the engineers from Team CodeXtreme came with Candase to start the new team for Single Adjudication or the rebuild of the US credit system (Team Velociraptors). Just like for ANZ, to kick off the new programs, we held a team workshop- this time in Romania- to get all the new engineers up to speed on the product and upcoming requirements (since the team for Single Adjudication was almost entirely new).
The EMEA Replatform program consisted of moving 17 countries in Europe off of a vendor tool that currently ran credit to the new credit system that we had deployed in ANZ. Since the systems integrating to our credit system were the same in ANZ and EMEA and the business requirements were similar, the main challenge of EMEA Replatform was working through all the countries in roughly a one year time span (the team moved from working on ANZ to work on EMEA in May of 2017 and had to be off the vendor tool by May 2018). During a workshop to kick off the program, it became very apparent that if we were going to deploy to 18 countries (including New Zealand), we had to ruthlessly automate our testing as every new country we onboarded required regression testing of every country already on the credit platform. One other challenge that EMEA faced was that most countries had their own credit bureau. This meant that the credit system would have to integrate with 9 different credit bureaus in Europe to get the right credit data. This also meant occasionally visiting with the credit bureau in their country because they wouldn’t answer emails and some didn’t speak English.
In addition to automation, the team on EMEA worked with the business to deploy countries individually from the vendor platform to the new credit system to mitigate a big bang cutover in May of 2018. Together, they created three groups of countries that could be “turned on” during the year and used upstream controls in the customer system to say whether a country’s customers would be adjudicated by the vendor tool or our new credit system.
In the US, the story was a little different. The US was using the existing homegrown credit system, but there were compliance issues in how the credit system was rendering the credit decision for the customer. In the US, the business supported two credit products for its commercial customers. When the legacy credit system was built, customers always applied for both credit products at once and were adjudicated for both products at once. However, as the business grew over time, customers wanted to be able to apply for only one of the credit products or the other. In addition, the business stakeholders wanted to continue supporting the current structure of determining a credit decision for both products at once. The effort to make this change from only rendering a decision from both products at once to the more flexible solution of one or both products was called Single Adjudication.
Once we spun up the Velociraptors team (working on Single Adjudication) on the same codebase as Team CodeXtreme (working on EMEA Replatform), we would end up with 16 engineers on one codebase! To make sure we weren’t going to be stepping on each other’s toes, we took a few steps to improve our chances for success across the two programs. First, the engineers met and determined some enhancements to their engineering processes- namely cross-team code reviews and a shared dev branch to find code conflicts early and often. Second, the two Product Owners of the team (Candase and the Romanian PO on Team CodeXtreme) kept a consolidated set of models and data mappings so we could visually see if we would be impacting each other’s requirements. We also held daily meetings to talk about what features were upcoming for each region. This was very efficient and allowed us to support up to 20 countries with the same credit system.
We faced another challenge from these two programs- conflicting asks from our global business partners. Our original goal with ANZ and when designing the new credit system was that we would have a unified, global business process to support. This assumption worked well for EMEA and ANZ, but fell apart when we got to the US (definitely one mistake we made was not engaging the US business partners earlier in the transformation). When I (Candase) started eliciting the requirements for Single Adjudication from the US business partners, I found that their current business processes were very different from EMEA and there was resistance to a whole-scale change of their business processes for various reasons.
For each of the deviations from the previously defined business processes, I would work with our business stakeholders to understand why their processes were different and what the real requirements for their process were. Some of these were compliance-based and had to be accommodated. In this case, I would work with the business stakeholders and the solution architect to implement those changes in a way that didn’t impact the existing code/countries. One example of this is that the US is the only country for which the business supports an owner of a company putting their personal credit up for the commercial entity (usually for small businesses that don’t have a credit report with the commercial credit bureau). In this case, a person who owned at least 25% of the company could supply their personal details and we would pull their personal credit (very similar to any consumer credit card). However, once you start doing consumer credit, there are very different laws at work to protect the consumer. One of these is that if a consumer customer is declined for credit, DFS MUST send them a letter stating the reasons they were declined. Internally we called this the Decline Letter. And there are various rules for when you must send one of these out to the customer (what happens if they apply twice in one day for example?) To work with this, I used a visual model called a Decision Table (see Figure 5), which shows all variables or decisions a system uses and what the outcome is based on the combination of decisions. I worked with the business rules team to document every variable (day, previous credit decision, etc.) to determine when the credit system would generate a new decline letter for the customer. This was very useful to make sure we had covered all scenarios as well implement it in such a way that it wouldn’t impact the EMEA/ANZ customers.
Figure 5. Decision table showing whether or not to send a decline letter to a customer based on current and past credit decisions rendered
In other situations, there were alternate ways to satisfy the requirement that may not have been compatible with current business processes. One example of this was changes we planned in the database structure. When I first presented the new database structure, our business partner didn’t want the changes made. Upon further digging and using the System Flows and Business Data Diagram to show that we indeed needed to make the changes to be able to only adjudicate for a single product at a time, we got to the real reason for her resistance. She had created many queries over the years where she pulled data for compliance and reporting. The new data structure would break her queries. So rather than trying to shoehorn the existing countries and processes into the legacy database structure, we, as a team, rewrote her queries so they would work with the new database structure. In the end, she agreed to the database changes and was happy with the end product for single adjudication, even if it took a while to get there!
It was a long year, with many ups and downs, but by July of 2018, we had deployed the new credit system to all 18 countries we had defined for Phase 2 (including New Zealand which had been deferred from Phase 1) as well as deployed Single Adjudication in the US.
5. Phase 3: What’s Next?
We deployed and it was a success! But what came next? In August of 2018, Cárlon hired a new IT Sr. Manager to lead the credit IT team as he received additional responsibilities pertaining to a new program that was starting up in the organization. He wanted Candase to move from credit and help establish a product management practice in this new program with him. This was the next test, could the team’s product knowledge outlive us leaving the team?
To help with this transition, I (Candase) 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 the 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 which says what is really out 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 across the three regions and put them all together in a document that described what the credit system did as of the July 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 for the team (who had worked with as a business systems analyst on the Velociraptors team previously so had some product knowledge) as well as the team.
I moved off the team in August 2018 and Cárlon continued with both areas for another 5 months. A year later, the team has turned over developers and Product Owners, but is 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 systems to even more countries using the blueprints we laid out. They continue to evolve them, especially on the technology side! Now, an “As-Built” document for an agile product is only good if it is kept up to date with new changes. We don’t know what the future holds for the credit team and the credit product, but so far, the “As-Built” has stood up to the year plus of changes.
6. What We Learned
I (Cárlon) had in the past built several teams with engineers located in different regions. In most cases the on boarding of new off-shore team members was usually intended to increase the capacity of an existing team which was technically proficient and knowledgeable of the application ecosystem and business domain.
In this case, we had to start almost from scratch. As mentioned earlier in this report, we had very few subject matter experts available to on-board the new team members. This meant the build-out of the team also had to rely a lot on the ability of the off-shore teams to proactively research and even at times reverse engineer the current state solutions they would begin to redesign.
From that perspective, the collocation of the members of each team played an important role in building a sense of ownership and also in boosting resolution of day-to-day impediments and challenges: each team had all roles it needed in the same location, including the product owner. This helped them operate independently while integrated with their peer delivery teams in other locations.
Even with that, staffing all required roles of a new team with technically sound collocated personnel is not enough to achieve effectiveness when collaboration is required across teams. Beyond bonding and creating a team spirit, it was also key to create opportunity for these new teams to absorb culture and values by practicing collaboration dynamics with the US team. The workshops we held when kicking of new programs were more than presentations of program plans. Instead, the events were used to host engineering process reviews, design discussions and to experiment with typically remote day-to-day problem solving, design and development activities across teams in a temporary collocated fashion. This allowed the new teams to practice several tasks they would have to continue doing remotely. The positive change in collaboration, adoption of standards, productivity increase as well as the reduction of communication issues was very visible.
I also learned how to use visual models on a technical project. I had used them for years on more user-centric projects. But it was a true learning experience on how best to accurately show technical details in these diagrams. I sometimes had to tweak our more user-centric models to show those technical details, like adding minute details about steps within the credit system. But these visuals were so much more powerful than user stories alone would have been. Even in the world of API calls, pictures are easy and words are hard.
From a product/transformation level, together we learned that just because a program or project doesn’t have the ideal agile conditions doesn’t mean that agile brings nothing to it! In fact, sometimes those unideal conditions are what makes agile more suitable than traditional approaches. Being agile means you can more easily accommodate the changes! Also, being agile doesn’t just mean one thing. It’s not a one size fits all. Given our compliance and other regulatory constraints some people may say we weren’t agile. But we embraced the agile principles and were as agile as we could be under the circumstances. We focused on delivering working software over comprehensive documentation, even if only to test environments for our business users. The visual models we made were by no means comprehensive documentation of the system, but gave us a tool to help get people talking and aligned on what we needed to build and where. We focused on people and interactions. Even with our visual models, it took people talking to other people to make these programs a success. Documentation only gets you so far. And we focused on customer collaboration and responding to change to find creative solutions when new requirements came up from our business partners that were sometimes at odds with what we had already built or what other regions had specified. Many of these things would not have been possible using more traditional software development methodologies. So in this way we were agile even if we were not the most agile!
So what do you do when your project or product doesn’t have the makings of an “Agile Cinderella Project” but you still want to be agile? You learn from past projects, take the principles of the agile manifesto to heart and be as agile as possible—finding that middle path through being agile and managing the challenges that would derail the project from being agile.
We would like to thank Rebecca Wirfs-Brock for shepherding us through this process and ensuring this paper told the best story of our experience, as well as our colleagues who helped make these programs a success!
[Andrea] Andrea, J. (2005, September). If the shoe doesn’t fit—Agile requirements for stepsister projects. Better Software Magazine. http://www.cmcrossroads.com/sites/default/files/magazine/file/2012/XDD9690filelistfilename1_0.pdf