0% found this document useful (0 votes)
139 views11 pages

Paper 11-Case Study The Use of Agile On Mortgage Application Evidence

This document presents a case study of a mortgage loan origination project in Thailand that used the SCRUM agile model combined with a Business Process Management and Business Rule Management System (BPMS and BRMS) tool. The initial project using a traditional waterfall model failed due to issues like insufficient project management and rapidly changing requirements. The project was continued using a BPMS/BRMS tool along with SCRUM methodology, which better supported rapid business needs with minimal coding. While SCRUM and the new tool helped rescue the project, budget overruns occurred due to inexperienced project management and political timeline pressures. User surveys found increased satisfaction with the new system and processes.

Uploaded by

MelvinTrendz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
139 views11 pages

Paper 11-Case Study The Use of Agile On Mortgage Application Evidence

This document presents a case study of a mortgage loan origination project in Thailand that used the SCRUM agile model combined with a Business Process Management and Business Rule Management System (BPMS and BRMS) tool. The initial project using a traditional waterfall model failed due to issues like insufficient project management and rapidly changing requirements. The project was continued using a BPMS/BRMS tool along with SCRUM methodology, which better supported rapid business needs with minimal coding. While SCRUM and the new tool helped rescue the project, budget overruns occurred due to inexperienced project management and political timeline pressures. User surveys found increased satisfaction with the new system and processes.

Uploaded by

MelvinTrendz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

(IJACSA) International Journal of Advanced Computer Science and Applications,

Vol. 5, No. 9, 2014

Case Study: the Use of Agile on Mortgage


Application: Evidence from Thailand
Kreecha Puphaiboon
Faculty of Computer and Information Technology
Kasem Bundit University
Bangkok, Thailand

Abstract—This paper presents a case study of a mortgage software development processes, and reduce costs. Other
loan origination project using SCRUM Agile model and Business organizations are skeptical about whether agile development is
Process Management and Business Rule Management System beneficial. Additionally, large organizations face an additional
(BPMS and BRMS). From the Waterfall model (Stage 1), a web- challenge in integrating agile practices with existing standards
based self-developed had been developed using opensource and business processes [4].
frameworks: Spring and Sarasvati. But, several problems were
detected and the project failed due to insufficient project Whilst it is generally accepted that SCRUM development
management, rapid requirement changes and developer coding improves the cost reduction and it helps to accelerate the
skills. The project was continued (Stage 2) selecting a BPMS and software product to the market. Importantly, it improves
BRMS tool. Later, Stage 3 SCRUM was executed with proper customer satisfaction [5] [6]. However, no field studies
project management and the new tool, which suited better for research has been reported when Agile and SCRUM is first
rapid business needs, and minimum coding. An efficient team being used in a large organization in Thailand. Research [5]
communication and the frequent delivery of code releases mentioned factors to run Scrum in aligned with PMP BOK
increasingly contributed to the sponsor and user’s satisfaction. principles (see Table I). Hence, the researcher wants to study
However, due to political influenced timeline, inexperienced and report the usage of Agile/SCRUM to satisfy business
project management and requirement changes, the budget needs and assess the impacts over the IT development an
exceeds and SCRUM is not favored. Nonetheless, Open-end example for software engineering community.
questionnaire and interview results with core team members
both business users and developers as well as software usability TABLE I. step 1. 4, often the projects have been assigned
measurement inventory (SUMI) conducted with 14 users, it with the timeline [6]. Political forces at work within a project
shows that SCRUM and the new tool rescue the project. or company can often drive estimation inaccuracy [8]. This is
Empirically, this paper demonstrates a method to evaluate the usually in the form of managerial pressure to stay within or
use of Agile augmented with usability measurement to Agile meet the estimate timeline [8]. The estimation process can be
development community. impacted negatively by these pressures resulting in project
timeline or cost constraints [8] [9].
Keywords—SCRUM; BPM; BRE; Mortgage Loan; LOS;
Usability The rate of change in business and bank is accelerating [1]
[2] . A number of techniques for addressing that change have
I. INTRODUCTION emerged independently to provide for automated solutions in
Mortgage loan origination process is complex, although this environment. Business Process Management (BPM) and
common process flows are: Application, Processing, Business Rule Engine (BRE) that are large as well as
Underwriting, Closing and Post Closing [1]. However, a distributed are becoming more prevalent [10] [11]. Both
system that can handle a large number of Loan numbers is technologies tend to offer the promise of easy to change. As
hard to find. In addition for IT, the pressure to revise flows, change is common in large projects; the case where the
policy changes and credit risk calculations in a few days and entirety of a project’s complexity is understood in the early
automatically make correct lending decisions has been a great stages is quite rare. Large, distributed projects that involve
challenge in retail banking [2]. There's no room for customer user requirements present a unique challenge that neither agile
and financial information and loan process errors as banks methods nor waterfall approaches alone can effectively
need to have certain confidence in every lending decision. address. Hence, combining an effective software development
tool with agile process may be very beneficial.
Agile’s principles encourage the formation of collaborative
and self-organization teams [3]. The Agile Manifesto is as Koch [12] has proposed three criteria for evaluating the
follows: 1) Individuals and interactions over processes and effectiveness of the agile method adopted: 1) project
tools. 2) Working software over comprehensive performance with schedule performance and budget
documentation. 3) Customer collaboration over contract performance; 2) management acceptance; 3) customer
negotiation. 4) Responding to change over following a plan. relationship and 4) team satisfaction. However, usability was
However, a continual debate surrounds the effectiveness of not included. Thus, it is important to evaluate all these five
agile software development practices. Some organizations criteria for agile adoption for which they were deserved.
adopt agile practices to become more competitive, improve
I am thankful to Kasem Bundit who has sponsored this research

