Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« January 2013 | Main | March 2013 »

February 22, 2013

A cat has 9 lives... how many does outsourcing have?

Posted by Suman Sasmal, Vice President and Service Delivery Head - Application Development and Maintenance, Infosys

 

A cat has 9 lives, so goes the saying. I am not sure what a cat thinks of this, but the world of business would love to be like a cat!
 
And why not? Only 12% of the Fortune 500 companies has remained on the list every year since the list was introduced in 1955. And over 2,000 of them have appeared, disappeared and appeared again throughout their journey. Similarly, the average churn rate of FTSE 100 ever since the Index was created in 1984 is 14 per cent. Companies come and go off the list, to come back on it again. So, even if fierce competition or changing technologies drive companies off the list, many of them gather strength, adapt to situations and survive. Who said only cats have 9 lives?...

The world of outsourcing is no different. I am not talking about outsourcing companies who are on a particular list or have gone off it, but the art and science of outsourcing in itself and how it has evolved to stay relevant through the years!
 
Where did it all begin? Actually, it is as old as civilization.  In the early days, people had to depend on each other. A farmer did farming and, for his other needs, had to depend on a barber, a builder, a merchant and so on. One could not do everything on his own. So, people outsourced needs that they couldn't fulfill easily themselves and engaged with specialists to obtain their services. No one called this phenomenon outsourcing then, but that was truly the purpose of it. Centuries later, outsourcing started developing during the Industrial Revolution, and companies used it to drive profits & good housekeeping and slowly it became mainstream.
 
The offshore variant of outsourcing appears to have been initiated during this period as well. Nandan narrates this in his book Imagining India.....   "The whole argument for educating Indians in English was thus, in essence, to allow the British to offshore their governance jobs - replace British workers with Indian ones". This was in the context of introduction of English education in India by Lord Bentinck and Thomas Macaulay in 1835, when the East India Company's finances ran into trouble.  As outsourcing matured and business went global with changes in political and economic climate, MNCs like GE and Texas Instruments engaged with companies in other countries (read India). That really got offshoring initiated. And then came the IT revolution, the famed Global Delivery Model (GDM) and the rest is history. We all know that. We breathe it every day, live in it and as professionals in this space, we would experience its evolutions throughout our lifetime.
 
The early days of offshoring meant physically carrying tapes to India and working on mainframes and delivering them back to clients. With easing tariff barriers and declining telecom costs, this soon got replaced by an ability to work directly on client's infrastructure remotely. This expanded the market, as more types of work could be accomplished. The processes matured, confidence grew, trust was built and the brand India was established. One thing led to the other and today, literally every possible component of the business value chain is getting outsourced. Be it software maintenance or infrastructure upgrade, application development or RnD initiatives, transformational business program to call center responses - all are getting delivered remotely. As NRN puts it - globalization is about producing where it is most cost effective, sourcing capital from where it's cheapest, sourcing talent from where it is best available and selling it where you make the most profits
 
With expanding economic boundaries and globalization of business, outsourcing implies global-shoring today. And the model depends on a seamless orchestration of several factors. Talents, telecom, infrastructure, technology, processes, locations, economic cycles, political climate, contracting model, legalities, industrialization and innovation, among many others. A change in any or more of them can trigger another change and this causes the outsourcing model to evolve on a continuous basis. With interaction models of the society changing, outsourcing destinations expanding with each passing year, outsourcing becoming outcome sourcing, millions of applications and billions of users, open source and crowd source becoming a norm, gamification-mobility-automation taking center-stage - the future of outsourcing is going to be very different. I believe the incremental change of this model, thus far, will get replaced by something game changing. An iTunes or a Facebook phenomenon is perhaps waiting to happen.

2 Geographies, 3 Development Centers, 85 Engineers and One Common Goal

Posted by Kartik Matmari, Senior Project Manager, Infosys

