You are on page 1of 24

Case Study:

Software development strategy for launching a

Banking product1
Anu Kapoor, VP, i-banking platform at Firm-G, a leading Indian bank has just
received a note from the CEOs office.
The note was brief and crisp:
-------------------------------------------------------------------------------------------------------------------------Dear Anu,
As you may be aware, we are planning to launch our next generation Portfolio Risk
Manager. This product is targeted at our top 10% retail banking clients who
cumulatively have a share of 80% of our asset under management (retail).
Successful launch of this product is critical to the business strategy of the bank.
A steering committee has been formed to oversee the design and launch of the
product. The steering committee will comprise of the Chief Executive Officer, Chief
Information Officer, VP Core Banking, VP Corporate Banking, SVP Private
Banking, and VP - Product Research.
Could you please present the steering committee with your recommendation on the
IT development strategy for the product design and implementation? The next
steering committee meeting is scheduled for the Friday of the following week. My
secretary will revert on the meeting logistics.

1 The case was developed by Ravi A. Rao with guidance from Professor Rahul De', of
the Indian Institute of Management Bangalore. Research assistance was provided by
Abhipsa Pal. Copyright is held by IIM Bangalore (2015). [Please do not circulate].
Though based on a real firm, the case data has been changed to protect
confidentiality of respondents. The case is meant for in-class discussion and may
not be cited as a resource.

Anu was not surprised with the email neither its tone nor the content. Indeed it
was a strange request to receive a note for presenting the IT development strategy
to the CEOs office. But with Information Technology playing an increasing role in
shaping the market strategy, Firm-G was compelled to launch a product that could
potentially disrupt and change the current competition landscape. With a very
aggressive time-to-market constraint and the challenge of unclear business
requirements, the development of the software had suddenly become the most
critical factor in the successful launch of the product.
The choice that Anu had to make was very simple a) whether to develop in-house
or to outsource, and b) what software development methodology to use? While
these questions seemed to have textbook answers, she knew that her task was
going to be a lot more difficult.

The Company:
Firm-G is a large nationalized bank in operation for over 75 years. With over 5000
branches, about 50,000 employees and revenue of over $10 Billion, Firm-G is one of
the leading retail banks in the country.
Over the years, Firm-G has expanded into several other banking related areas
including housing finance, life insurance and general insurance. With a buoyant
capital market, Firm-G has plans of launching a financial securities and derivatives
offering integrated with the banking business.
A brief overview of the banking sector and Firm-Gs market position is available in
Exhibit A.

The IT Department:
Firm-G has been an early adopter of a technology-led core-banking solution and
prided themselves on their use of technology. The IT department is headed by C.V.
Rangarajan or CVR as everyone in Firm-G knew him as. CVR was an industry
veteran of 35 years having spent his initial years at C-DAC. CVR has been with
Firm-G for close to 25 years now. With a few working years left, CVR has silently
desired to spend his remaining time in Firm-G with minimal stress. However, his
leadership and vision were being questioned of late, and he was seen to be
increasingly under stress.
The IT portfolio at Firm-G consisted of the three groups: Core-Banking, Corporate
Banking and Internet Banking. Each of the groups is head by a Vice President who
reported to CVR.

Firm-G implemented the core-banking software from I-Bank-Always (IBA). The

product has evolved over the last twenty years, and Firm-G had a big role in shaping
the product to their needs. Currently, Firm-G has outsourced the maintenance and
operation of the Core-Banking solution to IBA. IBA has deployed a team of 412
engineers to support this application. Of these 412 engineers, 365 are deployed for
operations support across the regional offices. The remaining engineers work out of
a dedicated development center that was set-up in the IBA office. These 47
engineers are tasked with providing upgrades, production support, and reporting
The Core-Banking product is a Unix-based product with a web front end. Till
recently, the product had a windows front-end. A major upgrade activity undertaken
18 months back migrated the user interface to a web-based front-end.
The contract with IBA is a fixed-price Annual Maintenance Contract (AMC). According
to the rules of the contract, IBA was authorized to add 5 personnel for every 40 new
branches that are opened.
Corporate banking is run by D.K. Sengupta, who is known to run a very tight shop.
His team consists of only 18 employees and 32 consultants who offer specialized
services such as Assets and Securities, Forex (foreign exchange), Treasury, and Risk
hedging products. These applications are mostly custom-built that were developed
as an add-on to the Core-Banking product.
The Corporate Banking group has an ongoing stream of service modules that get
regularly added to the core-banking product. The software development process for
each of the modules is a well controlled process. The modules require about 12 to
18 months of design and build. The typical activities for a new module involve the
following steps:

A business case and product idea from the business group

