(Fr)agile Software Development

Much of our world is made possible by software. There are myriad software systems that manage and move our money, keep track of our health histories, light our homes and offices, and indeed even enable you to read this post. While the sheer scale of accomplishment from zeros and ones flitting about at the speed of light is astounding, the manner in which some of these systems are developed, tested, and delivered raises a few questions.

Over the falls in a barrel. The early years of evolution in software development owed much to needs of the defense and aerospace industries. These were highly mission-critical systems that had to work correctly almost ten times out of ten. A linear process that involved detailed specifications, technical designs, strict coding discipline, reviews, and rigorous testing ensured the delivery of many high performance systems.

A version of this made its way into the commercial marketplace under the broad "waterfall process" moniker. The series of hand-offs, from product management, to architecture, design, development and testing, with intermediate review cycles, hearkened a series of waterfalls as in a cataract. While the process worked well for the most part, it lacked speed. The many steps limited organizations to one or two releases to the marketplace a year. It was difficult to nimbly respond to competitive and regulatory changes. If changes were not included early enough in the cycle, it was tantamount to missing an exit on a tollway, and waiting for the next one.

Sprints around the racetrack. In the 1970's, the automotive industry introduced the concept of "simultaneous engineering", where design engineers, manufacturing engineers, and quality control worked together in teams. As opposed to the linear, "throw it over the transom" model, this engendered both speed and sharing of ideas. That germ of an idea made its way into software as Agile Development. While there are many agile methodologies, the general concept is that specifiers, programmers, and testers work together in short, iterative, "sprints" to produce executable software. Over multiple sprints, complete, ready-to-release applications can be built.

Lost in translation. While agile development has made it possible to release software more frequently, a few challenges have appeared on the way to nirvana. To the agile purists, I will grant that many of these have to do with incorrect interpretation and implementation, and perhaps not because of fundamental drawbacks in the methodologies. The challenges are amplified when you add offshore development where the advantage of co-located teams disappears. They are also most acute when software is developed for General Availability to a large and varied customer base, as opposed to internal use within an enterprise. Here are some of the pitfalls I have observed over the years:

What we have here is a failure to communicate. With apologies to "Cool Hand Luke", one of the main complaints I have seen is, "We don't know what is coming, and when!" We have moved from exhaustive, written requirements to writing nothing down. The refrain is that the sprint teams communicate with each other, and are on top of release content. Some will add that everything can be discerned from documentation within the code. The problem is that there are many stakeholders outside the sprint team, such as sales, marketing, professional services, and support. These people are not adept at reading code, and think in terms of functions and applications, as opposed to individual features. The result often is that market facing groups either oversell or undersell the product (more often the former!).

Who's on first? While sprint teams are cohesive and democratic, the flip side is that it can result in no one at the helm. While the methodologies call for a "function customer" who signs off on software content and quality, this role is often missing in action. Either the role is completely absent, or it is relegated to a Product Manager who is more of a Product Marketer than someone who can go head-to-head with a technician. In the absence of this key role, many cooks jump in to influence the software broth in one direction or the other, resulting in content churn. The process is agile yes, but highly unstable.

Tried and tested. Agile methodologies like test driven development put testing and quality at the center of the process. In practice, however, quality often ends up getting the short end of the stick. The very expectation of agility can compress timelines due to unrealistic promises made to customers. In the rush to "get it out of the door", thorough testing is skipped, and some vendors essentially do their quality assurance on the customer's dime, by continuously band-aiding software at the customer site until it works. In extreme cases, this becomes a license to hack with little regard to version control, belying the very concept of "General Availability". While poor quality is not limited to agile methods, the less rigid process restrictions can exacerbate the tendency in organizations that already have a culture of treating quality lightly.

Customs and traditions. In organizations that cater to customers of varied sizes, the concept of General Availability can be turned on its head. There is often the case of a large customer that wants software customized to meet a unique need. There are very few vendors that have the discipline to examine whether that particular capability warrants inclusion in the software delivered to the general marketplace. The path of least resistance is to include it as a base capability that is "configurable". Over time, the preponderance of configurable customizations makes the software incredibly difficult to implement and support. Again, the lack of a process to adjudicate the "base versus custom" question can result in a multi-headed Hydra, with hidden heads that can appear to bite you when you least expect it.