63 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

TABLE I. THE KEY PROCESSES OF RUNNING SCRUM practices in a condensed form. SUMI for Software Usability
The key processes of running scrum Measurement Inventory is commonly used for usability
1. Determinate phase 2. Planning phase 3. Start-up phase evaluations [14]. SUMI consists of over 50 questions; it is
method of measuring software quality from the end user's
1.1. Develop the real 2.1. Define all the work 3.1. Recruit project point of view. There is a need of usability measurement
requirements of of the project; manager; integrated with agile methodology to determine whether the
customers; software supported mortgage loan needs or any domains.
2.2. Establish the 3.2. Build the scope
1.2. Write a one page
schedule of initial change management
This article presents the case of mortgage loan origination
project description;
project; process; project called LOS. The purpose of LOS was to replace an
existing mortgage application as there were problems such as:
1.3. Recode the 2.3. Assess the time 3.3. Recruit the legacy application (over 15 years old), lack of Power Builder
requirement of required to complete project team
customers; the project; members; developers to support, difficulty in changing business flows,
incapable of scalability and performance issue. There were
1.4. Gain the senior
2.4. Analyze and adjust 3.4. Manage the team over 8,000 users using the mortgage system, roughly around
managers’ permission
to run the project;
the project schedule; communication; 500 concurrent users across the nation. There are needs for
1.5. Discuss how to 2.5. Assess the resource 3.5. Write the
new application with features: easy-to-change, web-based and
meet the requirements required to complete descriptive document scalable, user to make routine changes. Also, the emphasis is
with the customers. the project; of project; on IT to have a fast delivery of the software application to
2.6. Write the risk 3.6. Determine the compete with market trends and attract customers, the faster
management plan; schedule; the delivery of software are the chances that the bank will gain
profits. Note that the writer is the technical manager of this
2.7. Assess the whole 3.7. Build the team
cost of the project; operating rules; project. The bank is ranked in the top five banks in Thailand.
The revenue of mortgage loan was over 1 billion us dollars in
2.8. Record the project 3.8. Write the work year 2012. So, it is a highly critical system for the bank.
plan; package.
2.9. Sort the work in
The paper is structured as follows: Section 2 presents the
chronological order; development stages of delivering a prototype, including
2.10. Get the senior detected problems. Section 3 explains ways in which
management’s BPM/BRE tools were selected. Section 4 describes the full
permission to start the development SCRUM model and some properties of the
project. methodology are summarized of the system and its iterations.
Section 5 shows team comments on Agile/SCRUM base on
4. Supervision and 5. Decided to start the
control phase iteration phase
6. Closeout phase questionnaire and feedbacks via Sticky Notes and user
experience assessment to the software via SUMI usability
5.1. Decision-making 6.1. Get the questionnaire. Lesson learned and conclusions are presented in
4.1. Build the running
process for customer confirmation of the
and reporting system;
management; customer;
Section 6.
5.2. Customers must be 6.2. Prepare for the II. STAGE ONE OF MORTGAGE APPLICATION – PROTOTYPE
4.2. Report the
fully involved in this deliverables and
schedule;
process; installations. SELF-DEVELOPMENT
5.3. The atmosphere Using Waterfall model, the development of web-based
4.3. Supervise the 6.3. Write the
running;
must be complete open
closeout report; mortgage application the project was initiated (2011–2012)
and honest; timeline and main tasks were planned by senior management
4.4. Deal with the
5.4. Determination with four months for each step of requirements, coding and
must base on the 6.4. Start the audit of UAT testing. Two main representatives’ of business users
request of scope
expected commercial the running.
change;
value;
were given. Requirement gathering in June – September 2011,
5.5. Solution must be
there were 18 main flows from start to finish entire loan
4.5. Supervise the
formed according to the process e.g. data entry, manager, credit approval officer, credit
risks; approval manager, legal contract and legal managers. The
project’s goal.
4.6. Identify and
direction was to used open-source framework and in-house
solve the problems. development the J2EE, Spring Framework (2009) and
Sarasvati proposed by IT developers. Spring is used to handle
Agile and usability aim to build quality software. As noted simultaneous runs and as an interface to database DB2 (see in
in research [13], agile and usability the two methods have Appendix for Fig. 4). The development effort was plan
much to offer when they share iterations because the iterations roughly for 14,400 man hours for the entire project for one
used in agile facilitate usability testing and allow developers project manager, two business users, 10 Java developers
to incorporate results of these tests in subsequent iterations. (average experienced 3.5 years) and 3 testers. The budget was
However, research [13] commented that improving the 180,000 USD.
usability of a product does not come without costs. In order to Application development was carried out in October 2011
integrate agile and usability and at the same time minimize - January 2012, but different problems threatened the project
these costs and risks, we need the use of usability artifacts and continuity. Considering the SIT was unable to finish within