I manage a services delivery program for a large software manufacturer in the world where we have 85 Engineers and managers, 3 different development centers spread across India and the United States. We use a perfect AGILE engineering model to deliver critical business functionality for the platform that is responsible for 95% of the client's revenue.

CIOs and IT Decision makers at global corporations continue to express their skepticism on the efficacy of an Agile engineering model involving multiple geographies, multiple time zones, different set of people from different cultures, multiple development centers etc.

I have been often approached by my colleagues from different accounts in Infosys to discuss the details of my program, how it's different from theirs and how we can adopt best-practices if any. I also got the opportunity to discuss the success of global agile delivery with the directors of a large US Retail giant who were skeptic about outsourcing work to Indian locations because they believed that Agile engineering model would not work in an Onsite-Offshore setup. My discussion with them was very positive and most of their myths were cleared and also influenced their IT decision in favor of a global delivery.

The most common arguments by CIOs/Directors/IT Decision makers against a global agile delivery model are:

"All members should be at the same location for Scrum to be successful"
"Different locations means lack of involvement of team members"
"X-Geo Scrum is not truly agile"
"Onsite Teams more productive than offshore teams"

I am sharing some of the most common points of discussion about global agile through some images and diagrammatical representation

The Need for a X-Geo Delivery 

  • Huge Cost Savings and Time Advantages (Follow-the-Sun) were the key drivers for adopting a X-Geo delivery by the customer.
  • High attrition and resource availability and loyalty at onsite location was a big challenge.
  • Customer did not prefer subcontractors due to various issues (Loyalty / NDAs / IP Issues / Accountability / Governance etc.)
  • Customer wanted to effectively leverage their own offshore captive development center in India.
  • Customer wanted a need-based ramp-up and ramp-down of resources via a strategic partner (Infosys)
  • Customer wanted to reap the benefits of having a resources available with cross-functional skills (Different Applications, Dev, Test, Build Engineering, Performance Testing)

 

How Infosys did it?

 HowInfy1.jpg

Challenges in SCRUM adoption

2.png 

 

Team Structure

teams.png

 

Scrum-of-Scrums (SoS)

A bi-weekly syncup of all scrum masters of various crews led by the release management team.  

sos.png

 

Communication Cadence

commcad.png

Above have been some of the critical elements of a geographically distributed Agile delivery model. Every program comes with a unique set of challenges and we cannot have a "one-size-fits-all" approach. However, some of the practices as mentioned above can be definitely considered in all programs dealing with similar challenges. 

February 5, 2013

Sometimes a self-inflicted pain is necessary to ensure success

self-infliction of pain-03.jpgPosted by Kartik Matmari, Senior Project Manager, Infosys

I was part of a large team at Infosys working for an application development program for a global customer. One of the good things of the program was a customer visit to the Infosys offshore locations every six months, after a large program release.  This regular customer visit was an integral part of the relationship as these "release celebrations" created a great sense of inclusivity and instilled a sense of importance and responsibility for everyone involved both at offshore and onsite locations. During these "release celebrations", star performers would be rewarded and recognized, key contributions appreciated and future projects and roadmaps discussed. ...


The customer team consisted of Senior Delivery Managers, Engineering leads and the Scrum coach. Project Managers and leads from Infosys always had an opportunity to discuss the strategies defined by the customer and we at Infosys, always looked forward for these meetings to bombard the customers with our questions.

On one such particular occasion, all of us were highly concerned about a new decision that had been taken. The decision was to reduce the Scrum Sprint from 4 weeks (20 days) to 2 weeks (10 days). Given that a Sprint end indicated a feature completion, a 2 week sprint would have made it extremely difficult for the engineering team to ship features. This decision did not go well with my team and me and  also with the customer's development teams that worked from their India IT center.

So, I took the initiative to lead the discussion with the customer and related stakeholders to understand why a decision as outlandish as this one had been taken.  I was sure that this would be a Work-Life Balance Killer and hence feared for my team's morale.  

