Are we (IT in India) on the right track?

Well this post is just about my rumblings from my experience in the IT Industry :-( What makes me feel sorry is that lot of (IT) companies in India prefer to play it safe. In the sense rather than intellectual property they go behind constant flow of revenue. Which basically implies that most of the well established IT companies also don't prefer to risk it out to invest there resources into a product development, rather they would prefer to go in for a service contract with their customers which would atleast ensure them a constant revenue inflow for next few years. Part of this could also be because of the prevailing market uncertainties which is making them act double cautious. Having said that, personally i do believe that we (Indian IT companies) some where in the future would be faced with a situation where in we will have to start investing in developing products rather than just providing services. Because today, thanks to the rising salary costs, India is fast loosing its cost advantage to other competitors like Philipines which are much less costly than us. It would be very interesting to see how Indian human resources are prepared to face this challenge.

SCRUM Productivity Metrics

Sharing a short white paper that I have prepared on individual productivity metrics in a SCRUM project: As Peter Drucker once said “What gets Measured, gets Managed”. It is an old management adage that is accurate even today. Unless we measure something we don't know if it is getting better or worse. You can't manage for improvement if you don't measure to see what is getting better and what isn't. In that pursuit this short write up lists some of the individual performance metrics that could be used in a SCRUM project to identify the kind of performance a team member is putting up and identify areas of improvement and areas where in he or she is performing well. Though it is a known fact that SCRUM in principle gives prominence to teams rather than individuals and sticks to the principle that “You stand as a team, You fall as a team”. But on the contrary if one needs to manage, he needs to know what the weak link in his team is or he should make sure that his team members are improving with every Sprint or he needs to know how he could manage his resources in the SCRUM team, as these individual performances would ultimately stack up to the team performance. Hence Metrics comes in as an inevitable way to achieve this. As in most cases the metrics discussed in this write up as well needs to be measured relatively, vis-à-vis the individual’s earlier performance and/or vis-à-vis overall team performance. Individual Performance Metrics The details of the individual metrics suggested in this write-up are mentioned below: 1. Earned Value (Story Points Completed in Sprint)/(Story Points Estimated for a Sprint) The Story Points committed by a resource in a Sprint would be known mostly by the Sprint Planning meeting and the Story Point completed in the Sprint would be known at the end of the Sprint in the Sprint Review meeting. 2. Efforts per Story Point (Total hours worked in current Sprint by a team member)/( Total Story Points completed in current Sprint by the team member) Ideally as a team member works on more and more Sprints, over a period of time his understanding of the product and the technology used should improve, which in turn means that the effort he used to complete a Story Point should see a declining trend over a period of time. This metric is an indication of the learning curve of the individual resource. 3. Actual Effort/IEH (Actual Effort Spent by the resource in this Sprint)/( Ideal Engineering Hours(IEH) of the resource in the current Sprint) This metric is indicative of the extent to which a resource is occupied. This metrics should ideally be used in conjunction with the earlier metrics. 4. Defects per Story Point (Total number of defects in a Sprint recorded against the stories worked by the team member)/(Total Story Points completed in the current Sprint by the team member) This one is more of an individual quality metrics than a productivity metrics. Pre-Requisites The measurement of the above four metrics requires SCRUM projects to record the Story Points assigned to each and ever user story or task. Recording the efforts won’t suffice as efforts assigned to a task are only indicative of the time required to complete that task and doesn’t take into consideration the complexity associated with the task. Also IEH for each team member should be recorded during the Sprint Planning meeting. Illustration This section tries to depict some examples of the ways these metrics could be interpreted and used in a SCRUM project. 1. Illustration of Earned Value Metric The below chart (Chart1) depicts the earned value of a resource across the 7 Sprints he has worked. Here X-axis indicates the Sprint number and Y axis indicates the Earned Value figures. As required he has shown gradual improvement in the Earned value. But then this chart stand alone doesn’t give enough information. Hence we plot Chart 2.

Chart 2 compares the progress of the same resources vis-à-vis the average earned value of the rest of the team. Such charts could be used to derive conclusions as to which resource is mainly responsible for bringing down the overall team’s performance, which could eventually be followed up by a detailed investigation to know the exact reasons and thereby the corrective actions. Say for e.g. is it that the resource is under skilled and requires training or has some motivational issues etc. Looking just at Chart 1 we could have concluded that this resource performed badly in Sprint-4. But then when we consider Chart 2 we realize that the entire team had a negative trend in Sprint-4, which helps us come to the right conclusion that in Sprint-4 it was not necessarily an issue related to this resource alone, but something pertaining to the entire team which brought down the EV. This could be because of unclear requirements, or due to some other dependency. 2. Illustration of Efforts per Story Point Metric Consider the table shown below (X-axis represents resource names, Y-axis represents the Effort per Story Point) which depicts the Story Points completed by each team member in a particular Sprint and the total effort the team member had spent in that Sprint. Now in the first look it might appear that the resource AR is better than PN since AR has completed more Story Points as against PN. But a look at Chart 3 clearly depicts that PN seems to be more efficient than AR, as PN takes lesser number of hours to complete a Story Point. Ideally owing to the learning curve. Resource Story Points Completed Actual Effort Spent Effort / Story Point BH 24 46 1.916667 PN 16 38 2.375 AR 18 48 2.666667 SP 10 20 2

Similarly we could also use this metric to plot ‘Effort per Story Point’ for a certain resource across multiple Sprints. This will shed light on whether the resource has shown improvement in his productivity across subsequent Sprints. (E.g. Chart 4). With reference to Chart 4 the resource has shown improvement across the release except in certain Sprints (E.g. Sprint-4) which if need be could be investigated as to what was wrong in Sprint-4, which could yet again help the SCRUM Master/ PM know if this resource is good at certain kind of tasks and not good at some others, or he needs some training in certain parts of the product which he worked during Sprint4 etc.

Data Centres - Server Farm

The importance of datacentres can be understood from the gowing size and number of data centres across the globe.Companies go in for various approaches when they decide to go for a DC. Say for an banking application or applications which need real time information it is very necessary that data should be as close as possible, to make sure of the speed and also to make
it possible for the support staff to rectify the errors if any.This is the reason the computers in corporate data centres were often housed in the firm's basement and dedicated “server farms”.
On the other hand for companies like Microsoft & Yahoo datacentres are mostly used as data storage areas/systems hence for them the prioriy is safety and security rather than the speed as real time use of that data might be less. Hence such companies go in for some really secluded place say for eg: Quincy in the centre of state Washington, about three hours drive from the nearest city.
One of the major reasons for going for such far off locations is the geographical advantage that they possess. Some of these locations close to dams and rivers, there by making sure that ample cheap power is available, as power is required in lumpsome for Datacentres.To have a feel of the quantity of power required by these datacentres, i quote: Microsoft's $500mn facility in Chicago will need three electrical substations with a total capacity of 198 megawatts.
Prempted with above concerns and data centre regulations, companies are now trying to consolidate and simplify their computing infrastructure. Hewlett-Packard, the world's biggest computer-maker, for instance, is replacing its 85 data centres across the world with just six in America.

US Slowdown isn't Exactly Bad for Indian IT

Its a long perceived notion that US recession shall hit the Indian economy specially the IT sector really hard, but then there is a different school of thoughts as well. It says that the recession might not exactly be bad for the Indian IT sector.
A report from Gartner says US economic slowdown will lead buyers of IT services to consider increasing the percentage of their labour in offshore, lower-cost locations. India will remain the dominant location for IT offshore services for North American and European buyers as a result of its scale, quality of resources and strong presence of local and traditional service

With concerns that the US economic slowdown could extend to other geographies, organisations are refocusing on IT cost reduction and taking steps to accelerate the use of offshore labour, Gartner said. Buyers of IT services will shift from cost-containment goals to a greater focus on cost reduction and productivity increases in their sourcing decisions. This will lead to a steady increase in the adoption and expansion of offshore services - primarily from India, but increasingly from other countries as well.

But the flip side of the recession would be that there could be a drastic cut in the IT expenditure of these firms , meaning the indian IT companies might not be able to negotiate for increased charge backs.And with the salaries in the Indian IT companies increasing at a fast pace the IT companies might take a hit !

SatyamWay

Found this interesting piece of info while reading an interview of Mr.Ramalinga Raju , founder and chairman of Satyam Computers.This is something which happened in 1991 ,when the west wasn't very sure of outsourcing work to India.And its then that Satyam got its first fortune 500 client in India.This happened in US Midwest where in Satyam took up a rented house , across its customer's software development centre .Ten satyam engineers field tested the benefits of Global IT offshoring by pretending they were in India.They worked nights to simulate the time difference and for 6 months never met their customers across the street in person , communicating only through a dedicated satellite link"In the end the team worked better from this place called Little India as compared to working onsite"....

That was a really different way of proving ones's credentials.
From then on Ramalinga Raju an commerce graduate & an MBA has been on the path of trying out new things .Currently they are working on a new business model which they call the "Satyam Way".
will write abt the satyam way in my next post .....

Ref : Mckinsey Quaterly

OutSourcing Models

The rapid growth of indian IT sector has brought into picture various outsourcing models prevalent in the market.On the first look it might seem that outsourcing isn't a big nut to crack but then there are quite a few critical decisions which come into the foray while taking decisions pertaining to outsourcing some work.



From the fringe there are three vibrant types of offshoring models:



Joint Venture offshoring (JV)

Subsidiary/Captive Development Centre Offshoring

Service Provider OffShoring



Joint Venture offshoring

In a Joint Venture an organization ties up with a local firm or company either by taking an equity stake or by forming an independent company in which either of the companies contributes resources.A joint venture contract may sometimes include build-operate-transfer (BOT) clauses to motivate both parties to work towards a clearly defined exit strategy.



Subsidiary/Captive Development Centre Offshoring

Companies may decide to bypass the JV model altogether and go directly in for a subsidiary or local office if the management is comfortable in dealing with the nitty-gritty of internationalization and local market operations. Some of the popular terms used to describe the model include offshore development center (ODC), captive development center or in some cases simply branch or local office.



Service Provider Offshoring
The JV and subsidiary models of outsourcing may involve deep commitment on the part of a client organization, a move that management at traditional companies may sometimes be averse to. To counter the perceived risks of these models and to capitalize on the benefits of offshoring, companies resort to outsourcing projects, programs and individual work orders to offshore vendors.