64 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

the first two month (1 month delayed) due to numerous bugs. drawn/changed without coding; and 3) requirements and
The team had difficulties to follow defined plans and the documents are saved in the system so developers can identify
senior executives were unsatisfied with the progress of the changes. Another benefit for the bank is that financially, 5
software development after 6 months. The following main Year Total Cost of Ownership (TCO) is less than other
deficiencies were detected: products. The product also offers Cloud Amazon EC2 service,
thus it leverages maintenance agility and investment cost. 5
 Deficient project management and communication; year TCO of the project is around 10 million US dollars. But
project manager, domain experts and end users were for mortgage application is funded with 1.5 million USD
present only six-hours per week. They also sit in where outsource developers budget is around 330,000 USD.
different buildings with IT developers. Telephone and Time-and-Material contracts and Labor Hour (LH) contracts
e-mail were used. These means did not result efficient are used. Three weeks of training was also provided to local
when problem arisen and need immediate action from staff including business analysts.
BAs.
IV. STAGE THREE OF MORTGAGE APPLICATION –
 Requirements were broad without enough details and
cannot integrate entire flow. For example, details of APPLICATION OF SCRUM
different collateral types between two units are not in On June 2012, the Stage 2 of the software development
sync (processing and underwriting). Therefore, most of finally started. As it was learnt that requirement
the coding tasks required impact analysis, modifications documentation was not clear, hence the re-
and re-implementations, causing continuous delays to documentation/requirement were captured and put directly
the development process. into the system. Two weeks period with multiple sessions
captured the details of the use cases and flow which give the
 The implications are poor change control, developers’ project traceability and determine application requirements.
software design skill and software framework to adopt During the requirement gathering, a close seating and direct
dynamic changes. communication environment within a big room with a
 The developer stated that complicated flow, business projector, design sketches and white-board, notes and mocked
rule calculations and changes were the root cause of up screen were conducted. These meetings focus on
failures. efficiency, getting 2 subject matter experts (SME) from 2
departments into the room to focus on the implementation
The objectives of self-develop web application project details of mocking up UI, validation of inputs and outputs and
were clearly not met. Significantly the budget was exceeded aware of each other impacts. They agreed up front on how the
by 60,606 USD. After a meeting between the team and application processes will work, avoiding costly rework later.
executives (CFO, COO and CIO), all decided to discontinue The outcomes determined the number of iterations, sprints and
the self-development. CIO advised the project to acquire BPM effort required for the project. Due to business confidentiality,
and BRE tools which support developer to code as less as Fig. 1 shows some of business process flow of Application
possible and users can manipulate the flow and rules within Registration, Processing and Underwriting (without Closing
the system. This is to downgrade possible failure risks. and Post Closing). More details will be discussed in Section
Importantly, the team requested access to the expert user on a 4.1 – 4.5. The sizing effort by developers was produced with
daily and full-time basis. 11,480 man hours for coding and unit testing (see Fig. 1
circled number 2) with total of 213 use cases (see some
III. STAGE TWO OF MORTGAGE APPLICATION – SELECTING specification below in Fig. 1 circled number 3).
AND ASSESSING THE TOOL
On February 2012 the BPM and BRE Vendor Selection
was executed. The top product listed in Gartner and Forrester
ranking reports were invited. Importantly and practically, two
weeks of POC project to build almost half of an entire
mortgage process arisen from Stage 1 including SIT and UAT
were conducted. Moreover, stress test with 500 concurrent
users was conducted and passed 3 seconds respond time
criteria. Developers and users from the bank also involved in
the development as well as evaluation of the software. This is
to prove that the selected BPM/BRE framework provided
software flexibility for fast development without much coding
and ease of change when users want to change various
calculation schemes. For end users, they appreciated the fact
that they can input decision rules and the software provides
friendly and intuitive screens for users. Another additional
benefit for developers is that the software supports Agile
development: 1) users can draw flow and design screen with
developers in real time without coding this helps to improve
business gaps with users; 2) flows and rules can be
Fig. 1. Flows of Mortgage Application

65 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

However, TABLE II shows the output sizing sheet and A daily "scrum" or standup meeting was held with all the
effort for the project which was influenced by the senior stakeholders. Every day, developers answered three questions:
executives to 7,524 man-hours (reduced 34%). 1) what have you done since yesterday; 2) what are you
planning to do by tomorrow; and 3) Do you have any
TABLE II. ITERATIONS PLAN AND SIZING EFFORTS problems preventing you from accomplishing your goal. To
Political Forced Effort and Initial Effort in Man-Hour
satisfy quality assurance of development, unit test with
Steps capture screens was applied by developers and reviewed by
Name Political Plan
business lead. Frequent delivery and test with every two
1 Application Registration 1,332 440 weeks, a release was delivered to SIT environment with bug
2 Application Processing 720 380 fixes and new features in product backlog. For fast testing,
QTP was used as an automated testing tool. Once a month, the
3 Underwriting and Closing 480 3,296 product was released to UAT and a meeting with steering
4
User Management and Change
2,256 502
committees was conducted to inform the status of bug fixes
of Condition and project status. This is to ensure that the team and all
5 Risk Analysis and Interface 2,736 6,862 stakeholders have reviewed the product and meet the
expectation.
Total 7,524 11,480
A. Iteration 1 (Application Registration)
In this project, the system development team was
Following the plan, a short first iteration (15 days) was
integrated by four groups with the following roles:
designed (02/07/12 - 23/07/12) but it was taken 34 days to
 Developers: agile defines specific categories team lead complete - 19 days later than planned. This iteration involves