Distant shores. Every one of the problems discussed explode in complexity when offshore development is involved. The communication challenge now includes time zones, national cultures, and language. The concept of sprint teams working in iterations is predicated on the concept of co-located personnel who can discuss, white-board, and resolve questions face-to-face. Getting this done with people somewhere else on the planet is very difficult, and contributes to hidden costs in offshore development that can obliterate the wage differential in the early stages of the offshore journey. The challenge can be overcome, but it takes special focus and attention to drive out the inefficiencies.

Brave new world. The benefits of agile development have ensured that it is here to stay in most environments. The word to the wise is that getting it to work right involves recognizing the pitfalls, and addressing them involving the right stakeholders. I would not be surprised if many of you recognized your organizations in some of the challenges I have outlined. It is important to recognize that getting software development to work is not just the purview of the programmers alone. Someone said, "War is too important to be left to the generals". If you'll allow the stretch, let me end by saying, "Software is too important to be left to programmers, and methodologies".

Why can't Tellers be Sellers?

Stepping into a debate that is as old as retail banking is perhaps unwise. There are passionate adherents ranged on both sides of the question. To some, the issue is not whether, but should tellers be sellers?

The question brings the raison d'etre of the retail branch network into sharp relief. Are branches retail storefronts with the primary mission to enhance customer relationships, or are they collection points for myriad transactions processed by centralized back office operations centers? Is the driving imperative one of customer intimacy, or does operational efficiency rule the roost?
A tilt towards operational efficiency has traditionally driven retail banking, with occasional overtures to the selling side of the equation. These overtures, however, tend to be fleeting, and with few exceptions, have not survived beyond some concerted marketing and employee incentive programs.