As I started the conversation with the customer delivery managers, it was apparent that they were anticipating my questions. I started describing the disturbance this decision had created among the teams and how this would mean long work hours and near impossible targets, issues with team morale, work life balance, etc. After I finished my "tale of woe", the customer delivery manager said, "We understand every point that you made, but this is a self-inflicted pain that we have introduced in our engineering model to ensure success". A self-inflicted pain to ensure success! Can you please elaborate I requested?

By shortening the sprints they were encouraging "early failures" in development rather than late failures. Finding and fixing critical problems in the early stages of a 6 month project schedule was the key benefit of this decision. A critical integration issue introduced as a late breaking bug after 4 months of the schedule would jeopardize a release. They also mentioned that "Sprint failure is OK!", which was like a load off our shoulders, as till then all of us believed that when a Scrum team commits to a sprint scope, then the team has to deliver that scope, come what may.

They further explained that it's OK to fail in early sprints and that was the main intention of shortening the sprint. Early failures help in uncovering critical issues and clear the path as we progress into the schedule. It's important that the leadership team ensures that critical requirements are scoped into the early sprints so that the roadblocks to deliver the most critical scope are unearthed and fixed early in the schedule.

As I sat back in my chair, I felt relieved. What I heard made perfect sense. The new model gave us an opportunity to find and fix critical problems very early in the lifecycle. It made the work more exciting and also the "freedom to fail" warded off the fear among the developers and testers. It was accepted positively and very soon we started seeing the benefits of this so called self-inflicted pain.

February 1, 2013

Refreshing User Experience - Different strokes for different folks

In my last blog I wrote about the problems organizations face when running with systems with poor User Experience (UX). Having experienced these problems across various projects, I thought it might be a good idea to showcase the situations which may necessitate a change in UX for an organization and the options which can be used....

Option 1 - Out with the old, In with the new

One of the situations in which the organization considers a change in User Experience (UX) is when it has received a strong backlash from the end users. Bringing in a new system resolves this issue as the newer systems generally have considered user experience as a vital point during the build. Then there are times when business or other factors necessitate the need for the retirement of an old system. This provides the organization with another opportunity to get the user experience fixed. The third situation in which an organization looks for a UX replacement is during an upgrade of software. If the new software presents new flows and screens which demand a new interface, the UX may get replaced as well.

The key to success in getting a new system with a new UX is to recognize the role of UX early in the game and to have a strong change management program in place to ensure the changeover to the new system is as seamless as possible to the end users. Having an early buy in from the end users and training them right at the beginning can ensure that the system "starts off on the right foot".

Option 2 - A new cover for an existing book.

If the system under question contains valuable business logic and intelligence that might be difficult and/or expensive to recreate and if the problem is related only to the UX, building a new façade for the system could be an option. Assuming that the embedded business logic can be accessed externally, we can build a new front end to the system.

Another solution for the same problem are products which claim to provide new ways to access the old processes and steps but this only perpetuates the failure of the old system. Providing a web interface to the same green screen based system does not solve UX problems. It may help in reducing the licensing costs but does not resolve the UX problems.

Thus, while designing a new façade, it is extremely important to keep the UX needs in mind else it may result in the entire effort falling "flat on its face".

Option 3 - In-Situ fix

This is one of my favorite approaches. Many web applications developed before the dawn of the consumer age were developed completely from a developer's viewpoint. There was very little attention given to how the end users would actually benefit from using the application.This was particularly true of systems that were developed for use within the enterprise boundaries.
 
Refreshing the UX of these applications is relatively simpler given that almost all these applications had separation of the presentation and business logic to a greater or lesser degree. Here is where the processes of Heuristic Evaluation and UX Design can be leveraged to truly identify the issues and design a system that helps alleviate some of the pain. The expert UX designer can take a deep dive into the business process and the way the system implements it to pin point the shortcomings in the system and provide guidance on how those can be overcome.  

 

The circumstances of the enterprise and where the application is in its lifecycle will determine the nature of the fix. At times may be a combination of these will have to be deployed. After all, one size does not necessarily fit all.

What do you think?