designer and programmers. In this case, they were the first three columns in Error! Reference source not
cross-functional and allocated dynamically depending found.1 where users register a mortgage application with the
on particular needs of the running iterations. Four barcode and confirm application creation. The data entry
developer teams were agreed between three different person will enter customer information from a hard copy
vendors and the bank. 23 developers were engaged and document and use the citizen identification to interface with
16 were outsources from India, Singapore and Hong National Credit Bureau and obtain the credit score result
Kong averaged 4.0 years experienced with the product. which will be used later in underwriting calculation. User can
Higher number of outsource the reason being that check and search if the borrower or co-borrowers information
because bank staff had little experience with the exist in the core bank systems, if so retrieve all the
product. information. Once completed, they can send to the supervisor
whose role is to review and revise wrong/missing data given
 Product owner is IT business analyst lead manager: she by their staff. Later, if required they can submit the work to
works with SME and users. another unit whose roles are to comment and record missing
 Scrum master is technical manager who does the code data or document for further analysis of sale sufficiency. They
review, release management, network, and security. He also need to follow up with sales or customers about the
serves as a resource to help the teams make appropriate missing information.
system and component level design decisions during The first integration of the GUI presentation layer with the
implementation. He defines and split use cases and bank systems was achieved as a working software delivery.
features for the program backlog, and allocating However, there were two factors which affected this iteration
respective items to the individual team for timeline. Firstly, Bank of Thailand regulation states that the
implementation. bank cannot keep customer’s sensitive information e.g. name,
 Team involves 3 SIT testers, an architecture leader from surname and id outside of Thailand. As a consequence, a
the vendor who establishes software architecture design special HTML/Ajax control was developed which maps all
support of upcoming user and business needs and sensitive information kept in Cloud and the bank. The control
helped developers when required. Subject matter is developed and can be reusable on all screens. The bank
experts: three domain experts each for processing, utilized the ‘Mapper’ server using Java and Spring Framework
underwriting and closing who can evacuate doubts or developed in Stage 1 to keep the real customer information
give a rapid opinion as required by developers. (see Fig. 2) and interface with the bank internal systems via
Different users carried out this role during the MQ. Secondly, during the reflection workshop carried out at
development depending on the issue under review. A the end of the present iteration, different code conventions
dedicated team for BRE was also provided to deal with were specified and refactored to facilitate maintenance and
all underwritings and A-Score models. readability of the code. As a result the iteration was finished
17/08/2012, 19 working days delay.

66 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

automatically when underwriter approved. The loan


