Cas Study: th Us of Agil on Mortgag Application: Evidnc from Thailand Krcha Puphaiboon Faculty of Computr and Information Tchnology Kasm Bundit Univrsity Bangkok, Thailand Abstract This papr prsnts a cas study of a mortgag loan origination projct using SCRUM Agil modl and Businss Procss Managmnt and Businss Rul Managmnt Systm (BPMS and BRMS). From th Watrfall modl (Stag 1), a wbbasd slf-dvlopd had bn dvlopd using opnsourc framworks: Spring and Sarasvati. But, svral problms wr dtctd and th projct faild du to insufficint projct managmnt, rapid rquirmnt changs and dvlopr coding skills. Th projct was continud (Stag 2) slcting a BPMS and BRMS tool. Latr, Stag 3 SCRUM was xcutd with propr projct managmnt and th nw tool, which suitd bttr for rapid businss nds, and minimum coding. An fficint tam communication and th frqunt dlivry of cod rlass incrasingly contributd to th sponsor and usr s satisfaction. Howvr, du to political influncd timlin, inxprincd projct managmnt and rquirmnt changs, th budgt xcds and SCRUM is not favord. Nonthlss, Opn-nd qustionnair and intrviw rsults with cor tam mmbrs both businss usrs and dvloprs as wll as softwar usability masurmnt invntory (SUMI) conductd with 14 usrs, it shows that SCRUM and th nw tool rscu th projct. Empirically, this papr dmonstrats a mthod to valuat th us of Agil augmntd with usability masurmnt to Agil dvlopmnt community. Kywords SCRUM; BPM; BRE; Mortgag Loan; LOS; Usability I. INTRODUCTION Mortgag loan origination procss is complx, although common procss flows ar: Application, Procssing, Undrwriting, Closing and Post Closing [1]. Howvr, a systm that can handl a larg numbr of Loan numbrs is hard to find. In addition for IT, th prssur to rvis flows, policy changs and crdit risk calculations in a fw days and automatically mak corrct lnding dcisions has bn a grat challng in rtail banking [2]. Thr's no room for customr and financial information and loan procss rrors as banks nd to hav crtain confidnc in vry lnding dcision. Agil s principls ncourag th formation of collaborativ and slf-organization tams [3]. Th Agil Manifsto is as follows: 1) Individuals and intractions ovr procsss and tools. 2) Working softwar ovr comprhnsiv documntation. 3) Customr collaboration ovr contract ngotiation. 4) Rsponding to chang ovr following a plan. Howvr, a continual dbat surrounds th ffctivnss of agil softwar dvlopmnt practics. Som organizations adopt agil practics to bcom mor comptitiv, improv softwar dvlopmnt procsss, and rduc costs. Othr organizations ar skptical about whthr agil dvlopmnt is bnficial. Additionally, larg organizations fac an additional challng in intgrating agil practics with xisting standards and businss procsss [4]. Whilst it is gnrally accptd that SCRUM dvlopmnt improvs th cost rduction and it hlps to acclrat th softwar product to th markt. Importantly, it improvs customr satisfaction [5] [6]. Howvr, no fild studis rsarch has bn rportd whn Agil and SCRUM is first bing usd in a larg organization in Thailand. Rsarch [5] mntiond factors to run Scrum in alignd with PMP BOK principls (s Tabl I). Hnc, th rsarchr wants to study and rport th usag of Agil/SCRUM to satisfy businss nds and assss th impacts ovr th IT dvlopmnt an xampl for softwar nginring community. TABLE I. stp 1. 4, oftn th projcts hav bn assignd with th timlin [6]. Political forcs at work within a projct or company can oftn driv stimation inaccuracy [8]. This is usually in th form of managrial prssur to stay within or mt th stimat timlin [8]. Th stimation procss can b impactd ngativly by ths prssurs rsulting in projct timlin or cost constraints [8] [9]. Th rat of chang in businss and bank is acclrating [1] [2]. A numbr of tchniqus for addrssing that chang hav mrgd indpndntly to provid for automatd solutions in this nvironmnt. Businss Procss Managmnt (BPM) and Businss Rul Engin (BRE) that ar larg as wll as distributd ar bcoming mor prvalnt [10] [11]. Both tchnologis tnd to offr th promis of asy to chang. As chang is common in larg projcts; th cas whr th ntirty of a projct s complxity is undrstood in th arly stags is quit rar. Larg, distributd projcts that involv usr rquirmnts prsnt a uniqu challng that nithr agil mthods nor watrfall approachs alon can ffctivly addrss. Hnc, combining an ffctiv softwar dvlopmnt tool with agil procss may b vry bnficial. Koch [12] has proposd thr critria for valuating th ffctivnss of th agil mthod adoptd: 1) projct prformanc with schdul prformanc and budgt prformanc; 2) managmnt accptanc; 3) customr rlationship and 4) tam satisfaction. Howvr, usability was not includd. Thus, it is important to valuat all ths fiv critria for agil adoption for which thy wr dsrvd. I am thankful to Kasm Bundit who has sponsord this rsarch 63 P a g
TABLE I. THE KEY PROCESSES OF RUNNING SCRUM Th ky procsss of running scrum 1. Dtrminat phas 2. Planning phas 3. Start-up phas 1.1. Dvlop th ral rquirmnts of customrs; 1.2. Writ a on pag projct dscription; 1.3. Rcod th rquirmnt of customrs; 1.4. Gain th snior managrs prmission to run th projct; 1.5. Discuss how to mt th rquirmnts with th customrs. 4. Suprvision and control phas 4.1. Build th running and rporting systm; 4.2. Rport th schdul; 4.3. Suprvis th running; 4.4. Dal with th rqust of scop chang; 4.5. Suprvis th risks; 4.6. Idntify and solv th problms. 2.1. Dfin all th work of th projct; 2.2. Establish th schdul of initial projct; 2.3. Assss th tim rquird to complt th projct; 2.4. Analyz and adjust th projct schdul; 2.5. Assss th rsourc rquird to complt th projct; 2.6. Writ th risk managmnt plan; 2.7. Assss th whol cost of th projct; 2.8. Rcord th projct plan; 2.9. Sort th work in chronological ordr; 2.10. Gt th snior managmnt s prmission to start th projct. 5. Dcidd to start th itration phas 5.1. Dcision-making procss for customr managmnt; 5.2. Customrs must b fully involvd in this procss; 5.3. Th atmosphr must b complt opn and honst; 5.4. Dtrmination must bas on th xpctd commrcial valu; 5.5. Solution must b formd according to th projct s goal. 3.1. Rcruit projct managr; 3.2. Build th scop chang managmnt procss; 3.3. Rcruit th projct tam mmbrs; 3.4. Manag th tam communication; 3.5. Writ th dscriptiv documnt of projct; 3.6. Dtrmin th schdul; 3.7. Build th tam oprating ruls; 3.8. Writ th work packag. 6. Closout phas 6.1. Gt th confirmation of th customr; 6.2. Prpar for th dlivrabls and installations. 6.3. Writ th closout rport; 6.4. Start th audit of th running. Agil and usability aim to build quality softwar. As notd in rsarch [13], agil and usability th two mthods hav much to offr whn thy shar itrations bcaus th itrations usd in agil facilitat usability tsting and allow dvloprs to incorporat rsults of ths tsts in subsqunt itrations. Howvr, rsarch [13] commntd that improving th usability of a product dos not com without costs. In ordr to intgrat agil and usability and at th sam tim minimiz ths costs and risks, w nd th us of usability artifacts and practics in a condnsd form. SUMI for Softwar Usability Masurmnt Invntory is commonly usd for usability valuations [14]. SUMI consists of ovr 50 qustions; it is mthod of masuring softwar quality from th nd usr's point of viw. Thr is a nd of usability masurmnt intgratd with agil mthodology to dtrmin whthr th softwar supportd mortgag loan nds or any domains. This articl prsnts th cas of mortgag loan origination projct calld LOS. Th purpos of LOS was to rplac an xisting mortgag application as thr wr problms such as: lgacy application (ovr 15 yars old), lack of Powr Buildr dvloprs to support, difficulty in changing businss flows, incapabl of scalability and prformanc issu. Thr wr ovr 8,000 usrs using th mortgag systm, roughly around 500 concurrnt usrs across th nation. Thr ar nds for nw application with faturs: asy-to-chang, wb-basd and scalabl, usr to mak routin changs. Also, th mphasis is on IT to hav a fast dlivry of th softwar application to compt with markt trnds and attract customrs, th fastr th dlivry of softwar ar th chancs that th bank will gain profits. Not that th writr is th tchnical managr of this projct. Th bank is rankd in th top fiv banks in Thailand. Th rvnu of mortgag loan was ovr 1 billion us dollars in yar 2012. So, it is a highly critical systm for th bank. Th papr is structurd as follows: Sction 2 prsnts th dvlopmnt stags of dlivring a prototyp, including dtctd problms. Sction 3 xplains ways in which BPM/BRE tools wr slctd. Sction 4 dscribs th full dvlopmnt SCRUM modl and som proprtis of th mthodology ar summarizd of th systm and its itrations. Sction 5 shows tam commnts on Agil/SCRUM bas on qustionnair and fdbacks via Sticky Nots and usr xprinc assssmnt to th softwar via SUMI usability qustionnair. Lsson larnd and conclusions ar prsntd in Sction 6. II. STAGE ONE OF MORTGAGE APPLICATION PROTOTYPE SELF-DEVELOPMENT Using Watrfall modl, th dvlopmnt of wb-basd mortgag application th projct was initiatd (2011 2012) timlin and main tasks wr plannd by snior managmnt with four months for ach stp of rquirmnts, coding and UAT tsting. Two main rprsntativs of businss usrs wr givn. Rquirmnt gathring in Jun Sptmbr 2011, thr wr 18 main flows from start to finish ntir loan procss.g. data ntry, managr, crdit approval officr, crdit approval managr, lgal contract and lgal managrs. Th dirction was to usd opn-sourc framwork and in-hous dvlopmnt th J2EE, Spring Framwork (2009) and Sarasvati proposd by IT dvloprs. Spring is usd to handl simultanous runs and as an intrfac to databas DB2 (s in Appndix for Fig. 4). Th dvlopmnt ffort was plan roughly for 14,400 man hours for th ntir projct for on projct managr, two businss usrs, 10 Java dvloprs (avrag xprincd 3.5 yars) and 3 tstrs. Th budgt was 180,000 USD. Application dvlopmnt was carrid out in Octobr 2011 - January 2012, but diffrnt problms thratnd th projct continuity. Considring th SIT was unabl to finish within 64 P a g
th first two month (1 month dlayd) du to numrous bugs. Th tam had difficultis to follow dfind plans and th snior xcutivs wr unsatisfid with th progrss of th softwar dvlopmnt aftr 6 months. Th following main dficincis wr dtctd: Dficint projct managmnt and communication; projct managr, domain xprts and nd usrs wr prsnt only six-hours pr wk. Thy also sit in diffrnt buildings with IT dvloprs. Tlphon and -mail wr usd. Ths mans did not rsult fficint whn problm arisn and nd immdiat action from BAs. Rquirmnts wr broad without nough dtails and cannot intgrat ntir flow. For xampl, dtails of diffrnt collatral typs btwn two units ar not in sync (procssing and undrwriting). Thrfor, most of th coding tasks rquird impact analysis, modifications and r-implmntations, causing continuous dlays to th dvlopmnt procss. Th implications ar poor chang control, dvloprs softwar dsign skill and softwar framwork to adopt dynamic changs. Th dvlopr statd that complicatd flow, businss rul calculations and changs wr th root caus of failurs. Th objctivs of slf-dvlop wb application projct wr clarly not mt. Significantly th budgt was xcdd by 60,606 USD. Aftr a mting btwn th tam and xcutivs (CFO, COO and CIO), all dcidd to discontinu th slf-dvlopmnt. CIO advisd th projct to acquir BPM and BRE tools which support dvlopr to cod as lss as possibl and usrs can manipulat th flow and ruls within th systm. This is to downgrad possibl failur risks. Importantly, th tam rqustd accss to th xprt usr on a daily and full-tim basis. III. STAGE TWO OF MORTGAGE APPLICATION SELECTING AND ASSESSING THE TOOL On Fbruary 2012 th BPM and BRE Vndor Slction was xcutd. Th top product listd in Gartnr and Forrstr ranking rports wr invitd. Importantly and practically, two wks of POC projct to build almost half of an ntir mortgag procss arisn from Stag 1 including SIT and UAT wr conductd. Morovr, strss tst with 500 concurrnt usrs was conductd and passd 3 sconds rspond tim critria. Dvloprs and usrs from th bank also involvd in th dvlopmnt as wll as valuation of th softwar. This is to prov that th slctd BPM/BRE framwork providd softwar flxibility for fast dvlopmnt without much coding and as of chang whn usrs want to chang various calculation schms. For nd usrs, thy apprciatd th fact that thy can input dcision ruls and th softwar provids frindly and intuitiv scrns for usrs. Anothr additional bnfit for dvloprs is that th softwar supports Agil dvlopmnt: 1) usrs can draw flow and dsign scrn with dvloprs in ral tim without coding this hlps to improv businss gaps with usrs; 2) flows and ruls can b drawn/changd without coding; and 3) rquirmnts and documnts ar savd in th systm so dvloprs can idntify changs. Anothr bnfit for th bank is that financially, 5 Yar Total Cost of Ownrship (TCO) is lss than othr products. Th product also offrs Cloud Amazon EC2 srvic, thus it lvrags maintnanc agility and invstmnt cost. 5 yar TCO of th projct is around 10 million US dollars. But for mortgag application is fundd with 1.5 million USD whr outsourc dvloprs budgt is around 330,000 USD. Tim-and-Matrial contracts and Labor Hour (LH) contracts ar usd. Thr wks of training was also providd to local staff including businss analysts. IV. STAGE THREE OF MORTGAGE APPLICATION APPLICATION OF SCRUM On Jun 2012, th Stag 2 of th softwar dvlopmnt finally startd. As it was larnt that rquirmnt documntation was not clar, hnc th rdocumntation/rquirmnt wr capturd and put dirctly into th systm. Two wks priod with multipl sssions capturd th dtails of th us cass and flow which giv th projct tracability and dtrmin application rquirmnts. During th rquirmnt gathring, a clos sating and dirct communication nvironmnt within a big room with a projctor, dsign sktchs and whit-board, nots and mockd up scrn wr conductd. Ths mtings focus on fficincy, gtting 2 subjct mattr xprts (SME) from 2 dpartmnts into th room to focus on th implmntation dtails of mocking up UI, validation of inputs and outputs and awar of ach othr impacts. Thy agrd up front on how th application procsss will work, avoiding costly rwork latr. Th outcoms dtrmind th numbr of itrations, sprints and ffort rquird for th projct. Du to businss confidntiality, Fig. 1 shows som of businss procss flow of Application Rgistration, Procssing and Undrwriting (without Closing and Post Closing). Mor dtails will b discussd in Sction 4.1 4.5. Th sizing ffort by dvloprs was producd with 11,480 man hours for coding and unit tsting (s Fig. 1 circld numbr 2) with total of 213 us cass (s som spcification blow in Fig. 1 circld numbr 3). Fig. 1. Flows of Mortgag Application 65 P a g
Howvr, TABLE II shows th output sizing sht and ffort for th projct which was influncd by th snior xcutivs to 7,524 man-hours (rducd 34%). Stps TABLE II. ITERATIONS PLAN AND SIZING EFFORTS Political Forcd Effort and Initial Effort in Man-Hour Nam Political Plan 1 Application Rgistration 1,332 440 2 Application Procssing 720 380 3 Undrwriting and Closing 480 3,296 4 Usr Managmnt and Chang of Condition 2,256 502 5 Risk Analysis and Intrfac 2,736 6,862 Total 7,524 11,480 In this projct, th systm dvlopmnt tam was intgratd by four groups with th following rols: Dvloprs: agil dfins spcific catgoris tam lad dsignr and programmrs. In this cas, thy wr cross-functional and allocatd dynamically dpnding on particular nds of th running itrations. Four dvlopr tams wr agrd btwn thr diffrnt vndors and th bank. 23 dvloprs wr ngagd and 16 wr outsourcs from India, Singapor and Hong Kong avragd 4.0 yars xprincd with th product. Highr numbr of outsourc th rason bing that bcaus bank staff had littl xprinc with th product. Product ownr is IT businss analyst lad managr: sh works with SME and usrs. Scrum mastr is tchnical managr who dos th cod rviw, rlas managmnt, ntwork, and scurity. H srvs as a rsourc to hlp th tams mak appropriat systm and componnt lvl dsign dcisions during implmntation. H dfins and split us cass and faturs for th program backlog, and allocating rspctiv itms to th individual tam for implmntation. Tam involvs 3 SIT tstrs, an architctur ladr from th vndor who stablishs softwar architctur dsign support of upcoming usr and businss nds and hlpd dvloprs whn rquird. Subjct mattr xprts: thr domain xprts ach for procssing, undrwriting and closing who can vacuat doubts or giv a rapid opinion as rquird by dvloprs. Diffrnt usrs carrid out this rol during th dvlopmnt dpnding on th issu undr rviw. A ddicatd tam for BRE was also providd to dal with all undrwritings and A-Scor modls. A daily "scrum" or standup mting was hld with all th stakholdrs. Evry day, dvloprs answrd thr qustions: 1) what hav you don sinc ystrday; 2) what ar you planning to do by tomorrow; and 3) Do you hav any problms prvnting you from accomplishing your goal. To satisfy quality assuranc of dvlopmnt, unit tst with captur scrns was applid by dvloprs and rviwd by businss lad. Frqunt dlivry and tst with vry two wks, a rlas was dlivrd to SIT nvironmnt with bug fixs and nw faturs in product backlog. For fast tsting, QTP was usd as an automatd tsting tool. Onc a month, th product was rlasd to UAT and a mting with string committs was conductd to inform th status of bug fixs and projct status. This is to nsur that th tam and all stakholdrs hav rviwd th product and mt th xpctation. A. Itration 1 (Application Rgistration) Following th plan, a short first itration (15 days) was dsignd (02/07/12-23/07/12) but it was takn 34 days to complt - 19 days latr than plannd. This itration involvs th first thr columns in Error! Rfrnc sourc not found.1 whr usrs rgistr a mortgag application with th barcod and confirm application cration. Th data ntry prson will ntr customr information from a hard copy documnt and us th citizn idntification to intrfac with National Crdit Burau and obtain th crdit scor rsult which will b usd latr in undrwriting calculation. Usr can chck and sarch if th borrowr or co-borrowrs information xist in th cor bank systms, if so rtriv all th information. Onc compltd, thy can snd to th suprvisor whos rol is to rviw and rvis wrong/missing data givn by thir staff. Latr, if rquird thy can submit th work to anothr unit whos rols ar to commnt and rcord missing data or documnt for furthr analysis of sal sufficincy. Thy also nd to follow up with sals or customrs about th missing information. Th first intgration of th GUI prsntation layr with th bank systms was achivd as a working softwar dlivry. Howvr, thr wr two factors which affctd this itration timlin. Firstly, Bank of Thailand rgulation stats that th bank cannot kp customr s snsitiv information.g. nam, surnam and id outsid of Thailand. As a consqunc, a spcial HTML/Ajax control was dvlopd which maps all snsitiv information kpt in Cloud and th bank. Th control is dvlopd and can b rusabl on all scrns. Th bank utilizd th Mappr srvr using Java and Spring Framwork dvlopd in Stag 1 to kp th ral customr information (s Fig. 2) and intrfac with th bank intrnal systms via MQ. Scondly, during th rflction workshop carrid out at th nd of th prsnt itration, diffrnt cod convntions wr spcifid and rfactord to facilitat maintnanc and radability of th cod. As a rsult th itration was finishd 17/08/2012, 19 working days dlay. 66 P a g
Fig. 2. Architctur of th Systm B. Itrations 2 (Application Procssing) Th scond itration startd on 25/07/2012 to 03/09/2012 with an incrmntal on top of th prvious itration, dvloprs nhancd faturs: 1) mploy loan and mploy sarch capability (dit, dlt, and add) which can b rusd in all scrns. 2) Borrowr sarch with dit, dlt, add and onlin information rtrival of rlatd loan and customr dtails rsidd in old mortgag application as data migration is not implmntd and 3) validation for prvious scrn input filds wr don. To nhanc businss valu, th itration dvlopd routing capability which is to dlivr task to dsignd usrs and unit. In addition, all managrs can track and stor for ky prformanc indicators (KPIs). So th managr can analyz procss prformanc as wll as crat srvic lvl agrmnts (SLAs). Howvr, a challng of this itration is that procssing a mortgag loan, thr wr ovr 180 input filds in on pag such as pricing plan dtail, f dtail, insuranc srvic, payback plan, guarantor, scur collatral typs i.. land and building, dd, condominium, dbntur, bond and tc. Ths fild valus wr highly intr-rlatd and significant for th loan outcom. Thrfor, dvloprs rquird businss knowldg, tims for dvlop and unit tst. On this itration, prior to th dlay 5 additional usrs cam into hlp aftr offic hour to tst and idntify missing rquirmnts on th scrn and validation ruls and prvnt furthr dlay. Nvrthlss, du to businss complxity of all filds, th itration facd 18 days dlay and compltd in 03/09/2012. C. Itrations 3 (Undrwriting and Closing) This itration was carrid out from 23/08/12 to 13/11/12 (58 days). Two main procsss wr dvlopd whr undrwritr officr approvd th loan will b routd to loan closing unit. In this projct undrwritr officrs main tasks includ: 1) calling th borrowr about his/hr incom, walth, crdit history; 2) vrifying borrowr information with third partis such as social scurity dpartmnt, othr banks and mployrs via phon and onlin govrnmnt wbsit; and 3) approving or ovrriding th undrwriting rsult (risk analysis, s Sction 4.4). Loan closing procss which is triggrd automatically whn undrwritr approvd. Th loan application will b dlivrd to appraisal unit, onc having an appraisal approvd. Th systm initiatd th procss of finalizing documntations and printing btwn th bank and customr i.. insuranc, contract and chqu. Thr wr challngs in this itration rsulting in 48 days dlay. With undrwriting dvlopmnt (20 days dlay), as data modl was from th prvious procssing unit. Howvr, th undrwritrs can add commnts and adjust all filds rsulting in 225 input filds appard on scrn (s Fig. 5). In addition, auto population of historical data (.g. statmnts, dbt, and insuranc) via 7 intrfac bank systms was rqustd to rduc thir tim to ky-in in on singl pag. Nonthlss, midway dvlopmnt undrwritr usrs wr informd on prformanc issus with HTML straming and intrfac tim (tim > 3 sconds), so data grouping was proposd. UI was rdsignd collaborativly with usrs whr all input filds wr groups into 3 tabs: customr (nam and addrss, guarantor), financ (incom, dbt) and loan (mortgag trm, rat, installmnt amount) information. Onc, th usr wants to viw or dit thn thy can click ach tab individually to improv loading tim of lss than 3 sconds. For intrfacing issu, a manual click was proposd and accptd with svn intrfac buttons providd for usrs to nquir whn ndd. With th closing stat, thr wr rsourc and tchnical problms with th dvlopmnt of lgal contracts. Not knowing bfor, th BPM tool th bank bought is not sufficint in gnrating documnts. Thr wr ovr 140 lgal contracts in mortgag loan. So, lgal contract usrs wr traind to us irport and dsignd th contracts which fulfill lgal compliancs such as font siz, paragraph, margin and tc. Additional dvloprs also wr mployd. Tchnically, loan data was kpt in Cloud and ral tim data was rquird. So a ddicatd wb-srvic srvr was usd to transfr loan data from Cloud to th on-prmis rport srvr (s Error! Rfrnc sourc not found. circld numbrs 2 and 4). It was also found out that lgal contracts consumd JVM mmory, as ach loan rquirs 30 lgal contracts at last. As a rsult, a ddicatd srvr was providd with 2 JVMs insid. Th itration was onc finishd but during th itration rviw, businss xcutivs rqustd a flow chang (dlt of appraisal managr), thy wr not cognizant of th impact ths changs would hav on th projct budgt or timlin, lading to significant tnsion across th projct tams. D. Itrations 4 (Usr Managmnt and Chang of Condition) Th fourth itration startd on 05/09/2012 and finishd on 19/12/2012 19/12/12 takn 76 days. By thn, th tam undrstood many rquirmnts of housing loan and in a continuous improvmnt, favoring a high tam motivation. Anothr modul was dvlopd to handl usr profil managmnt, which dfins allowd accss rights, authority lvls, skills, approval limits, dpartmnt, viws and outcoms by profil of diffrnt usr groups. This is usd to control startup faturs for th usr's scrn and sssion, th typs of authorizd approval limit and scrn that s/h can oprat. Th lat part of businss procss is th chang of condition. Th purpos of chang of condition is to nabl any information adjustmnt of th latst approvd loan such as 67 P a g
dtails of customr, financ and loan. Th businss procss starts by allowing usrs to sarch by borrowr or loan application numbr. Systm will rturn th latst approvd loan application for th borrowr or th loan. But spcific complication aros as a chang in rquirmnt whn validation rquird rcursiv sarch whthr all th rlatd partis (borrowr, borrowr-spous, authoriz signatur prson, all th partis in collatral) in th latst application having any in-progrss loan application within th bank. For xampl, a borrowr may b a co-borrowr or a guarantor in multipl loans. So, a chang of borrowr s nam should not impact othr loan. Aftr rtriving all rsults in th background of th latst loan, all data will b auto-populat, usrs can rgistr th chang of condition loan procss with minimum to ky-in and validation is nsurd. Aftr, th loan opration ritrats th sam stps as 4.1 4.3. Du to complxity of this rcursiv validation rquirmnt, th projct trid multipl ways to achiv th objctiv and strss tsts to prvnt futur systm failur. Hnc, th itration was dlayd 76. E. Itrations 5 (Risk Analysis and Intrfac) Th fifth itration startd on 16/07/2012 and finishd on 18/03/2013 takn 176 day. Howvr, vry two wks som ruls and intrfacs wr dlivrd in accordanc with th prvious itration sprints. Significant usags of BRE ar usd to mpowr businss usrs to quickly crat and manag undrwriting ruls with minimal involvmnt from IT staff. To facilitat th mortgag undrwriting procss, rduc costs, and promot consistncy for all loans, crdit scoring modls hav bn dvlopd that numrically wigh or scor som or all of th factors considrd in th undrwriting procss and provid an indication of th rlativ risk posd by ach application (s TABLE III). At th tim, th bank s mortgag undrwriting ruls had ovr 2,600 ruls. So, four ddicatd dvloprs and thr businss usrs involvd in th undrwriting and analytic scor dvlopmnt. BRE and its complx calculations wr also involvd such as loan to valu, loan trm, loan history, dlinqunt and tc. During th dvlopmnt, w also found with many accounts and dbt history can rsult in a long procssing. So, a ddicatd BRE srvr was mployd (s Fig. 2 circld numbr 5). In th loan procss, thr wr nds for ral tim onlin intgration with 13 xtrnal systms and databass such as crdit burau, dposit, dbt, fraud and so on. Th application controlld th rspons snt in turn to a rspons rcivd from bank systms via wb srvic. Information was mappd dirctly to loan application proprtis or parsd and transformd. Th application srvrs srvd as th ndpoint for an xtrnal connction as a mans to provid data to othr systms (s Fig. 2). Additionally, at night tim, for non ral tim data mortgag systm snt/rcivd fil intgration via SFTP with xtrnal systms.g. ntrpris data warhous (EDW), insuranc, human rsourc, anti-mony laundry and tc. Tim was also a constraint as usrs finishd work at midnight only 6 hours prmit to complt fil transfr. As thr wr many loan applications only nw and updatd loans information wr xtractd and snt to th xtrnal systms. A ddicatd agnt nod and SFTP was utilizd (s Fig. 2 circld numbr 6). TABLE III. Mortgag and charact ristic Ma n PARTIAL EXAMPLE OF APPLICATION SCORE MODEL Md ian % of char actr istic Crdit scor Low Mdium High % of % of % of % of scor scor char char actr actr rang rang istic istic Th SFTP fil intgration with othr systms was xcutd last, as ths was btwn systm to systm and th assumption that businss application ndd to b procssd corrctly first. Howvr, during th tst, it was continuously dtctd by rlatd systms that our intrfac data causd thir systms to collaps rgularly. For xampls with th insuranc systm, firstly, dat of birth nd to b in Christian yar format yyyy-mm-dd. So, th softwar ndd to convrt th Thai data bfor transfrring. Scondly, insurd company documnt idntification numbr ndd to b 13 digits, so thr was a nd for scrn formattr and validation to nsur usrs hav ntrd data corrctly. Thirdly, KYC Lvl th systm ndd to st a dfault lvl valu at 100 (low risk). Fourthly, in th cas of slcting a lif insuranc of a particular company, w ndd to st a sum insurd to b gratr than 0. Ths fil intgrations significantly impactd th projct timlin, as mtings and agrmnts with IT and businss ownrs wr rquird to agr upon th inputs and signd-off. Ths systms hav som rgulations that thy hav to comply and cannot chang. As a rsult of ths nw findings, various parts of th softwar wr rvisd.g. data format and typs, businss ruls and scrns. SIT, UAT and rgrssion tsts wr don rsulting in 124 days dlay in total. V. EVALUATIONS OF SCRUM AND MORTGAGE APPLICATION % of scor rang Loan-tovalu ratio (%) < 81 817 842 3.8 86.8 8.2 85.5 88.1 86.8 81 to 90 801 821 3.7 12.6 8.8 13.6 87.5 12.6 > 90 770 782 3.4 0.6 12.8 1 83.9 0.6 Loan siz 2 M 814 840 4.4 44.2 8.3 37.7 87.3 37.5 2 M 5 M 812 836 3.9 39.1 8.7 39.9 87.5 37.8 > 5 M 819 840 2.6 16.8 7.6 22.4 89.8 24.7 Location charactri stic ZIP cod < 80 788 811 5.5 13.4 12.6 13.9 81.9 8.5 80 to 120 811 836 4.2 52.9 8.6 50.1 87.2 47.5 > 120 824 847 2.9 33.6 6.9 36 90.1 44.1......... Th rsarch aimd to answr fiv aras: 1) projct prformanc with schdul and cost; 2) managmnt accptanc; 3) customr rlationship; 4) tam satisfaction and 5) usability accptanc. 68 P a g
For projct prformanc, TABLE IV shows actual ffort and duration, th last column highlightd diffrncs from th plan. Th actual fforts wr ovr two thousands man hours (33%) mor than stimatd and 200 days dlayd rsulting in 300,000 USD ovr budgt. Thrfor, top snior managmnt dcidd that in th nxt phas a turn-ky projct managd by a vndor will b utilizd in ordr to manag th cost. Agil will no longr b favord. Procss Application Rgistration Application Procssing Undrwriting and Closing Usr Managmnt and Chang of Condition Risk Analysis and Intrfac TABLE IV. Plan (hr) ACTUAL EFFORT AND DURATION Durati on (day) Act. Work (hr) Act. Durati on (day) Diff (hr) 1,332 16 420 35 912 720 12 774 29-54 480 11 4,164 59-3,684 2,256 32 790 76 1,477 2,736 52 3,885 176-1,149 Total 7,524 123 10,033 375-2509 A wk aftr th production dat (3/06/2013), assssmnt to find customr rlationship and tam satisfaction with Agil, an intrviw with projct sponsor, was conductd. Sh was happy with Agil as its approach promotd tamwork, facilitatd th dlivris of priodic working softwar. Howvr, sh was disappointd with th control ovr costs. From working tam (PM, Dv, BA, SME, tstrs) points of viws towards th projct (with writing commnts on sticky not colord in grn and rd to rprsnt good and no good ), th rsult shows that dvloprs likd th Agil approach, nw tool and offic nvironmnt. Thy flt th tam was congnial (outsourcs and in-hous dvloprs) and wr comfortabl on working and undrstanding with ach othr dspit languag challngs. Dvloprs flt SME and businss lads ar opn to discussions, abl to xplain and clarify quris on xisting businss procsss. Howvr, th tam shard similar ngativ opinions: 1) high rsourc turnovr, rsulting in substantial tim and ffort spnt on orintation and initiation of nw rsourcs; 2) Thr ar many situations whr changs to rquirmnts wr mad without analysis and approvals from stakholdrs Bttr utilization of tim and ffort could hav bn achivd if thr was a mor comprhnsiv procss in assssing suitabl rsourcs. Chang managmnt procss nds furthr rfining and govrnanc ; 3) Projct status updats in wkly mtings with snior managmnt of outsourc companis wr oftn postpond. In trms of intrfac usability valuation, fourtn participants, from all units, 7 mals and 7 fmals, voluntarily participatd. Thir ags rangd from 22 to 31 yars with a man ag of 25 (std. = 0.48). LOS was givn an ovrall usability of 58% which is considrd abov avrag. Th othr factors mt th standard rquirmnt of usability scals (s Error! Rfrnc sourc not found.). For ach scal, th mdian valu is shown circld in th middl of th lin; th 95% confidnc lvls ar shown by th opning and closd points. Ths limits man that w can b 95% crtain that tru scal mdian for th softwar can b found. LOS mad th circls ovr 50% lin, xcpt for th Efficincy scal showing that usrs flt th softwar and navigation wr complicatd. Fig. 3. SUMI Rsult Th main conclusion for ach of th Sub-scals is summarizd in TABLE V. Subscal Efficincy Affct Larnability Control Hlpfulnss TABLE V. SUMMARY OF SUMI RESULTS Main Rsults LOS was complicatd to navigat. It rquird too many intractions (txt inputs, buttons and conditions) to achiv an intndd task. Th softwar is robust and sufficint to work in a ntwork nvironmnt. Evn though, th softwar did tak th issus of snsitiv data into account, many of th sav buttons wr too many. Th usrs nd to sav of snsitiv data for any modification bcaus of Cloud. Th usrs wr satisfid with working with this softwar and did not fl tns whil using it. Still, th prsntation nds to b improvd. Th intrfac is informativ; most functions of mnu and buttons rprsntd what it did quit clarly xcpt for th snsitiv data. Th softwar was fast and robust. Th usr could mov from on part to anothr fairly asily. Howvr, thr wr too many clicks and kystrok and th usr flt thy wr not in control. Th hlp fil was informativ but som txts wr difficult for th staff. Th rror and softwar mssags wr adquat. Each scrn had its own hlp prsntation. From th SUMI qustionnair, LOS was usabl (> 50). Ovrall nd usrs had no problm in oprating th softwar. This indicatd that intrfac s factors such as clarly sn buttons and layout of UI lmnts rcivd positiv fdback from th nd usrs. 69 P a g
VI. DISCUSSION AND CONCLUSION This papr aims to contribut with an undrstanding of agil dvlopmnt failur in a larg scal projct, by idntifying larning lssons which may contribut to othr financial systms and othr complx domains. Importantly, this study shows that Agil and th projct was not faild, but du to political prssur on rducing th ffort by snior managmnt (Stag 3) which alignd with prvious studis [7] [8]. Currntly, Agil is not adoptd by th bank as a rsult of ffort, timlin and cost ovrruns. Watrfall modl is currntly mployd. Howvr, TABLE VI shows that if using th initial stimatd (last column); th total projct ffort was in a saf zon (ovr stimatd by 1447 man-hours or 12%). Indd, agil should hav bn adoptd, if fforts wr not dtrmind by snior managmnt. TABLE VI. COMPARISON OF ACTUAL AND INITIAL PLANNING Procss Political Actual Tam plan 1. Application Rgistration 1,332 420 440 2 Application Procssing 720 774 380 3 Undrwriting and Closing 480 4,164 3,296 4 Usr Managmnt and Chang of Condition 2,256 790 502 5 Risk Analysis and Intrfac 2,736 3,885 6,862 Total 7,524 10,033 11,480 Evn though, on of th main principls of agil mthods is to wlcom changing rquirmnts [4] [7] [12] howvr this rsarch showd that changing rquirmnts spcially with tchnically complicatd challng (Itration 4) can contribut to xtndd timlin and cost [9]. Th projct appard to hav timlin and budgt is strictly dtrmind by snior managmnt, thn it implis that working ovr-tim is mandatory. In this projct, dvloprs workd ovr-tim on a rgular basis to mt th political forcd timlin. Thir fforts wr mostly un-clockd and un-billd to hlp th projct and tam. Thrfor, th actual hours of ovr-tim wr not rcordd. Consquntly, six outsourcs and two local staff rsignd adding problms to th projct. Rigid timlin incrasd prssur, whn timlin is rstrictd, poor planning and analysis of rlatd intrfac systms (Itration 5) wr not focusd causing r-works significantly and miss of timlin for th projct. Futur mpirical rsarch is ndd to invstigat undr which rlatd intrfac systms and thir mssags should b rconcild in trms of thir rquird filds to avoid rworks and dlay of projct. For xampl, if a middl namd is a rquird fild in a customr information systm, thn th fild is a rquird fild in mortgag systm. As rportd in th PMKBOK [4] lack of fulltim SME staff was an important sid ffct of th dtctd problms (Stag 1), lading to projct dlays and failur. Bsids, th prviously mntiond problms potntially linkd to political forc and projct managmnt, thr wr additional difficultis during softwar dvlopmnt. At th bginning of Stag 3 of our projct, th local tam was novic. Employing nw tchnology in any projct implis crtain inhrnt risks. Although, a training priod to us BPM/BRE tool was carrid out in Stag 2, it rsultd insufficint; sinc thr wr aras of th tool to srv complicatd mortgag rquirmnts. Spcial car was mployd by sid-by-sid programming practic btwn local and outsourc dvloprs. This turns bnficial to outsourc as wll for handling complx natur of mortgag domain whr multipl disciplins intract [1] and spcific Thai mortgag ruls. It is thrfor rcommndd that local and forign staff sitting togthr. Efficint communication is on of th ky issus of Agil [3] and frqunt dlivry of tstd working softwar in an itrativ way brought high visibility of projct progrss [10]. Th mail updat of bug fixs and projct status updat for vry two wks too all stakholdrs giv dirct fdback to dvlopmnt amlioration. This contxt hlpd to shar th big pictur of th projct stat and to build a strong camaradri and tam spirit, which dfinitly wr th ky drivrs to sustain focus and commitmnt during all stags. Although, th SUMI scor was adquat, a rang of intrfac problms was uncovrd. Firstly, th major problm arising from th SUMI analysis rlatd to th Efficincy scal (46%). It was found that th usrs wr rquird to kyin substantial data in on singl pag, chck data synchronization btwn tabs and sctions in ordr to complt th procdur. For xampl, firstly, in financial data sction, usrs wr not allowd to stp nxt if thy had not compltd typing in ight tabs of th account. Scondly, th application instructd th usr to sav snsitiv information in many placs (s Fig. 6). In th nxt vrsion of LOS in trms of Efficincy scal, thrfor th softwar will minimiz th numbr of sav button. Also, collapsibl sction will b usd (s Fig. 7) without displaying all filds 1. This may rduc th usr prcption that thy hav to ky-in all. On of th limitations of this rsarch study was th constitution of th sampl i.. mortgag application spcific. Nonthlss, mortgag was only part of th activitis of this rsarch in agil dvlopmnt whr an institut attmptd to adopt Agil. BPM/BRE tool usd is propritary whr lin of cod cannot b countd to assss softwar siz. Additionally, from th authors knowldg, th BPM/BRE cloud-basd loan origination systm is th first xprinc in th world. So in trms of Koch Agil valuation [10] thr is no bnchmarking availabl to compar in trms of spd of dlivry, softwar siz, prformanc, robustnss or adaptation of Agil in banking industry. Thrfor, th rsults might not gnraliz to othr agil dvlopmnt, particularly thos in diffrnt cultur or fr of political influncs. Whil th nd for agil approach has bn widly rcognizd, making an agil approach work in a long stablishd watrfall bank is challnging. A numbr of rcommndations can b drawn; firstly vn a political prssur on th ffort stimatd by th dvloprs, still in th nd th actual ffort rflcts th arly stimat. Scondly, inxprinc dvloprs may not b abl to dsign a cor ngin of BPM/BRE for th bank. Tool may b ndd. 1 At th tim of this writing, it has bn implmntd as a rsult of SUMI and intrviws whr usrs rqustd for scrn rdsignd changs 70 P a g
Thirdly, constantly changing rquirmnts incrass difficultis and workload during dvlopmnt whr timlin cannot b changd producing a significant dissatisfaction from dvloprs and th sponsor. Th rsarch rvald svral paradox-lik phnomna that nd furthr rsarch and invstigation. Th agil mthod was found fasibl in a larg projct; within th tam Scrum was highly ffctiv in rscuing this mortgag wb-basd projct. Th us of Scrum rsultd highly positiv at working tam sinc it improvd th communication btwn tam mmbrs and as a consqunc incrass th tam flxibility and productivity and maintaining focus on thos tasks mor rlvant to th projct. ACKNOWLEDGMENT Th author is vry gratful to Andrs Markvardsn for continud rviws of this papr. [11] K. G. Royc, "Intgration of a Businss Ruls Engin to Manag Frquntly Changing Workflow: A Cas Study of Insuranc Undrwriting Workflow," in Amricas Confrnc on Information Systms, Colorado, 2007. [12] A. S. Koch, Agil Softwar Dvlopmnt Evaluating th Mthods for Your Organization, Boston: Artch Hous, 2005. [13] T. Silva, M. Silvira, F. Maurr and T. Hllmann, "Usr Exprinc Dsign and Agil Dvlopmnt: From Thory to Practic," Journal of Softwar Enginring and Applications, vol. 5, pp. 743-751, 2012. [14] A. Narasimhadvara, T. Radhakrishnan, B. Lung and R. Jayakumar, "On Dsigning a Usabl Intractiv Systm to Support Transplant Nursing," Journal of Biomdical Informatics, vol. 42, p. 137 151, 2008. [15] G. G. Angl, PMP Crtification A Bginnr s Guid, Nw York: McGraw-Hill, 2010. APPENDIX REFERENCES [1] K.Tmkin, D. Lvy and D. Lvin, "A Cas Study of th Mortgag Application Procss," in Mortgag Lnding Discrimination: A Rviw of th Evidnc, Washington DC,, Urban Institut Prss, 1999, pp. 137-160. [2] R. Avry, R. Bostic and P. Calm, "Crdit Risk, Crdit Scoring, and th Prformanc of Hom Mortgags," Fdral Rsrv Bulltin July 1996, Washington, 1996. [3] L. Williams, "What Agil Tams Think of Agil Principls," Communications of th ACM, vol. 55, no. 4, pp. 71-76, 2012. [4] B. Jordan, J. Gibony, M. Kith, J. Mark, D. Wilson, R. Schutzlr, P. Lowry and A. Vanc, "Ovrviw and Guidanc on Agil Dvlopmnt in Larg Organizations," Communications of th Assosiation for Information Systms, pp. 25-44, July 2011 [5] H. Mohammad, T. Alwada and J. Ababnh, "Agil Softwar Mthodologis: Strngth and Waknss," Intrnational Journal of Enginring Scinc and Tchnology, vol. 5, no. 3, pp. 455-459, 2013 [6] D. Batra, W. Xia, D. VandrMr and K. Dutta, "Balancing Agil and Structurd Dvlopmnt Approachs to Succssfully Manag Larg Distributd Softwar Projcts: A Cas Study from th Cruis Lin Industry," Communications of th Association for Information Systms, vol. 27, no. 21, pp. 378-394, 2010. [7] J. Wan, Y.Zhu and M. Zng, "Cas Study on Critical Succss Factors of Running Scrum," Journal of Softwar Enginring and Applications,, vol. 6, pp. 59-64, 2013. [8] M. Santos, P. Brmjo, M. Olivira, A. Tonlli and E. Sidl, "Improving Th Managmnt of Cost and Scop in Softwar Projcts using Agil Practics," Intrnational Journal of Computr Scinc & Information Tchnology, vol. 5, no. 1, pp. 47-64, 2013 [9] S. Kavny and K. Conboy, "Cost stimation in Agil Dvlopmnt Projcts," in ECIS, 2006. [10] S. Kruba, S. Bayns and R. Hyr, "BPM, Agil, and Virtualization Combin to Crat Effctiv Solutions," Intrnational Journal of Advancd Computr Scinc and Applications, 2012. Fig. 4. Thr Tir Architctur of Mortgag Application 71 P a g
Fig. 5. Scrn Exampl 72 P a g
Fig. 6. Sav Buttons Fig. 7. Collapsibl Sctions 73 P a g