An approval from the Business leadership and the CEOs office
A Business consulting session of 1 to 3 months (usually led by one of the
Big-5 consulting groups) that ended in a Business Requirements Document
A request for proposal (RFP) for a fixed-price development floated to 5
empanelled vendors (IBA being one of them though they rarely won the
Usually a 9-15 month implementation timeline for System Appreciation,
Design, Build, User Acceptance Testing (UAT) and Implementation. The UAT is
usually a 3 month exercise that involves a production run in a controlled
environment. Two times in the past, the UAT had failed and the vendor had to
take additional time to fix the defects.

The contract for the BRD phase is always a Time & Material (T&M) Contract.
However, the contract type for the Development phase is usually a Fixed Price (FP)
contract having stringent SLAs and Penalty clauses. Once the module was
implemented, the support for that was taken over by the internal IT staff.
Firm-G launched their i-banking services 18 months back. The i-banking platform
was integrated with the core-banking platform. The initial product was procured
from IBA over 30 months back. The product was supposed to have a standard
solution and was expected to be deployed over one quarter. However, it took Firm-G
more than 12 months to integrate the i-banking platform to the core-banking
product. As a result, Firm-G was at least a year behind in their launch of their
i-banking product.
Anu Kapoor is the VP responsible for the i-banking platform. Anu has a premier
engineering degree from an IIT. Immediately after her graduation, Anu had taken up
employment with a leading banking firm in the USA. After having spent a couple of
decades in the USA, Anu decided to return back to her roots. Despite advise from
friends, Anu decided to join an old-sector bank and took up the offer from Firm-G to
head their internet banking division.
The last 30 months in her new job had been everything short of being pleasant. Anu
found Firm-Gs working culture constraining her from taking independent decisions
relating to the functioning of the i-banking platform. She had a vision of internet
banking that her peers and superiors failed to comprehend. She was of the opinion
that while the IBA core-banking platform was good, they (IBA) did not have a good
internet offering. However, the IT core committee decided to go with IBA, despite
her advice.
Further, when it was clear that IBA was struggling to implement the platform,
Firm-G's leadership team decided to provide them an extended run. Now, with over
a year of delay in implementation, and having lost the market share in the internet
banking business, Anu felt that the leadership team suddenly seemed to realize that
they had lost critical time-to-market advantages. Further, Anu, as the head of the
department, was now being held responsible for Firm-Gs loss in market share!
Refer to Exhibit B for a brief overview of Firm-Gs i-banking platform and its
comparison with other banks solutions.

New Product Offering

An operations review meeting for each of the banking platforms was held in the first
week of every quarter. This meeting was attended by all the business unit heads,
the CIO and the VP responsible for the platform. The CEO made a presentation in

the last operations review meeting. He had invited a gentleman named K.

Ramanathan to this meeting.
Without mincing his words, the CEO communicated his displeasure with the
i-banking platform. Firm-G was not only a year late in launching their internet
business; they were also trailing behind on the launch of new services and offerings.
Most of the competitors were now launching next generation products such as
mobile-banking, sms-banking, safe-banking, one-touch banking and a series of
other products. Anu felt that some of these services were indeed revolutionary leveraging SMAC (an acronym that stands for Social Media, Analytics and Cloud) 2
technologies to the full extent, while others were just there to confuse the
consumers. Nevertheless, Firm-G had not been a market leader in launching any of
these services and instead, always seemed to be out of breath catching up with the
The CEO introduced Ramanathan as a young recruit who has been roped in to head
the product research team. Ramanathan (aka KR) had a masters degree from the
Indian Statistical Institute and a Doctorate in Applied Statistics from Harvard. KR
proposed to launch a new Portfolio Risk Manager (PRM) that would be a
first-of-its-kind offering from a banking firm in India. PRM had the potential of being
a key business driver for the retail banking business particularly for the profile of
customers who were likely to bank over the internet.
The CEO told CVR and Anu in no unclear terms that this was their chance for
redemption. Launching the PRM product should be top priority, and that Firm-G
should aim to launch the product within six months.

The Project
Post the ops review meeting, CVR had a discussion with Anu. For the first time, CVR
confided that they had made a mistake with the i-banking solution and should have
heeded to Anus advise and not pursued the IBA solution. He offered Anu a free
hand to decide on the next steps for developing the PRM product.
Her first action was to seek an appointment with KR to understand the projects
complexity. KR appeared to be a pleasing, though eccentric, personality. A brief
interaction with KR was sufficient for Anu to realize that KR was brilliant in his
subject. While he had an incredible belief on how the product could revolutionize
retail banking and portfolio management, he seemed to have no idea on how to
convert this idea into a software application. He spoke in vague terms such as
Monte-Carlo, Data Envelopment, Markowitz Model and a whole lot of other

terms that did not mean anything to her. And KR did not seem to connect to any of
Anus vocabulary such as screens, databases and functions!!
A brief outline of the objective of the PRM product is provided in Exhibit C. KR
further mentioned that there is no one way of developing a portfolio risk
management solution. It will need a series of simulations to be performed based on
the different class of consumers that the bank has and the response they get from
these different sets of consumers.
After reviewing the challenges of developing the PRM product, Anu was becoming
increasingly aware of the risk of taking up the assignment in its current form.
Question 1: Highlight the key risks and challenges in the project.
Agile Software Development approach
While she was pondering over these challenges in her office, she chanced upon an
article on Agile software development that caught her attention. Intrigued by the
article, she decided to explore further the use of Agile methods as an option for
developing the product. She immediately commissioned one of the bright new
management trainees that she had recently hired to provide a summary overview
on the advantages and challenges in adopting agile methods for software
development. A summary of the report provided by the management trainee is
provided in Exhibit D.
Question 2: Evaluate the suitability of using Agile methods for developing the
Portfolio Risk Manager product. What internal skills and resources should the client
firm have to ensure Agile works? What are the risks in using Agile?
A skeptics opinion on Agile
Having made an initial assessment of the feasibility of developing the product in an
Agile way, Anu decided to seek the opinion of her peer from the Corporate Banking
division. DK was known to have very successfully implemented several software
modules on top of the core-banking platform. DKs advice was very clear. You
cannot implement anything in six months. These products are complex and critical.
There is only one way of getting it right. Engage with a top consulting firm, ensure
that your requirements are air tight, have a rigid contract, and recruit the best
outsourcing company to deliver it. DKs firm advise: I have implemented eighteen
highly complex and critical applications on the corporate-banking platform. There is
only one way of doing it right ensure that your requirements are air tight and give
it sufficient time. Everything else will fall in place.
Anu felt that DKs advice was very sound. With KR speaking only statistics, she
could visualize how difficult it would be to convert his thoughts into business
requirements. However, with mounting pressure from within and outside to launch
new products in the market, Anu knew that any project plan that went beyond six

months would not be acceptable. So, she sought DKs advise on using Agile
methods for developing the project.
DK came across as quite well-informed on the challenges of using Agile. First, he
pointed out that Agile was being used by the new-technology industry and not yet
widely adopted by the financial services industry. So, finding teams that are aware
of Agile methods could be a challenge. He further recounted the experience of his
classmate who was the CIO of a large telecommunications provider. His friend had
apparently engaged an Agile service provider to develop a mobile based
bill-presentation software for the telecommunication consumers. What was
apparently a simple mobile application that was supposed to be developed in three
months was shelved after six months of development.
In DKs own words: My friend engaged Agile-Soft to develop the mobile
bill-presentation software. Agile-Soft suggested developing the software using
Scrum and deployed a team of six people including a scrum master, four developers
and a tester. My friend was asked to nominate one person from his team who was
nominated as the product owner. The product owner, whom my friend nominated,
was from the IT team and did not know the detailed product requirements.
Agile-Soft assured that it was okay and that they dont need all the requirements to
be specified upfront. They were perfectly happy with knowing just sufficient
requirements that they can develop in two weeks and then come back and ask for
more requirements. You can imagine whats going to happen right? After two
months of development, the business users realized that the current set of
requirements was not compliant with those developed earlier, so they went back
and changed the earlier ones. Then the software developers realized that the
database design had become too unwieldy because of the frequent changes in
requirements. I was told that the core bill-presentation engine was modified some
18 times in three months. Apparently, the business owner was constantly given a
demo of the application and they seemed to be happy with what they were seeing.
But when it came to user acceptance testing (known as UAT), they found that the
application could not be rolled out into production. It took them two hours for a
simple transaction to complete! I suspect that the design and code had become too
unwieldy. You cant develop an application only by showing the screens to the users.
So, my friend had an advice for me use agile when you dont know the
requirements and when you dont intend to complete the project!
A practitioners opinion on Agile
At the end of this depressing chat with DK, Anu was quite confused. While the
textbook agile practices promised a great amount of agility and flexibility, the actual
reality seemed to be otherwise. On her way back from DKs office, she bumped into
Kartik, a new manager she had hired. She recollected Kartik coming from an Agile
project management background, and thought it worthwhile to speak to him.

Karthik shared his experiences on running an agile project - typical approach,

challenges and benefits. A transcript of the discussion between Anu and Kartik is
provided in Exhibit E.
That evening Anu decided to do her own research on cases where Agile worked. She
found that organizations like GE, and even government organizations like the FBI in
the USA were leveraging agile methodology successfully 3 4. But these were success
stories from abroad. Anu was wondering if it would work in a public sector bank like
Firm-G in India.

Decision time
The next morning, Anu received the note from the CEOs office. The note was copied
to CVR. A steering committee was being formed to decide on the next course of
action for developing the product. She had a sense of a dj vu. Thirty months back,
when she first stepped into Firm-G, her first task was to present a plan for the
i-banking platform development. She dreaded the turn of events since then and
wished she could change things around this time.
3. What should Anu do? Heed to DKs advice and follow a waterfall approach to the
product development, or risk taking an agile approach?
4. What are the key controls she should exercise to increase the chances of
5. Should Anu do the development in-house or out-source the product
6. What internal skills and resources should she align within her team to ensure the
project runs smoothly?
7. What criteria should she use to evaluate the outsourcing firms for awarding the
contract (in the case of outsourced development)? Highlight key parameters that
you would want to be included in the contract.



Exhibit A : Banking Sector and Firm-G

The history of public sector banks in India dates back in 1955 when Imperial Bank of India became the
State Bank of India. This was followed by Government of India nationalizing 14 banks in 1969. Currently
there are 19 public sector banks (refer to Figure: 1). Banking industry is a major developmental tool for
Indias economy. Most of the banks were founded prior to 1950, and till 1968, they organized themselves
independently. After nationalization of banks in 1969, the public sector banking sector grew heavily under
support from the government. Private banks nearly perished. The expansion of nationalized banks
continued as the total number of branches grew from 8000 branches in 1969 to nearly 40,000 by 1985.
However, from 1985 onwards, the profits and productivity started declining due to various reasons like
poor work culture of the employees, no market competition from private banks, corruption and outdated
technology. Following this, the Reserve Bank of India (RBI) made private commercial banks entry into
the industry easy by a liberalization policy. This resulted in stiff competition, and from 1994 onwards, the
public sector banks, already low on profit, started reformatory activities in terms of customer services and
use of modern technology.
Public Sector Banks in India
Allahabad Bank
Andhra Bank
Bank of Baroda
United Bank of India
Bank of India
Bank of Maharashtra
Canara Bank
Vijaya Bank
Central Bank of India
Corporation Bank
Dena Bank
Indian Bank
Indian Overseas Bank
Oriental Bank of Commerce
Union Bank of India
Punjab & Sind Bank
Punjab National Bank
Syndicate Bank
UCO Bank
Figure 1: Public Sector Banks in India.
Banking is a service industry and customer service plays a major role. Yet, in the first few decades of
public sector banking, employee work culture was far from being customer friendly. In the absence of
convenient money transaction systems like ATMs and internet banking, customers were even more
dependent on the banks branch offices. Public sector banks did not face any competition from private
banks, and therefore the employees followed a relaxed work culture. Long queues at the counter, refusal
to process any transaction beyond strict 10am-5pm working hours accompanied with extended lunch
breaks, difficulty in opening new accounts, and unavoidable need of bribing bank officials for loans and
other transactions, were common experiences at any of the nationalized banks. In spite of these poor

customer services, public sector banks dominated the banking business in India for two reasons. One,
Reserve Bank of India decided the interest rates hence there was little scope of market competition. Two,
RBI had restricted new entry of banks.
In 1994, RBI issued the policy of liberalization that reduced the entry barrier for new banks. Soon there
was a sudden surge in competition as new private banks started entering the market. Some examples of
private banks currently in India are ICICI Bank, Axis Bank, ING Vysya Bank, Karnataka Bank, Kotak
Mahindra Bank, etc. The private banks brought modern technology along with them. It is these new
private sector banks that have revolutionized customer service. They forced the public sector banks to
adopt similar information technology and customer satisfaction schemes. This directly impacted the
casual working culture that had prevailed in the public sector banks, forcing them to offer services
comparable, if not equal, to the private banks. With RBI fixing the interest rates, thereby restricting the
freedom of competing through better rates, the only way to create a difference was by services.
The technically advanced private banks contributed to the overall development of the banking sector in
India. Faced with competition, over 7000 branches of public sector banks were completely computerized.
This resulted in both faster customer services and more centralized control of the branches. There was
strategic planning for better operations and services with the new information systems, other than the
basic data-storing and accounting activities.

Along with other banks, Firm-G was nationalized in 1969. Currently it has a network of more than 5,500
branches across India, at places including metropolitans, towns and rural villages, with 48,800 employees
working in India and a few offices abroad (London, Hong Kong, Moscow, Dubai, Doha, Shanghai and
New York). It has 7,000 ATMs, with approximately 2,000 branches offering Internet and mobile banking
(IMB) services and another 2,000 branches providing anywhere banking services.
Firm-G grew massively during the post-nationalization period, after 1969. However, 1980s witnessed a
decline in profitability due to various factors including poor technology, political intervention in loan
policies, low capital, excessive branch expansions, etc. Following this was the liberalization by RBI
inviting new private banks into the industry. The first private bank after liberalization was Global Trust
Bank, followed by Housing Development Finance Corporation Limited (HDFC). Along with the poor
profitability and productivity, this posed a significant threat to Firm-G. It realized, radical reformation
was extremely important.
One such reformatory step was starting a major IT initiative to network all its branches and move them to
a single software platform. This helped it launch its Internet Banking facilities in 2003, followed by total
computerization of all branches in 2004. Currently, about 22 million customers are benefiting from these
IT services. This initiative triggered the recruitment of software engineers with work experience, and
senior management employees with Management in Information Systems education and experience.

Some key strengths of Firm-G are:

It has superior financial performance.

Its capital adequacy ratio is good. Capital adequacy ratio measures the banks capital as a
percentage of banks risk. It is important for the safety of the depositor and determines the banks
It has started new IT initiatives to secure a competitive edge with latest technology.
It has innovative schemes and policies, including the Solar Loan Program.
It is recruiting continuously, and currently has employee strength of above 45,000.

The major weaknesses include:

It has poor marketing and publicity schemes, compared to the competing private banks.
There are fewer branches and hence it has a weaker presence in Western India.
It is facing continuous threat from the private banks equipped with modern technology and
superior customer service policies.

Table 1: Comparison of Firm G with its competitor banks (as on March 2014)

Competitor 1 of Competitor 2 of Competitor 3 of







Deposits (in Rs.
Advances (in Rs.
Net fixed assets
(in Rs. millions)
Share capital (in
Rs. millions)
Investments (in
Rs. millions)
Total assets (in
Rs. millions)
Capital adequacy
ratio (%)
Equity share (Rs.)
Cash flow per
Equity share (Rs.)

















































Equity share
income (in Rs.
expense (in Rs.
Gross profit (in
Rs. millions)
Net profit margin





















1. Samar Srivastava, Economic Milestone: Nationalisation of Banks (1969), (2014), Forbes India
2. Abhiman Das, Subhash C. Ray, Ashok Nag, Labor-use efficiency in Indian
banking:Abranch-level analysis, (2009), International Journal of Management Science
3. Surabhi Singh, Renu Arora, A Comparative Study of Banking Services and Customer
Satisfaction in Public, Private and Foreign Banks, (2011), Journal of Economics
6. Canara Bank Website -
7. Bank of Baroda Website -
8. HDFC Bank Website -
9. ICICI Bank Website -

Exhibit B : Internet Banking

ICICI bank was the first bank in India to launch internet banking services as early as 1998. Soon after,
other banks followed suit. A typical internet banking facility, also known as i-banking, net banking, or
online banking, consists of the multiple services that can be availed from anywhere via the online bank
account, without any physical presence of the customer at the banks branch.
The services typically include:
1. Viewing recent transactions and current balances
2. Downloading bank statement in PDF or text format
3. Ordering cheque books
4. Linking other accounts of the same customer and fund transfers to these accounts
5. Fund transfers to other account holders (same bank or different bank)
6. Mobile/DTH online recharge
7. Opening new accounts of the same customer for Recurring Deposits, Fixed Deposits, etc.
8. Third-party bill payments in case of Online Payment during online shopping, online ticket
booking, etc.
9. Applying for a loan
10.Applying for new credit card
Internet banking has gained immense popularity over the years. The common reasons of popularity of
i-banking are:
1. Convenience: It saves tremendous amount of time to accesses the account and doing transactions
without physically visiting the bank branch or office. Daily transactions like fund transfer to
another person, mobile recharge and bill payments can be comfortably done from anywhere,
starting from home, or workplace, or even while traveling, if the user has a computer or a mobile
phone with internet connection.
2. Security: Online bank accounts are linked to the customers mobile and the account holder
receives an SMS for all transactions. This is a protection against any theft as the customer can
inform the bank as soon as it happens. Also, the ease with which a customer can view his/her
account helps him/her track all previous transactions, in a chronologically sorted manner.
3. No Queues: Earlier, banks used to be identified by long queues of customers waiting for a bank
personnel serving them individually for activities like cash transactions, new account opening and
passbook updating. I-banking has made all these possible via the users online account. Banks are
usually much less crowded these days.
4. Additional Services: Some banks provide extra features in their i-banking facility. For example,
the iWish scheme launched by ICICI bank is a flexible recurring deposit. A customer can open an
iWish account, and deposit flexible amounts to his/her account every month, through net banking.

Stock Trading Platforms

Figure 2: ICICI Banks Internet Banking (User Account Screen)

Indian banks have started providing online stock trading platforms for account holders to trade
stocks and monitor the stock prices regularly, through a single window. The customer is required
to open a demat account in order to access the facilities. The common features of a stock trading
platform provided by banks include:
1. Easy transactions between the customers various accounts banking, demat and trading
2. View current stock prices, market fluctuations, top gainers/losers, etc.
3. The customer can view current margin status, holding report, order and trade, on a real time
4. The bank also provides recommendations and suggestions to its customers on the trading
5. It also provides the facility for buying Mutual Funds.
6. The platform has innovative tools to help the user manage his stocks and make better
investment decisions.
7. It also allows the user to create and manage multiple portfolios of all asset classes.

Currently several banks in India have online stock trading platforms, which include State Bank of
India (SBI), Canara Bank, HDFC Bank, ICICI Bank, and many more.

Figure 2: Online Stock Trading Platform of Canara Bank

1. S.Vignesh, Internet Banking In India, (2014), ISR NATIONAL Journal of Advanced Research
in Computer Science Engineering and Information Technology
2. ICICI Banks Homepage, accessed on 23-Jan-15
3. Canara Banks Webpage, accessed on 23-Jan-15

Exhibit C : Portfolio Risk Manager

Over the last decade, Firm-G had diversified the solution it offered to its clients. The
firms product offerings through its various divisions and subsidiaries included:

Core banking services

Housing finance and other loan services
Life and General insurance
Brokerage services
o Equities and Derivatives
o Debt, Bonds and Money market instruments
o Alternative investments such as hedge funds, commodities and real

While Firm-G had diversified its product offerings, more than 90% of their revenue
came from the core-banking services. Firm-G was unable to effectively sell the
various products to their clients. Over the years, Firm-G had developed a strong
relation with most of the leading corporate firms in the nation and managed the
salary accounts of several million customers. However, most of these customers
limited their business with the bank to savings bank and related products. As a
result, Firm-G was not able to tap into the large disposable income of these clients.
Over the last couple of years, Firm-G had established a strong research desk. The
firm had spent considerable amount of time, effort and money in branding their
research desk. The management felt that it was time to leverage the brand equity
of their research desk for new customer acquisition and increase their business of
existing customers.
A key to their plan was the patented Risk Profiling algorithm developed by their
research desk. Firm-G aimed at offering portfolio management advice that was
powered by the Risk Profiling algorithm as a free service to its clients. Firm-G saw
this as an opportunity to gain access to its clients portfolio, provide
recommendation on portfolio alteration that are essential, and then use this
opportunity to push Firm-G product.
The Portfolio Risk Manager product was conceived as a native mobile app that was
to be made available as a free download. The key product requirements included:

Offer the risk profiling application as a stand-alone app that can be used
directly by the client.
Enable the risk-profiling of the client through a heuristic based model that
eliminated standard survey based questionnaires
Combine past market performances, research desk outlook, asset distribution
pattern and the personal risk profile to recommend optimal asset allocations
Provide in-depth analytics and what-if models that are simple enough for the
consumers to use but offer powerful insights to their portfolio

An advanced version would be to integrate the application with the i-banking

and trading platform.
A few key technical considerations include
o Data privacy and protection
o The high computational requirements
o Mobile form factor and the ability to provide rich and intuitive analysis

Exhibit D: A brief introduction to Agile Development Methodologies

The Waterfall Model has been the traditional approach to software

development. The waterfall model follows an approach of developing
software in several well defined stages such as requirements definition,
analysis, design, coding, testing and implementation. The focus of each of
the stages is to complete the activities of the stage, obtain an approval from
the sponsor and then proceed on to the next stage. The focus of the waterfall
model is to bring in predictability to the complex activity of software
development by prescribing well-defined process for each of the stages and
ensuring adequate reviews and approvals before proceeding on to the next
Software development is however seen to be a complex, chaotic and largely
unpredictable process. Software requirements have often been known to be
unpredictable and constantly changing. Software development is a skill
based activity that requires the co-ordination between diverse sets of people.
Controlling the software development process through well-defined project
plans and air-tight review processes is often seen to be a challenging activity.
Over the last decade and half, a new set of methodologies in software
development have evolved with a focus on adaptive rather than predictive;
and people-oriented rather than process-oriented methods. These methods
were commonly known as agile development methods. Leaders and
proponents of various agile development methods formed the Agile
Alliance and developed the Agile Manifesto 5 as an alternate software
development paradigm.
The agile manifesto is based on a set of twelve principles 6. One set of these
principles is around self-organized teams, stressing on the need for
motivated and skilled human resources, the need for co-location and
co-working of users and developers, and frequent interaction between the
team and the users. A second set of principles is around the importance of
customer satisfaction, the need to accommodate changing business
requirements, and collaborating with the customer as against following a
contract. The principle of accommodating changing requirements requires
that the project teams be adaptive rather than predictive, with a focus on
responding to change rather than following a strict plan. Another set of
principles focuses on creating value by frequently delivering working
software at regular short intervals.


Scrum and XP
The various agile methods are oriented around these principles. Two of the
most popular agile methods are Scrum and eXtreme Programming (XP).
Scrum7 is a project management based framework for developing software in
an agile manner while XP8 focuses on the engineering aspect required to
develop software in an agile manner. A combination of agile and XP is often
used by software developing vendors adopting agile methods. The figure
provided below provides an overview of Scrum and XP.



Figure: Agile Software Development using Scrum and XP

Scrum employs an incremental approach to software development and aims to
optimize predictability and control risk through transparency, inspection and
adaptation. Scrum team consists of three roles: the Scrum Master responsible for
ensuring that the process is understood and followed; the Product Owner
responsible for maximizing the value of the work done by the team; and the Team
comprising of developers. Scrum processes are time-boxed to create regularity: the
development cycle is a Sprint that is an iteration of one month or less; daily Scrum
meetings are limited to fifteen minutes, the Sprint planning meeting is limited to
eight hours and the Sprint retrospective meeting is time-boxed to three hours. The
primary objectives of the Sprint meetings are to enable inspections and continuous
adaptations. The Scrum artifacts comprise of the Product-Backlogs that includes the
prioritized list of product features; the Sprint-Backlog that consists of Sprint tasks;
and the Burn-down charts that measures the remaining backlog over time. There
are a set of rules that govern the Scrum roles, time-boxes and artifacts.
The Scrum Masters role is to ensure that the team follows the Scrum principles and
rules. This involves coaching the team members and enabling them to form a
self-organized team. The other important role of the Scrum Master is to remove
impediments. The Product Owner is responsible for managing the product backlog
and ensuring that the output of the team is of value to the stake holders. The
Team members are skilled, cross-functional developers who form a self-organized
team and convert the product backlog into workable software. Being a
self-organized team means no-one (not even the Scrum Master) commands the
team with respect to converting the product backlog to workable software.
Assignment of tasks is done through a volunteering for tasks by the team members.
There are two ancillary roles, the management (project management external to the
scrum team) and the stakeholders (vendors or customers) who are recipient of the
output of the Scrum team.
The final output of the Scrum team at the end of each Sprint is an increment of
product functionality that is considered as done. The entire Scrum team has to
have a shared understanding of the definition of what done is: typically a running
increment of the product that is potentially shippable to the end customer and
consists of only those functionalities that is of considerable value to the stake
Some of the concepts introduced by XP that are frequently adopted by agile projects

The concept of the Whole team and Collective Code Ownership that
ensures that the entire team is responsible for the code and no single
individual is indispensable

Practices such as Pair Programming that believes that working together in

pairs provides better quality and productivity
Continuous Integration and Refactoring to ensure that developed software
code is never out of sync with the overall product goal and is constantly
being improved upon.
Test Driven Development that believes that the software code needs to be
developed with a test-first approach : with a focus of eliminating redundant
code and having a working software with almost a 100 percent test coverage.

Comparing Agile and Waterfall

The approach followed by Agile development is paradigmatically different from
those of waterfall methodologies. A summary of the difference between Waterfall
and Agile development is summarized in the Table below.

Traditional (Waterfall)
Optimization and Predictability
Sequential, controlled and relies
Central, Hierarchical

Adaptation and learning
Parallel, iterative and relies on
effective communication

Distributed, Shared
Individual accountability
Collective ownership
Table 1: Difference between Traditional and Agile methodologies

Exhibit E: Transcripts of the discussion between Anu and Kartik.

A: Hey Kartik, you have a minute? I am starting on a new product development and
I wanted to pick your brain on using Agile methods for doing the product
development. Would you have some time to have a small chat on this?
K: Sure Anu, in fact, I wanted to speak with you on this topic as well. You know I am
a Certified Product Owner and an Agile coach. I have been thinking that we could
benefit a lot by introducing Agile in our organization.
A: Excellent, then this is the time to discuss. Lets go, grab a coffee, and then you
can get started.
K: I suppose you are aware of typical Agile practices Scrum and XP right?
A: Yes, yes, I have some basic understanding of that. I have an understanding of
what the various roles are: product owner, scrum master, and the developers. I also
understood that development is undertaken in short iterations that are called
Sprints, and each sprint has various ceremonies such as Sprint planning, review,
retrospective and the daily scrum. And then I was told that there are certain
artifacts that are produced the Product Backlog that has the requirements written
as user stories, Sprint backlog comprising of tasks, and the Burndown charts for
measuring progress. See, I have gathered a lot of what Agile software development
does (Exhibit D). But the question is how is it different? This still does not answer
my question on why Agile?
K: Wow, thats a lot. Thats all they taught me in my certified scrum training. But
seriously, you have a good question why agile. Well let me attempt that...
First is this whole notion of requirements. If you read the Agile Manifesto 9, one of the
principles is about Responding to change over following a plan. So, the belief is
that software requirements are bound to change, there is nothing like a frozen
requirement. As you keep developing software, you understand the application and
the requirements better you uncover different possibilities, and then you take
opportunity of the improved understanding by changing the requirements as
necessary. So, agile software development does not believe in having requirements
completely done and boxed up before you start the design and build. You start with
a base set of requirements, there needs to be a great amount of collaboration
between the business and the tech folks, and then you design and build those
requirements. You then take the next set and do this iteratively.
The product backlog usually captures the requirements in the form of user stories.
These are prioritized based on their value to the business. You need to ensure that

the high priority user stories have reasonably clear requirements, the next set not
so much, and maybe the last set you dont have any idea at all at this stage.
A: So, I suppose, it is appropriate to say that Agile software development does need
good requirements, if not perfect requirements.
K: True, you need good requirements. But it is just in time though. You of course
need to have an idea of what you are going to build, what the end goal is, and how
to get there. To get there, you do a series of incremental builds, and you do this
iteratively. These are what we call Sprints. For the immediate Sprint, and maybe the
next Sprint, the requirements have to be reasonably clear.
As you move from one Sprint to another, the solution evolves - the requirements,
design and code all of them evolve. And to make agile projects successful, you need
to embrace this evolution.
A: OK, I understand this evolutionary process, and that requirements are bound to
change. But doesnt this developing in short cycles cause too many changes? Isnt it
an inefficient way of software development design, build, test and then maybe go
back and change your design again to accommodate new requirements? Wont
there be excessive rework?
K: Yes, indeed, you got it right. There is a chance of rework. But then it is a trade-off.
Can you manage the project such that your cost of rework is minimized? In agile, we
think we can. As I mentioned earlier, you need to have a sight of the end goal, you
base your architecture on that. Under this framework, you let your design evolve. As
long as you maintain a good technical stack and coding standards, the change in
design should not impact you too much. Are your software components low on
coupling and high on cohesion? Do you have a good unit test coverage? Are you
maintaining the discipline of doing a daily build? There are several good engineering
practices from XP continuous integration, refactoring, pair programming,
test-driven-development .. to name a few, that ensure that you are continuously
able to provide value to the client.
A: These are a completely different new set of engineering practices! What kind of
demand does this pose on the development teams?
K: Good question. Agile software development has an implicit assumption that you
have experienced cross-functional personnel. We dont believe in wasting effort in
unnecessary documentation:

The requirements are sparsely documented in the product-backlog instead,

the software developers actively discuss this with the business users to
understand requirements.

We do not waste effort in elaborate project planning and scheduling instead,

the developers self-assign tasks, provide an estimate and we track our
progress using a burn-down chart on the agile wall!
We do not waste time documenting detailed design and program specs the
best documentation is the code itself. So, you need developers who can read
code and understand the design from the code! Owing to the incremental
nature of the development, there is a possibility that a software component
may change repeatedly, and these changes may be undertaken by different
developers. So, we dont see one person owning the code, its the team that
owns the code. The entire team has a right to change and improve the code.
Refactoring is the essence of Agile!

So, you can see, developing in an agile way needs experience. You need
experienced developers who can work independently but collaborate with each
other. I dont think Agile development is meant for rookies.
A: So, Kartik, you are saying that the business folks and the software developers
need to work together to ensure agile development is successful. So, what are the
challenges in outsourcing the development?
K: Well, I know there are a lot of vendors out there who make tall claims about
outsourced agile development. But I dont see it happening this way. Agile needs
co-location, agile needs experienced developers, agile needs an implicit trust
among all the team members. I dont see how an outsourced vendor can fit into this
scheme of things? Agile talks about collaboration over contract isnt that an
Outsourced vendors are used to driving quality through strong stringent process,
stringent scope management, excessive documentation and stage-gate reviews. All
of these are against the principles of agile development. I have always seen
outsourcing working with a tall hierarchical structure, not a flat structure that agile
mandates. I think outsourcing is good for waterfall development, not for agile!
A: Well Kartik, thank you so much for your time! It was indeed very useful .. will
help me in my decision process. And I do remember your offer to be the Product
Owner for the project. The only issue is that I dont have the rest of the team!