application will be delivered to appraisal unit, once having an
appraisal approved. The system initiated the process of
finalizing documentations and printing between the bank and
customer i.e. insurance, contract and cheque.
There were challenges in this iteration resulting in 48 days
delay. With underwriting development (20 days delay), as data
model was from the previous processing unit. However, the
underwriters can add comments and adjust all fields resulting
in 225 input fields appeared on screen (see Fig. 5). In addition,
auto population of historical data (e.g. statements, debt, and
insurance) via 7 interface bank systems was requested to
reduce their time to key-in in one single page. Nonetheless,
midway development underwriter users were informed on
performance issues with HTML streaming and interface time
(time > 3 seconds), so data grouping was proposed. UI was
redesigned collaboratively with users where all input fields
Fig. 2. Architecture of the System
were groups into 3 tabs: customer (name and address,
B. Iterations 2 (Application Processing) guarantor), finance (income, debt) and loan (mortgage term,
rate, installment amount) information. Once, the user wants to
The second iteration started on 25/07/2012 to 03/09/2012 view or edit then they can click each tab individually to
with an incremental on top of the previous iteration, improve loading time of less than 3 seconds. For interfacing
developers enhanced features: 1) employee loan and employee issue, a manual click was proposed and accepted with seven
search capability (edit, delete, and add) which can be reused in interface buttons provided for users to enquire when needed.
all screens. 2) Borrower search with edit, delete, add and
online information retrieval of related loan and customer With the closing state, there were resource and technical
details resided in old mortgage application as data migration is problems with the development of legal contracts. Not
not implemented and 3) validation for previous screen input knowing before, the BPM tool the bank bought is not
fields were done. sufficient in generating documents. There were over 140 legal
contracts in mortgage loan. So, legal contract users were
To enhance business value, the iteration developed routing trained to use iReport and designed the contracts which fulfill
capability which is to deliver task to designed users and unit. legal compliances such as font size, paragraph, margin and
In addition, all managers can track and store for key etc. Additional developers also were employed. Technically,
performance indicators (KPIs). So the manager can analyze loan data was kept in Cloud and real time data was required.
process performance as well as create service level agreements So a dedicated web-service server was used to transfer loan
(SLAs). However, a challenge of this iteration is that data from Cloud to the on-premise report server (see Error!
processing a mortgage loan, there were over 180 input fields Reference source not found. circled numbers 2 and 4). It was
in one page such as pricing plan detail, fee detail, insurance also found out that legal contracts consumed JVM memory, as
service, payback plan, guarantor, secure collateral types i.e. each loan requires 30 legal contracts at least. As a result, a
land and building, deed, condominium, debenture, bond and dedicated server was provided with 2 JVMs inside. The
etc. These field values were highly inter-related and iteration was once finished but during the iteration review,
significant for the loan outcome. Therefore, developers business executives requested a flow change (delete of
required business knowledge, times for develop and unit test. appraisal manager), they were not cognizant of the impact
On this iteration, prior to the delay 5 additional users came these changes would have on the project budget or timeline,
into help after office hour to test and identify missing leading to significant tension across the project teams.
requirements on the screen and validation rules and prevent
further delay. Nevertheless, due to business complexity of all D. Iterations 4 (User Management and Change of Condition)
fields, the iteration faced 18 days delay and completed in The fourth iteration started on 05/09/2012 and finished on
03/09/2012. 19/12/2012 19/12/12 taken 76 days. By then, the team
C. Iterations 3 (Underwriting and Closing) understood many requirements of housing loan and in a
continuous improvement, favoring a high team motivation.
This iteration was carried out from 23/08/12 to 13/11/12 Another module was developed to handle user profile
(58 days). Two main processes were developed where management, which defines allowed access rights, authority
underwriter officer approved the loan will be routed to loan levels, skills, approval limits, department, views and outcomes
closing unit. In this project underwriter officers’ main tasks by profile of different user groups. This is used to control
include: 1) calling the borrower about his/her income, wealth, startup features for the user's screen and session, the types of
credit history; 2) verifying borrower information with third authorized approval limit and screen that s/he can operate.
parties such as social security department, other banks and
employers via phone and online government website; and 3) The late part of business process is the ‘change of
approving or overriding the underwriting result (risk analysis, condition’. The purpose of change of condition is to enable
see Section 4.4). Loan closing process which is triggered any information adjustment of the latest approved loan such as

67 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

details of customer, finance and loan. The business process dedicated agent node and SFTP was utilized (see Fig. 2 circled
starts by allowing users to search by borrower or loan number 6).
application number. System will return the latest approved
loan application for the borrower or the loan. But specific TABLE III. PARTIAL EXAMPLE OF APPLICATION SCORE MODEL
complication arose as a ‘change in requirement’ when
Credit score
validation required recursive search whether all the related Low Medium High
parties (borrower, borrower-spouse, authorize signature Mortgag
% of % of % of
person, all the parties in collateral) in the latest application e and % of % of % of
Mea Med scor scor scor
characte char char char
having any in-progress loan application within the bank. For ristic
n ian
acter
e
acter
e
acter
e
example, a borrower may be a co-borrower or a guarantor in rang rang rang
istic istic istic
multiple loans. So, a change of borrower’s name should not e e e
Loan-to-
impact other loan. After retrieving all results in the value
background of the latest loan, all data will be auto-populate, ratio (%)
users can register the change of condition loan process with < 81 817 842 3.8 86.8 8.2 85.5 88.1 86.8
minimum to key-in and validation is ensured. After, the loan 81 to 90 801 821 3.7 12.6 8.8 13.6 87.5 12.6
operation reiterates the same steps as 4.1 – 4.3. Due to > 90 770 782 3.4 0.6 12.8 1 83.9 0.6
complexity of this recursive validation requirement, the Loan size
project tried multiple ways to achieve the objective and stress 2M 814 840 4.4 44.2 8.3 37.7 87.3 37.5
tests to prevent future system failure. Hence, the iteration was 2 M –5 M 812 836 3.9 39.1 8.7 39.9 87.5 37.8
delayed 76. >5M 819 840 2.6 16.8 7.6 22.4 89.8 24.7
Location
E. Iterations 5 (Risk Analysis and Interface) characteri
stic
The fifth iteration started on 16/07/2012 and finished on ZIP code
18/03/2013 taken 176 day. However, every two weeks some < 80 788 811 5.5 13.4 12.6 13.9 81.9 8.5
rules and interfaces were delivered in accordance with the 80 to 120 811 836 4.2 52.9 8.6 50.1 87.2 47.5
previous iteration sprints. Significant usages of BRE are used > 120 824 847 2.9 33.6 6.9 36 90.1 44.1
to empower business users to quickly create and manage …. …. …. …. …. …. …. …. ….
underwriting rules with minimal involvement from IT staff. The SFTP file integration with other systems was executed
To facilitate the mortgage underwriting process, reduce costs, last, as these was between system to system and the
and promote consistency for all loans, ‘‘credit scoring’’ assumption that business application needed to be processed
models have been developed that numerically weigh or correctly first. However, during the test, it was continuously
‘‘score’’ some or all of the factors considered in the detected by related systems that our interface data caused their
underwriting process and provide an indication of the relative systems to collapse regularly. For examples with the insurance
risk posed by each application (see TABLE III). At the time, system, firstly, date of birth need to be in Christian year
the bank’s mortgage underwriting rules had over 2,600 rules. format “yyyy-mm-dd”. So, the software needed to convert the
So, four dedicated developers and three business users Thai data before transferring.
involved in the underwriting and analytic score development.
BRE and its complex calculations were also involved such as Secondly, insured company document identification
loan to value, loan term, loan history, delinquent and etc. number needed to be 13 digits, so there was a need for screen
During the development, we also found with many accounts formatter and validation to ensure users have entered data
and debt history can result in a long processing. So, a correctly. Thirdly, KYC Level the system needed to set a
dedicated BRE server was employed (see Fig. 2 circled default level value at 100 (low risk). Fourthly, in the case of
number 5). selecting a life insurance of a particular company, we needed
to set a sum insured to be greater than 0. These file
In the loan process, there were needs for real time online integrations significantly impacted the project timeline, as
integration with 13 external systems and databases such as meetings and agreements with IT and business owners were
credit bureau, deposit, debt, fraud and so on. The application required to agree upon the inputs and signed-off. These
controlled the response sent in turn to a response received systems have some regulations that they have to comply and
from bank systems via web service. Information was mapped cannot change. As a result of these new findings, various parts
directly to loan application properties or parsed and of the software were revised e.g. data format and types,
transformed. The application servers served as the endpoint business rules and screens. SIT, UAT and regression tests
for an external connection—as a means to provide data to were done resulting in 124 days delay in total.
other systems (see Fig. 2). Additionally, at night time, for non
real time data mortgage system sent/received file integration V. EVALUATIONS OF SCRUM AND MORTGAGE
via SFTP with external systems e.g. enterprise data warehouse APPLICATION
(EDW), insurance, human resource, anti-money laundry and
etc. Time was also a constraint as users finished work at The research aimed to answer five areas: 1) project
midnight only 6 hours permit to complete file transfer. As performance with schedule and cost; 2) management
there were many loan applications only new and updated loans acceptance; 3) customer relationship; 4) team satisfaction and
information were extracted and sent to the external systems. A 5) usability acceptance.