To understand why the push towards serving and selling the customer has not been sustainable, consider a few points. Making check deposits is by far the main reason customers visit a branch. When they do visit, the teller is the person they most often interact with. Regardless of all the training and incentives that may have been put in place, consider what tellers actually do. They are heads down punching numbers into keyboards (try counting the number of teller keystrokes the next time you're in a branch). They have barely enough time to complete the data entry and squeeze out a quick thank you before the next customer is at their window. Imagine a Neimann Marcus salesperson wordlessly packing what you've picked out and intently ensuring that the bow on the package is just right! Yes, the analogy is not quite right- but you get the picture.
So despite many a marketing push, it is the fundamental transaction tether that yanks the teller back into the role of a frontline operations clerk- the first cog in the vast infrastructure that we put in place to process paper checks, featuring planes, trains, automobiles and giant "paper factories".

There is an alternative, courtesy the legislative cover of Check 21 and advances in imaging and recognition technology. Teller Capture allows the teller to drop the entire deposit into a small foot print scanner and interact heads up with the customer, while an imaging application reads all the necessary information, ensures the transaction is balanced, and prints out a receipt when done. Teller Capture eliminates teller induced data entry errors, and also catches math errors up front. This "ready-to-post" transaction at the very beginning of the deposit stream results in major efficiency savings further down the value chain. It is as close to straight-through-processing as one can get in the check world.

"Not so fast," say some. "You want to make my tellers into check operators?" The reality is that the opposite is true. There is now evidence of major savings in teller time per deposit, including data from a Top 5 U.S. bank of having reduced keystrokes from 75 to 5!

"What about the cost of a scanner and software at every station?" challenge others. "It is really difficult to integrate these capture applications with teller systems." The cost per node for both hardware and software is steadily declining, making it well worth the while to examine the return on investment. The hard numbers on transportation savings, back office labor elimination, and funds availability make it interesting- leave alone the soft benefits in customer service and added sales. Capture systems are also increasingly being integrated into teller systems, both by teller vendors that have acquired check-capture technology, and pure play check imaging vendors that have certified their applications with leading teller vendors.

Coming back to the tellers-to-sellers paradigm, what do you do with the saved time? Do you use it to push even more transactions through? Do you have tellers refer customers to other branch personnel based on prompts from an integrated CRM system? Or do you have tellers take on more of a sales and service role themselves? Those are decisions that will be driven by your overarching strategic intent. Do you want tellers to be sellers in the first place? As you ponder that question, you may want to look at teller capture as an opportunity to cut the transaction tether that keeps pulling you back, yo-yo-like, to the paper factory of another era.

India- the new mobile frontier?

I just returned from India. The contrast between frenetic growth in the subcontinent and recession blues in the West is palpable. To be sure, India went through a mild downturn late last year. There was a slowdown in retailing, real estate prices came down a bit from speculatory madness, food prices skyrocketed and annual salary increases in the IT services sector came down to 7% and 10% from the 20's, 30's and beyond. But it is back to growth again for a billion plus Indians- in the number of automobiles, new highways and metros under construction, high rise buildings, and mobile phones.

With 500 million hand sets in use, India has more mobile phones than any country except China. It is adding to that base at a rate of around 35 million phones per quarter! Significantly, 92% of all phones are wireless- a clear indication that the country is leap-frogging the land line era. This in a country where in the not so distant past, a land line required a deposit payment and a waiting period of months (sometimes years) to get!

The phenomenon has benefited from a policy decision to open the industry to private sector competition, as opposed to domination by state owned monopolies as was the case with the wireline industry at the outset. Fierce competition has driven prices down to the point where many at the "bottom of the pyramid" can afford the service (BTW, C.K. Prahalad's book on the fortune at the bottom of the pyramid is a great read). Incoming calls and texts are free, encouraging consumer use, as well as businesses hawking all manner of products and services direct to the handset. Tata Docomo recently introduced a pay by second model at one paisa (about 0.022 cents) per second, which is bound to boost call volume.

In addition to mobile marketing, there are other mobile services that are poised to avail of the critical mass and growth in teledensity. Mobile banking is one area where we may very well see India leap-frog other countries. While only 1% to 2% of mobile subscribers use mobile banking services today, there is an enormous upside. Some of the common uses today are bill payments, insurance premiums, charitable donations, pre-paid mobile telephone recharging, and travel ticketing.

The Reserve Bank of India (RBI) has been both aggressive and strategic in building a regulatory framework to enable the growth of mobile banking. It issued guidelines for Mobile Banking Transactions in October 2008 addressing banking, money transfer, payments and commerce. RBI has since moved to swiftly revise some aspects of this guideline based on feedback over 12 months.

Arguably, the most well known example of mobile banking in the developing world is M-PESA in Kenya. It is widely used for money transfer by the unbanked and is run by the mobile operator Safaricom through a nationwide agent network. The RBI, however, wants banks firmly ensconced in the transaction stream, but with a twist. While funds have to be deposited at a bank branch, the disbursement of cash at the receiving end can be through an ATM or a bank-appointed agent. The RBI is thus ensuring the need for oversight through Know Your Customer (KYC) norms and the regulated banking system to address money laundering concerns in a part of the world where informal networks like "hawala" are rampant. It is also addressing the need for "last mile convenience" in a country with an evolving physical infrastructure. The not so invisible hand here is that of the RBI, nudging banks, mobile operators, and others with agent networks to partner to facilitate ubiquity and security.

Other RBI modifications include raising the daily cap on transactions from Rs. 10,000 (~$218) to Rs. 50,000 (~$1087), enabling larger purchases, such as airline tickets. At the other end of the spectrum, it also removed the need for end-to-end encryption for transaction below Rs.1000 (~$22) to remove the cost overhead on small transactions.

While the stage appears set for an upsurge in mobile transactions, led perhaps by funds transfers from banked urban workers to families living in villages, it is not easy to pick early winners in the race. Of the 32 RBI approved mobile service provider banks, 21 have launched services. The partnerships between banks and mobile service providers are yet to materialize. While India is known for its information technology prowess, most well known names are services companies. There are very few true product companies in the country that have embraced product management, development and delivery for general availability, and streamlined delivery and support of versioned products across large customer bases. That would spell opportunity for the many battle tested mobile banking product vendors in the U.S. and Europe, right?

Well, before you pack your bags for Mumbai, keep in mind that selling software into India is extremely challenging. Markets at the bottom of the pyramid are very price sensitive. They call for innovative price packaging like the one paisa per second model from Tata Docomo. In addition, while attitudes are changing, justifying value for software products in India is difficult. Races to the price bottom, regardless of other value attributes, are common. If your business model dictates recovery of Dollar or Euro based cost from Rupee sales, you can end up in a bind if you are not careful.

Despite the cautionary note, mobile services in general and mobile banking in particular are poised for explosive growth in India. We will see innovative services offered there before we see them in the West. It is a transformational journey of a billion people that will be exciting to watch and participate in. Mumbai, anyone?

Marketing Best Practices

It is difficult perhaps, to shed light on an often misunderstood discipline like marketing. In the minds of many, it is equated with advertising and promotion. In others, it plays a supportive role to sales as an administrative resource. When approached strategically, however, marketing can be a powerful source of sustainable competitive advantage.

Click on the link below to hear a webinar I did on the subject with the folks at Remote Deposit Capture. Com. While the presentation is geared towards financial institutions looking to offer remote deposit capture, the broad framework can be used in any business endeavor. Framework is really the key word here, as each of the bullet points can be expanded upon to drive tactical plans.

Enjoy!

http://www.remotedepositcapture.com/webinars/webinar.20091023.aspx

Changing Face of Check Fraud

Check fraud has morphed to adapt itself to the digital world. Here's an interesting article by Karen Hoffman in Banking Strategies that has insights from several industry insiders, including me.

Enjoy!

http://www.bai.org/bankingstrategies/risk-management-and-fraud/security-and-fraud/the-changing-face-of-check-fraud#

ET Phone Home (and zap up a check)

Mobile phone cameras have captured images of everything from election protests in Iran to the recent tragic collision of a helicopter and a small plane over the Hudson River. So, what could one possibly add to the list of things that would intrigue mobile shutterbugs? With apologies to Mr.McGuire in the movie The Graduate, "I have just one word for you. Just one word.....checks."

The recent announcement from USAA, allowing its customers to make deposits by sending images of checks taken with their Apple iPhones, brings together technologies from the 19th and 21st centuries. Until the advent of Check 21, the movement of deposited funds depended on the physical transport of paper. An extensive retail branch network was developed to act as collection points for deposited paper. USAA, which serves 7.2 million active and retired members of the U.S. military and their families from one branch in San Antonio, has consistently used technology to turn conventional wisdom on its head. Three years ago, it announced its Deposit @Home service that allows customers to make deposits by sending images of checks scanned at home. Despite early scepticism from many, USAA claims 150,000 users. The addition of mobile smart phones takes the remote capture notion even further.

In addition to this announcement, mobile deposit technology provider Mitek Corporation has announced relationships with Fiserv, RDM, NCR, and J&B Software to take the capability to their customers. As these formidable players get past their pilots and launch offerings, we will likely see more financial institutions make mobile deposit services available.

What about fraud, you say? Doesn't Check 21 require account and transit information to be read magnetically to ensure security? While I admit that the prospect of sensitive check images flying through the air can be unnerving, and there are issues of authentication, privacy and data integrity that need to considered (another post, another day), the fact is that there is no regulation that requires that the magnetic ink character recognition (MICR) information be read magnetically. In fact, Check 21 is silent on the subject. Thus absent regulation, it falls to the individual financial institution's tolerance for risk, versus the obvious convenience of the service.

There are two factors that can mitigate risk to some extent: the old dictum of knowing your customer (KYC), and the option to delay funds availability until the check has cleared. I believe we will see the adoption of mobile deposit capture in defined communities such as the USAA customer franchise, where the financial institution has a very good idea of risk exposure. Credit unions with well defined memberships are more likely to offer this service than banks (and like USAA, most credit unions are also not extensively branched allowing them to make virtue out of necessity). We will likely see the service offered to the "safest" customers first, based on their deposit history, followed by a gradual expansion using funds availability agreements as a tool to calibrate exposure.

The banking community at large has a different challenge. Deposit acceptance is arguably the raison d'etre for large retail branch networks. Remote capture in general, and mobile deposit in particular, poses an interesting channel conflict paradox (see BAI Insights for a summary of a presentation I did with Bob Meara from Celent on the RDC/Branch paradox). Thus, my take is that banks (particularly the larger ones) will perceive mobile deposit as a bridge over troubled waters and be reluctant to put their branch network at risk.

While I don't see the airways saturated with check images from mass deployment, I believe mobile deposit will do well through niche (not necessarily small) adoption. Technology providers, transaction processors, and financial institutions all have different but related niche marketing challenges ahead. Astute target market selection will likely govern success. The alignment of factors like service and product features, pricing (ex: who pays for the data plan for zapping all those images, and what's the payback?), as well as path-to-market partnerships, are imperatives to be carefully considered.

Image Payments- Commoditization Redux?

The payments industry has seen the uncanny repetition of a pattern. It starts with innovation driven by software companies, followed by ambitious "hockey stick" adoption predictions, fits and starts a la Geoffrey Moore's "chasm" model, an initial trickle followed by a torrent towards outsourced processing and a brutal race to scale and commoditization.

Not all that long ago, there were around thirty U.S. providers of in-house credit card processing software, addressing both the issuing and acquiring ends of the spectrum. Today, there are none that I can think of. A few providers remain, serving niche international markets which are yet to be served by giant multi-national transaction processors. The card processing market is otherwise dominated by transaction processors(or should we call them Software as a Service(SaaS) providers in keeping with contemporary monikers?).

The early years of both credit and debit card payments were characterized by battles for recognition by relatively unknown players, using innovation as a weapon of differentiation. The now distant introductions of electronic draft capture (EDC) and even the automated teller machine (ATM) were ground breaking and transformational. With the move to outsourced processing, however, the overarching imperative shifted from innovation to operational efficiency. Efficiency allowed scale, which in turn drove ever lower costs, resulting in tremendous operating leverage.

A few factors accompanied the shift to outsourced processing. There was massive consolidation in the rush to scale- independent software vendors were elbowed out in the melee. Banks exited the business, and allowed third parties to soon dominate the landscape, despite dire warnings from some that disintermediation could result in banks surrendering access to strategically important customer franchises. The rules of governance and the interchange system created by Mastercard and Visa provided the ideal platform for global acceleration. The availability of inexpensive telecommunications bandwidth and distributed terminal technologies has given us a world in which a card issued in Minneapolis can be swiped in Manila, and then processed by a switch in Melbourne, Australia.

Great, you say, but what does this have to do with imaged check payments? It is true that check images originate at more varied points, including branch back offices, teller stations, image-enabled ATMs, corporate offices, retail points of sale, and even people's homes. In contrast, card transactions are limited to points of sale and ATMs (not counting card-not-present transactions). The need to capture images of a certain quality, recognize amounts, correct errors, and balance transactions involving multiple checks makes this a more complex cat to skin.

Nevertheless, there are early indicators that check image payments are following a path similar to their plastic cousins. There has been significant consolidation in the industry with independent software vendors having been acquired by transaction processors- witness Metavante (AFS, Vectorsgi), Fiserv (Carreker), Fidelity (Bankware), to name a few. There is an acceleration of images being exchanged between banks through networks like Endpoint Exchange, The Federal Reserve, SvpCo, and Viewpointe. Independent Sales Organizations (ISOs) are adding check capture to their kit bag of offerings to the merchant community. While the so-called X9.37 standard for image exchange still exhibits Babel like inconsistency, it is markedly less opaque than it was a few years ago. The check scanner vendors are gingerly feeling their way towards including more check processing workflow capability in their devices, lest they fall afoul of their software provider partners.

So then, is the past necessarily prologue? Are we on a one way track to a First Data type transaction processing behemoth covering the span from capture to settlement?

Based on observation of industry evolution, StratEx, LLC predicts the following:

In the next five years,

• There will be no independent check imaging software vendors in the U.S.
• Core processors will convert acquired software companies into captive suppliers to assist outsourced item processing
• Severe price pressure on transaction fees will be the norm as core processors bundle (and perhaps give way) item processing with core deals
• The outsourced processing market will have several players serving niche markets dictated by institution size, and geography (dictated by sales coverage not technology)
• The commoditization will be most pronounced in consumer and merchant capture
• Branch capture (particularly teller capture) will not see as drastic an erosion in value
• Teller capture will increasingly be combined with teller systems as teller platform providers either make or buy their own capture applications
• ATM capture will continue on its very slow adoption curve

In ten years,

• There will be a significant consolidation of transaction processors for item processing as scale becomes all important
• This will include a few "bank agnostic" processors representing a replay of the disintermediation seen in card acquiring
• Merchant and consumer capture applications will become part of scanner firmware, resulting in a "terminal-to-switch" path typical of card processing today
• Merchant and consumer capture will also be widely available as embedded applications in home banking and accounting software packages (the latter facilitating the "bank agnostic" processing referred to earlier)
• ISOs will dominate the sale of merchant capture to businesses, with capture application enabled scanners being their flagship "plug and play" products
• There will be no interchange fee system for check transactions; rather there will be risk adjusted transaction fees depending on transaction type and source
  
  Whether or not these predictions are borne out exactly, providers and buyers of item processing software and services will be well advised to factor these possibilities into their strategic scenario planning.
  
  After all, it is always better to ask "what if" as opposed to "now what?"