68 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

For project performance, TABLE IV shows actual effort median value is shown circled in the middle of the line; the
and duration, the last column highlighted differences from the 95% confidence levels are shown by the opening and closed
plan. The actual efforts were over two thousands man hours points. These limits mean that we can be 95% certain that true
(33%) more than estimated and 200 days delayed resulting in scale median for the software can be found. LOS made the
300,000 USD over budget. Therefore, top senior management circles over 50% line, except for the Efficiency scale showing
decided that in the next phase a turn-key project managed by a that users felt the software and navigation were complicated.
vendor will be utilized in order to manage the cost. Agile will
no longer be favored.

TABLE IV. ACTUAL EFFORT AND DURATION


Act.
Durati Act.
Plan Durati Diff
Process on Work
(hr) on (hr)
(day) (hr)
(day)
Application
1,332 16 420 35 912
Registration
Application
720 12 774 29 -54
Processing
Underwriting
480 11 4,164 59 -3,684
and Closing
User
Management
2,256 32 790 76 1,477
and Change of Fig. 3. SUMI Result
Condition
Risk Analysis The main conclusion for each of the Sub-scales is
2,736 52 3,885 176 -1,149
and Interface
summarized in TABLE V.
Total 7,524 123 10,033 375 -2509
TABLE V. SUMMARY OF SUMI RESULTS
A week after the production date (3/06/2013), assessment
to find customer relationship and team satisfaction with Agile, Subscale Main Results
an interview with project sponsor, was conducted. She was
happy with Agile as its approach promoted teamwork,
LOS was complicated to navigate. It required too many
facilitated the deliveries of periodic working software. interactions (text inputs, buttons and conditions) to
However, she was disappointed with the control over costs. achieve an intended task. The software is robust and
From working team (PM, Dev, BA, SME, testers) points of sufficient to work in a network environment. Even though,
Efficiency
views towards the project (with writing comments on sticky the software did take the issues of sensitive data into
note colored in green and red to represent ‘good’ and ‘no account, many of the save buttons were too many. The
good’), the result shows that developers liked the Agile users need to save of sensitive data for any modification
because of Cloud.
approach, new tool and office environment. They felt the team
was congenial (outsources and in-house developers) and were
comfortable on working and understanding with each other The users were satisfied with working with this software
despite language challenges. Developers felt SME and Affect and did not feel tense while using it. Still, the presentation
business leads are open to discussions, able to explain and needs to be improved.
clarify queries on existing business processes. However, the
team shared similar negative opinions: 1) high resource The interface is informative; most functions of menu and
turnover, resulting in substantial time and effort spent on Learnability buttons represented what it did quite clearly except for the
orientation and initiation of new resources; 2) There are many sensitive data.
situations where changes to requirements were made without
analysis and approvals from stakeholders “Better utilization of
The software was fast and robust. The user could move
time and effort could have been achieved if there was a more from one part to another fairly easily. However, there were
comprehensive process in assessing suitable resources”. Control
too many clicks and keystroke and the user felt they were
“Change management process needs further refining and not in control.
governance”; 3) Project status updates in weekly meetings
with senior management of outsource companies were often
The help file was informative but some texts were difficult
postponed. Helpfulness for the staff. The error and software messages were
In terms of interface usability evaluation, fourteen adequate. Each screen had its own help presentation.
participants, from all units, 7 males and 7 females, voluntarily
participated. Their ages ranged from 22 to 31 years with a From the SUMI questionnaire, LOS was usable (> 50).
mean age of 25 (std. = 0.48). LOS was given an overall Overall end users had no problem in operating the software.
usability of 58% which is considered above average. The other This indicated that interface’s factors such as clearly seen
factors met the standard requirement of usability scales (see buttons and layout of UI elements received positive feedback
Error! Reference source not found.). For each scale, the from the end users.

69 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

VI. DISCUSSION AND CONCLUSION new technology in any project implies certain inherent risks.
This paper aims to contribute with an understanding of Although, a training period to use BPM/BRE tool was carried
agile development failure in a large scale project, by out in Stage 2, it resulted insufficient; since there were areas
identifying learning lessons which may contribute to other of the tool to serve complicated mortgage requirements.
financial systems and other complex domains. Importantly, Special care was employed by side-by-side programming
this study shows that Agile and the project was not failed, but practice between local and outsource developers. This turns
due to political pressure on reducing the effort by senior beneficial to outsource as well for handling complex nature of
management (Stage 3) which aligned with previous studies [7] mortgage domain where multiple disciplines interact [1] and
[8]. Currently, Agile is not adopted by the bank as a result of specific Thai mortgage rules. It is therefore recommended that
effort, timeline and cost overruns. Waterfall model is currently local and foreign staff sitting together.
employed. However, TABLE VI shows that if using the initial Efficient communication is one of the key issues of Agile
estimated (last column); the total project effort was in a safe [3] and frequent delivery of tested working software in an
zone (over estimated by 1447 man-hours or 12%). Indeed, iterative way brought high visibility of project progress [10].
agile should have been adopted, if efforts were not determined The email update of bug fixes and project status update for
by senior management. every two weeks too all stakeholders give direct feedback to
development amelioration. This context helped to share the
TABLE VI. COMPARISON OF ACTUAL AND INITIAL PLANNING ‘big picture’ of the project state and to build a strong
Team camaraderie and team spirit, which definitely were the key
Process Political Actual
plan drivers to sustain focus and commitment during all stages.
1. Application Registration 1,332 420 440 Although, the SUMI score was adequate, a range of
2 Application Processing 720 774 380 interface problems was uncovered. Firstly, the major problem
480 4,164 3,296
arising from the SUMI analysis related to the ‘Efficiency’
3 Underwriting and Closing scale (46%). It was found that the users were required to key-
4 User Management and
Change of Condition
2,256 790 502 in substantial data in one single page, check data
5 Risk Analysis and synchronization between tabs and sections in order to
2,736 3,885 6,862 complete the procedure. For example, firstly, in financial data
Interface
Total 7,524 10,033 11,480 section, users were not allowed to step next if they had not
completed typing in eight tabs of the account. Secondly, the
Even though, one of the main principles of agile methods application instructed the user to save sensitive information in
is to “welcome changing requirements” [4] [7] [12] however many places (see Fig. 6). In the next version of LOS in terms
this research showed that changing requirements especially of Efficiency scale, therefore the software will minimize the
with technically complicated challenge (Iteration 4) can number of save button. Also, collapsible section will be used
contribute to extended timeline and cost [9]. The project (see Fig. 7) without displaying all fields1. This may reduce the
appeared to have timeline and budget is strictly determined by user perception that they have to key-in all.
senior management, then it implies that working over-time is
One of the limitations of this research study was the
mandatory. In this project, developers worked over-time on a
constitution of the sample i.e. mortgage application specific.
regular basis to meet the political forced timeline. Their efforts
Nonetheless, mortgage was only part of the activities of this
were mostly un-clocked and un-billed to help the project and
research in agile development where an institute attempted to
team. Therefore, the actual hours of over-time were not
adopt Agile. BPM/BRE tool used is proprietary where line of
recorded. Consequently, six outsources and two local staff
code cannot be counted to assess software size. Additionally,
resigned adding problems to the project.
from the authors’ knowledge, the BPM/BRE cloud-based loan
Rigid timeline increased pressure, when timeline is origination system is the first experience in the world. So in
restricted, poor planning and analysis of related interface terms of Koch Agile evaluation [10] there is no benchmarking
systems (Iteration 5) were not focused causing re-works available to compare in terms of speed of delivery, software
significantly and miss of timeline for the project. Future size, performance, robustness or adaptation of Agile in
empirical research is needed to investigate under which related banking industry. Therefore, the results might not generalize
interface systems and their messages should be reconciled in to other agile development, particularly those in different
terms of their required fields to avoid reworks and delay of culture or free of political influences.
project. For example, if a middle named is a required field in
While the need for agile approach has been widely
a customer information system, then the field is a required
recognized, making an agile approach work in a long
field in mortgage system.
established waterfall bank is challenging. A number of
As reported in the PMKBOK [4] lack of fulltime SME recommendations can be drawn; firstly even a political
staff was an important side effect of the detected problems pressure on the effort estimated by the developers, still in the
(Stage 1), leading to project delays and failure. Besides, the end the actual effort reflects the early estimate. Secondly,
previously mentioned problems potentially linked to political inexperience developers may not be able to design a core
force and project management, there were additional engine of BPM/BRE for the bank. Tool may be needed.
difficulties during software development. At the beginning of
Stage 3 of our project, the local team was novice. Employing 1
At the time of this writing, it has been implemented as a result of SUMI and
interviews where users requested for screen redesigned changes

70 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

Thirdly, constantly changing requirements increases [11] K. G. Royce, "Integration of a Business Rules Engine to Manage
difficulties and workload during development where timeline Frequently Changing Workflow: A Case Study of Insurance
Underwriting Workflow," in Americas Conference on Information
cannot be changed producing a significant dissatisfaction from Systems, Colorado, 2007.
developers and the sponsor. The research revealed several [12] A. S. Koch, Agile Software Development Evaluating the Methods for
paradox-like phenomena that need further research and Your Organization, Boston: Artech House, 2005.
investigation. The agile method was found feasible in a large [13] T. Silva, M. Silveira, F. Maurer and T. Hellmann, "User Experience
project; within the team Scrum was highly effective in Design and Agile Development: From Theory to Practice," Journal of
rescuing this mortgage web-based project. The use of Scrum Software Engineering and Applications, vol. 5, pp. 743-751, 2012.
resulted highly positive at working team since it improved the [14] A. Narasimhadevara, T. Radhakrishnan, B. Leung and R. Jayakumar,
communication between team members and as a consequence "On Designing a Usable Interactive System to Support Transplant
Nursing," Journal of Biomedical Informatics, vol. 42, p. 137–151, 2008.
increases the team flexibility and productivity and maintaining
focus on those tasks more relevant to the project. [15] G. G. Angel, PMP Certification A Beginner’s Guide, New York:
McGraw-Hill, 2010.
ACKNOWLEDGMENT APPENDIX
The author is very grateful to Anders Markvardsen for
continued reviews of this paper.
REFERENCES
[1] [Link], D. Levy and D. Levine, "A Case Study of the Mortgage
Application Process”," in Mortgage Lending Discrimination: A Review
of the Evidence, Washington DC,, Urban Institute Press, 1999, pp. 137-
160.
[2] R. Avery, R. Bostic and P. Calem, "Credit Risk, Credit Scoring, and the
Performance of Home Mortgages," Federal Reserve Bulletin July 1996,
Washington, 1996.
[3] L. Williams, "What Agile Teams Think of Agile Principles,"
Communications of the ACM, vol. 55, no. 4, pp. 71-76, 2012.
[4] B. Jordan, J. Giboney, M. Keith, J. Mark, D. Wilson, R. Schuetzler, P.
Lowry and A. Vance, "Overview and Guidance on Agile Development
in Large Organizations," Communications of the Assosiation for
Information Systems, pp. 25-44, July 2011
[5] H. Mohammad, T. Alwada and J. Ababneh, "Agile Software
Methodologies: Strength and Weakness," International Journal of
Engineering Science and Technology, vol. 5, no. 3, pp. 455-459, 2013
[6] D. Batra, W. Xia, D. VanderMeer and K. Dutta, "Balancing Agile and
Structured Development Approaches to Successfully Manage Large
Distributed Software Projects: A Case Study from the Cruise Line
Industry," Communications of the Association for Information Systems,
vol. 27, no. 21, pp. 378-394, 2010.
[7] J. Wan, [Link] and M. Zeng, "Case Study on Critical Success Factors of
Running Scrum," Journal of Software Engineering and Applications,,
vol. 6, pp. 59-64, 2013.
[8] M. Santos, P. Bermejo, M. Oliveira, A. Tonelli and E. Seidel,
"Improving The Managment of Cost and Scope in Software Projects
using Agile Practices," International Journal of Computer Science &
Information Technology, vol. 5, no. 1, pp. 47-64, 2013
[9] S. Keaveney and K. Conboy, "Cost estimation in Agile Development
Projects," in ECIS, 2006.
[10] S. Kruba, S. Baynes and R. Hyer, "BPM, Agile, and Virtualization
Combine to Create Effective Solutions," International Journal of
Advanced Computer Science and Applications, 2012.
Fig. 4. Three Tier Architecture of Mortgage Application

71 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

Fig. 5. Screen Example

72 | P a g e
[Link]
(IJACSA) International Journal of Advanced Computer Science and Applications,
Vol. 5, No. 9, 2014

Fig. 6. Save Buttons

Fig. 7. Collapsible Sections

73 | P a g e
[Link]

You might also like