Indian IT Industry

Arjun · Post by **Arjun** » 14 Oct 2012 06:29

matrimc wrote:Enterprise software services may be but sorry not products - enterprise or otherwise.

Matrimcji,

Check out the annual global rankings of top providers in technology for healthcare, financial software, risk and other vertical sectors...India has always been good at the business software end as opposed to infrastructure software. The US is the biggest consuming market by far - so it is natural for most of the biggest provider names to be American, but India is head and shoulders above any other country as far as vertical-specific software goes.

Vayutuvan · Post by **Vayutuvan** » 15 Oct 2012 00:20

Arjunji

I think we have different definitions of what enterprise products mean. I mean by enterprise products SAP, Manugistics, (or the older Mapics and Copics), Peoplesoft, and now Salesforce.com etc.. In my book, infra products would be compilers, OSes, Network stacks, DBMSs. Implementation, deployment, operations mgmt. of SAP (for example) in an enterprise would come under enterprise services. Also, there are other specialized software products - shrink wrapped - like CAD/CAM/CAE, embedded software products, device drivers, and miscellaneous scientific and engineering software products which are a small part of the eco-system. If you look at production/supply chain management products, these are dominated by Germans followed by US, CAD/CAM/CAE France, US and UK and so on. You might already know that a large part of the industry runs (used to run - but I don't think the situation has changed all that much in spite of all the hoop-la of clouds, SOA) on software developed in-house. This is where India contributes behind the scenes. But there are no products AFAIK from Indian software houses that have the market foot print like (for example) SAP. We can argue whether SAP itself is all that useful (there are cases high profile cases the implementations have failed) but it is a different argument.

FWIW

Arjun · Post by **Arjun** » 15 Oct 2012 11:23

matrimc wrote:I think we have different definitions of what enterprise products mean. I mean by enterprise products SAP, Manugistics, (or the older Mapics and Copics), Peoplesoft, and now Salesforce.com etc.. In my book, infra products would be compilers, OSes, Network stacks, DBMSs. Implementation, deployment, operations mgmt. of SAP (for example) in an enterprise would come under enterprise services. Also, there are other specialized software products - shrink wrapped - like CAD/CAM/CAE, embedded software products, device drivers, and miscellaneous scientific and engineering software products which are a small part of the eco-system. If you look at production/supply chain management products, these are dominated by Germans followed by US, CAD/CAM/CAE France, US and UK and so on. You might already know that a large part of the industry runs (used to run - but I don't think the situation has changed all that much in spite of all the hoop-la of clouds, SOA) on software developed in-house. This is where India contributes behind the scenes. But there are no products AFAIK from Indian software houses that have the market foot print like (for example) SAP. We can argue whether SAP itself is all that useful (there are cases high profile cases the implementations have failed) but it is a different argument.

Yes, I realize you had horizontal market products (CRM, ERP, SFA, EAI...) in mind, as opposed to vertical market products. Sticking to the latter, take a look at this: Core Banking Vendors - Top 15. India comes in right behind the US amongst the top providers of core banking software - in fact if one extends the list to top 25 or so, the India % would only increase. Btw, #1 (Oracle FSS) is also the old-iFlex - an Indian firm which is now American.

Anyways, the US + Europe still constitute 80% of global software consuming market. For a firm of non-Western background to break into this market is not just a simplistic issue of acquiring the necessary talent (which may in fact be easier for Indian firms given the demographics)- but more an issue of breaking cultural barriers. India has been far ahead of other non-Western countries on this count. As the market evolves in the future to become more balanced in worldwide consumption - acceptability of India-based firms would only go up. There are also other issues to consider:

- There have been quite a few Indian-American firms successful on the horizontal products side (i2 for example)...if the market is defined as largely American, it makes much more sense to register a firm in the US rather than in India.

- Products do not automatically imply higher value than many high-end services (either in margins or growth potential). In fact most software product firms in India are valued at lower multiples than the service firms

Vayutuvan · Post by **Vayutuvan** » 06 Nov 2012 02:18

IT, but not specific to Indian IT. Nevertheless, I think it warms the cockles of those who have made the decision to stay technical and not move to management. The comments are quite interesting too.

Why Coding At Fifty May Be Nifty

ramana · Post by **ramana** » 06 Nov 2012 03:15

Not a programmer by any stretch but once wrote (1987) a Turbo Pascal program that would spit out the major and minor dia meters for Amercian screw threads to help the inspection guys not having to consult the Machinery handbook.

It really was rewarding to see the thing print those useful parameters.

Yes its like a puzzle but once it fits tis not fun anymore.

Vayutuvan · Post by **Vayutuvan** » 06 Nov 2012 03:50

Ramana garu, very true. Once you have finished the program, then its onto more different types of problems. That is the reason why programmers do not like maintenance projects.

Singha · Post by **Singha** » 06 Nov 2012 07:45

comment on the /. article

Now I'm doing a ******** child of agile that the company has brought in and I cannot do anything for longer than 2 hours without having to go back to the scrum board for more work. Don't they know they can just point me at a problem and I'll get it solved - it is what I've been doing for several decades after all.

I guess the agile stuff is for the kids who can't concentrate on a task for longer than an hour and have to keep being told what to do or they'll just start looking at facebook and twitter all day.

Sachin · Post by **Sachin** » 06 Nov 2012 10:43

matrimc wrote:Nevertheless, I think it warms the cockles of those who have made the decision to stay technical and not move to management.

Hmm.. but coming to the bit IT-Vity Majors (and Cols & Brigs). How many of such companies really have old-time programmers? Say a chap who joined as a technical consultant doing programming, and nothing else even after putting 6-7 years into it. Slowly but steadily I feel there is a push to either move him to some other position, which certainly does not require hands-on programming. Some of them are show-cased as "Technical Architects", but dont know whether the companies they work for really are architecting some thing new. Most of them are now purely into maintenance jobs. Some senior folks get into Management role (which as one gentlemen put it, is nothing but the old job of "Expeditor" in a new Avatar). At least in the big time IT Cos in India, I feel getting a higher pay scale purely by doing programming for umpteen number of years may not be an option at all.

I dont know about Product based companies. The only chap I know who sticks to programming (say for the last 10 years) is one who is into Mainframe based product development for a mid-sized business. They are part of that business' IT wing. Pretty okay life, with an okay pay scale. Their scope of activities are very limited, and releases etc. are well scheduled. If this gent had a very good hobby, it would have been even better I feel

.

Personally, I would have sticked to programming if folks high above me did not constantly change their minds, or I could take up some activity with a clear cut and well defined time lines. At one point of time, I just could not continue with activities which needs to be done in say 4 hours flat, always and every time. Working on a shift basis, and then holiday working was another problem.

ArmenT · Post by **ArmenT** » 06 Nov 2012 12:19

Singha wrote:comment on the /. article
I guess the agile stuff is for the kids who can't concentrate on a task for longer than an hour and have to keep being told what to do or they'll just start looking at facebook and twitter all day.

That comment is probably dead on target. In the words of one Ravi Mohan, a blogger that I like to read:
http://pindancing.blogspot.com/2009/09/ ... ow-by.html

The problem with agile is not “consultants” per se but “consultants” who have no credibility building and delivering great software.

For Games, when John Carmack or Tim Sweeney advocate agile for game studios, I’ll listen.

When its someone who has no product we can judge, advocates a methodology that failed in its very first project, where it originated (spare me the redefinitions of “failure” If the client kicked the team out that is “failure” enough for me) that is a different kettle of fish entirely.

Next time an “agile consultant” pitches for your money, ask him to show you code he has written that made a substantial change in your domain.

“I wrote/ led-the-team-that created Doom/Unreal/World of Warcraft” is acceptable.

“Oh yeah I created this uber cool enterprise system which you can’t look at and I don’t have any open source code, but I know how to write clean code and to “lead” teams, cross my heart” isn’t."

Yogi_G · Post by **Yogi_G** » 06 Nov 2012 18:13

Dang, I am the technical architect for one of the hottest Scrum products in the market and yes that comment did crack me up. But smiling all along will be the manager who has a high level view of tasks completed across releases/products/programs etc etc. A good Scrum tool can make life easy for a developer and the managers would love the ones with a good dashboard.

Yogi_G · Post by **Yogi_G** » 06 Nov 2012 18:19

With the services model it is very difficult to get good margins with 10 years experienced programmers. The small ones find it especially tough to shunt out the very experienced technical people once it is realized that they wont be able to do well on the "management" front. The product companies try to cut costs too and usually try to outsource the implementation/coding part to third party companies with services model and only have architects/business analysts on their teams apart from the routine "manager".

As has been discussed to death in BR, most project managers in the services model IT companies dont do any estimation/scheduling etc etc, they just do routine interference, handling fall outs after appraisals and "proposals/value addition ideas/presentations" to further augment revenue. Seeing the kind of day to day lies and manipulation my project manager would do I took a pass when the project manager designation was offered to me and went into the technical steam.

negi · Post by **negi** » 06 Nov 2012 18:27

Scrum actually makes things too robotic (for lack of a better word) for the code junkie , the latter in most cases like to work alone and at time of their liking they are fine with being given a delivery date but hate having to send in status updates everyday and run back to some scrum tracker to update the current status. In the service segment since most of the ITVTY companies are having to deal with major clients who have been already convinced by likes of Mckinsy, PWC, Accentures and Deloittes as to how they can reduce costs and prevent projects from going over-budget by following SCRUM the former in most of the cases are left with no choice but to march to the tune of whoever sold that idea.

Thankfully the product dev side is still untouched by such stuff .

SaiK · Post by **SaiK** » 06 Nov 2012 18:34

if you can maintain a good backlog, and review them periodically there isn't any chicken on the project. managers think they are the chicken and go the extra length to just nominate a scrum master from a dev group. that is the most stupid chickening out deal any company can do.

scrum is all about controls.

Aditya_V · Post by **Aditya_V** » 06 Nov 2012 21:32

negi wrote:Scrum actually makes things too robotic (for lack of a better word) for the code junkie , the latter in most cases like to work alone and at time of their liking they are fine with being given a delivery date but hate having to send in status updates everyday and run back to some scrum tracker to update the current status. In the service segment since most of the ITVTY companies are having to deal with major clients who have been already convinced by likes of Mckinsy, PWC, Accentures and Deloittes as to how they can reduce costs and prevent projects from going over-budget by following SCRUM the former in most of the cases are left with no choice but to march to the tune of whoever sold that idea. Thankfully the product dev side is still untouched by such stuff .

Ever worked for Big 4 and been under constant pressure to show 100% utlisation which 150% time to complete, i.e book 8 hours and asked to justify why 8 hours. These firms have brought thier internal culture into a consultancy reports which makes life for people crap. BTW why did you leave KPMG and EY and signle out the PWC and Deloitte?

Employees at these firms have constantly justify thier time, you are constantly asked for the details of time you spent in the day, what did you for every 1/2 hour and then told you wasted 3 days in a week and you are incompetant lout.

No partner ever likes to see his staff in the office, they are supposed to be busy at client place working mechanically and efficiently in getting them a billing. They probably run the most profitable business with 50% margins as partner profits. But most Big 4 partners are also mentally not so stable especially in India, you can't be normalafter risign up to be partner in an Indian Big 4 or even an international one.

KJo · Post by **KJo** » 06 Nov 2012 21:49

Scrum, Agile, XTreme Programming are all a load of crap. If you have sucky programmers and managers, there is nothing that can save you or the project. All these are scams by the companies that promote it as the new silver bullet to all problems. Kind of like Islam, Christianity and other religions that claim to fix all and acquire a fan following through extensive marketing.

RamaY · Post by **RamaY** » 06 Nov 2012 22:03

As usual I disagree to agree.

My experience and perspective is that majority S/W engineers (I would put it >60%) have no sense of 'productization of the code they write'. They simply write code and do not understand the simple fact the real life of the s/w is after the project is delivered.

Agile, like any other methodology, is just a methodology; meaning a best-practice on how to approach the s/w development process. So it's success/failure like any methodology is 100% dependent on how the team understands the business requirements, designs and architects, implements and validates the s/w against those business needs.

The

of S/W engineers is just another

. They cried about every methodology that demanded them to spell out what they are doing and verified their words with their work.

I cannot respect a s/w engineer who says that he cannot give me a deployable and consumable increment of the s/w in a 2/3 week time box. That means his play pen is full if **IT.

If a s/w Engineer is capable of giving a consumable/deployable increment of s/w every two weeks, then I wouldn't mind calling his process AoA and live with it.

RamaY · Post by **RamaY** » 06 Nov 2012 22:09

KJo garu,

As a Manager and future Exec you are expected to not only believe in this crap but also demonstrate the value it brings in. So prepare your Taquiyya/Tawariya PPT templates on Agile

Yogi_G · Post by **Yogi_G** » 07 Nov 2012 11:56

Guys,

I have had it with service companies and product companies which practise taqiyya by saying they are product companies by in reality are deep down are a service company.

I am looking to move to some nice cozy IT dept (if such exist) in one of the big companies whose core business is not IT. Now I am not aware if these even exist but if anyone is in the know kindly answer the following questions,

1. Will the pay they offer be on par with the "IT" companies?
2. Will there be step motherly treatment for the IT dept in these companies.
3. How will career growth be, will the ultimate rung in the ladder be the IT dept head and nothing more than that?
4. Can you name some such companies in Chennai who have IT departments where I can expect to get a good Java Tech Lead/Architect kind of positions?

Singha · Post by **Singha** » 07 Nov 2012 13:04

atleast in paschimi financial sector, a lot of guys become "VP IT" quite quickly by mid 30s. but they would not get a real position of power on the financial side of the house...they would not be financial types anyway, but the ulta is quite possible - a sales or finance side guy being VP/GM of a IT outfit!!

in terms of funding these paschimi cos seem to spend a lot of cash on servers, networking and such. high frequency algorithm driven trading means they need ever faster and low latency infra and some pay for onsite vendor support during trading hours.

Sachin · Post by **Sachin** » 07 Nov 2012 16:06

RamaY wrote:They cried about every methodology that demanded them to spell out what they are doing and verified their words with their work.

This alone would take the wind out of the sails of many folks. I know cases where Engineering graduates who know how to do basic coding, show cased as techno-functional consultants who are also suppose to know how the business works. A B.Tech chap with 9 months programming experience is suppose to understand the business from a veteran with 10 years experience at the other end. And I dont think any methodology would help in such cases, as it is a a wrong man put on a wrong job.

PS: Any good links which gives a basic understanding of Scrum, Agile etc.? I am so far saved from these methodologies. But heard of a methodology in which they have daily morning stand-up meetings

. It reminded me of the Parades and Roll Call parades we had to do *.

* And this I have still seen in many uniformed forces, and I feel it is good for passing down orders and getting quick feedbacks/short reports.

Yogi_G · Post by **Yogi_G** » 07 Nov 2012 16:16

Scrum is so yesterday. Most projects these days are a hybrid of development and support which is an ideal candidate for the kanban methodology. This just in time methodology was brought in from the automobile industry (Toyota) and is an ideal candidate these days for the hybrid model of projects. Its also not uncommon to see some projects using scrum for their development and kanban for support.

Once I learnt kanban I realized that it is just plain common sense in the form of a methodology. I used to manage a 22 member team using the same tools without realizing its called kanban

RamaY · Post by **RamaY** » 07 Nov 2012 17:38

Yogi_G wrote:Guys,

I have had it with service companies and product companies which practise taqiyya by saying they are product companies by in reality are deep down are a service company.

I am looking to move to some nice cozy IT dept (if such exist) in one of the big companies whose core business is not IT. Now I am not aware if these even exist but if anyone is in the know kindly answer the following questions,

1. Will the pay they offer be on par with the "IT" companies?
2. Will there be step motherly treatment for the IT dept in these companies.
3. How will career growth be, will the ultimate rung in the ladder be the IT dept head and nothing more than that?
4. Can you name some such companies in Chennai who have IT departments where I can expect to get a good Java Tech Lead/Architect kind of positions?

Again my 2cents on career advise.

Every company has a core business. For example an IT (services/product) company's core business is IT where as all other functions (product mgmt, hr, finance etc.,) are supporting functions. Eventhough a company (say ADP) has IT as its core comparative advantage, its core business is different - payroll processing in this example.

It is always advised to work in a company whose core business is your core field of competence. This will ensure that your career/intellectual aptitude is satisfied and encouraged and you are paid handsome.

RamaY · Post by **RamaY** » 07 Nov 2012 19:10

Sachin wrote: PS: Any good links which gives a basic understanding of Scrum, Agile etc.? I am so far saved from these methodologies. But heard of a methodology in which they have daily morning stand-up meetings . It reminded me of the Parades and Roll Call parades we had to do *.

* And this I have still seen in many uniformed forces, and I feel it is good for passing down orders and getting quick feedbacks/short reports.

Gurudev,

Did not study many books on any topic

This is my 2 minute pitch on s/w methodologies.

Water-fall/SDLC methodologies - Key is coming up with a good Work Breakdown Structure, resources and dependencies. And the intellectual part of the methodology is to identify the critical paths and managing them. Everything else is collecting the data and re-calibrating the critical paths. Here your Time to Market is length of the Critical Path.

OODs - Key is to identify key business/technical entities and defining how they interact with each other and user. If you defined an entity or relationship incorrectly you end-up creating s/w jambies. Here your Time to Market is the duration of a meaningful object interaction (unless you do parallel jambie work).

Agile - Key is to define consumable requirements along with their business value in a way that they can be developed in one iteration. Once you achieve that your agility comes from the fact that your team know (self-aware) their velocity (how much 'consumable' work they can produce in an iteration - and not a mountain of incomplete stories) so they do not take any more work than that; and the business side have the ability to change their priorities every iteration if needed. The s/w is useful after every iteration. So your Time to Market is reduced to one iteration. How cool is that?

KANBAN - Used as a nice escape route to not to complete a unit of work in one iteration unfortunately. But the keyword here is the number of work items that can be in Queue at any given point of time. If you have more than 5 items in Work In Progress state, then you are losing the advantage of Kanban.

The biggest opposition I observed against Agile is from these points of views
1. My work is so complicated that I cannot define stories that can be completed in one iteration. This means the team is not thinking or do not want to think before talking or writing code.
2. I don't understand story points and how they somehow make me estimate work. Agile is not an estimation tool. Story Points are the new currency your team is allowed to define. How cool is that? If you like you can call them idlies or dosas or coconuts. Who cares. Imagine saying this story is 5 idlis.
3. I cannot verify this work at the same time the team is developing. That means one is pushing code and not functionality.

The benefits I derived from Agile (I think I posted this before)
1. For a Top5 consulting company which owns a product - We reached a sweat spot where we can safely estimate the story points for a given story. Since we know our budgets and costs, I can tell the business user, your story cost you $50K. Do you think it is worth that money if this story is for one specific customer who is paying say $400k license fee. Is this so important that the customer will look for a competing product?

2. For a Top5 product company which is one of top 5 best employers in the world - The S/w release process is decoupled from the development process because every iteration is a releasable product. The product management team can decide which iteration cut they want to give to a customer based on the product functionality. In a major release as the iterations passed (estimated to be a 14 iteration long release) the product was released thrice (after iterations 3, 7 and 12); the release after I7 being a new customer whose key requirements are introduced/prioritized in I6. The most interesting thing is the team is disbanded between iterations 8 and 9 for 3 months to help release another product.

3. For a Top5 Services company in India - Remove the stress of delivery from the Onsite/Offshore delivery team and put the onus on a small team of onsite coordinators (1:20 ratio) where the onsite coordinator acts as the scrum master (for 2 teams) and make sure that the team is focusing one iteration at a time. This also made the services company make the resource attrition transparent from its commitment to the customer

Singha · Post by **Singha** » 07 Nov 2012 20:56

imo given sufficiently high quality of engineers and managers relative to the task at hand, any methodology will work fine. efficiency might vary with the domain of the project and the method used. a good org will match the methods used and process flow to their own needs.

but no method or process can save a project from the wrong people!

Yogi_G · Post by **Yogi_G** » 07 Nov 2012 23:37

RamaY wrote: KANBAN - Used as a nice escape route to not to complete a unit of work in one iteration unfortunately.

Thats the general idea ji. Kanban is for those projects where any form of iteration is not possible. Some tickets take 1 hour and some take 3 days to complete, so what will be your sprint? Kanban is for these very scenarios where a fixed model iteration is simply not feasible.

RamaY wrote: But the keyword here is the number of work items that can be in Queue at any given point of time. If you have more than 5 items in Work In Progress state, then you are losing the advantage of Kanban.

5 is not a fixed number. In most of my trainings for end user customers I see this common perception of a fixed number of in progress items (actual term being WIP limit) while in actuality it is not. The manager sees a trend and then decides on the number across each phase of the work cycle. Some projects may have 100 items in progress for testing while others may have only one. It all depends on team size and lead time factors to arrive on a number which can again be further optimized.

RamaY · Post by **RamaY** » 08 Nov 2012 00:19

^ Yogi_G garu

Sprint duration is a fixed time box (generally between 1wk to 3wks for software projects). So if a unit of functionality (user story) is below the sprint duration (as in your example), then you do not need Kanban.

Kanban is for scenarios where you cannot achieve a reasonable ratio of cross-functional team (for example: User:Developer:Tester:Doc:etc) because each user story is so diverse in usage of this ratio. That is when you go for Kanban.

Kanban is a manufacturing sector innovation because in Ops Mgmt because some process dependencies on variables like time required/ not suitable for automation / cost of m/c etc., Then you define what is the LCD to ensure that your assembly line is NOT resulting in half-finished goods and warehouse costs.

Kanban in IT industry is "mostly" for Paki reasons (I am sure your organization is using it for valid reasons) because the developers do not want to wait to claim (story completion) the story points until others are done and so on. It is more of a process and organizational problem than a s/w engg problem, IMHO.

P.S: Standard disclaimers apply (there always exist exceptions)

RamaY · Post by **RamaY** » 08 Nov 2012 00:23

Singha wrote:imo given sufficiently high quality of engineers and managers relative to the task at hand, any methodology will work fine. efficiency might vary with the domain of the project and the method used. a good org will match the methods used and process flow to their own needs.

but no method or process can save a project from the wrong people!

wise words!

My experience (I have a reasonably above average exposure to project/program mgmt discipline than most of the program managers in the industry) is that the real issue is organizational (hierarchy).

It is often the middle mgmt that is the problem. As a project/program manager I wouldnt introduce a process/methodology to the organization unless I have their consent, so that issue is not there. And the team members (the actual developers/testers etc) can be educated/debated and won.

negi · Post by **negi** » 08 Nov 2012 00:38

Well I figured an easy way to stay out of all this process oriented BS, work for smaller orgs (small in terms of total number of employees) . You get to work on lots of different stuff, no hard and fast rules on whether to break an egg from big/smaller end, no dress code and more importantly people at the top tend to be hands on sipahi types so they tend to relate to a code junkie's pain. Did my share of flying in and out every week when I was at EMC but all that glamour of consulting doesn't last more than a month, what will I do with hotel/air reward points when weekends are spent doing expense reports, laundry and preparing for next week's assignment ? More importantly no weekly/daily status reports.

Bade · Post by **Bade** » 08 Nov 2012 00:48

We have no defined processes at work here, but all works fine. I would like to keep doing code changes that suit my exploration desires. If one has to scope and plan it all, then creativity goes through the door. As you guess I do not work in IT industry, but using IT is the bread and butter to get anything done in our shop.

Each to his own. Reading this thread makes me feel unemployable, but negi's post does raise some hope.

Sachin · Post by **Sachin** » 08 Nov 2012 15:00

RamaY wrote:Sprint duration is a fixed time box (generally between 1wk to 3wks for software projects).

Now that I did some self reading of Scrum etc., I realised that a project which I did nearly 6 years back was basically following this methodology. The sprint duration, and the general modus operandi all now looks familiar

. And this methodology was recommended by our client (who had out-sourced the development work to our company).

To be honest, quite a number folks left the project right after the stipulated time which is set by the company. Things started going hay wire, when our own management started putting too many "user stories" in an iteration, to prove that we can do more. This naturally led to working over time to complete all designs in the prescribed time limit. The pressure continued on during the development cycle as well. There was one short sprint for bug fixing, and that was another challenge because the rush in the earlier cycles introduced more bugs. And the commitment was to deliver each Increment with zero critical defects. One Sprint is over, the next Sprint backlog was ready. And On and on..

And so I do agree that all methodologies, frame works etc. all go waste, if we dont have the right people on the right job. In the example I quoted things became even worse, when the people who replaced the leavers were very much less experienced. They could not work according to the Sprints set by the customer.

RamaY · Post by **RamaY** » 08 Nov 2012 18:52

One frequent reason for a scrum-team breakup is the 'developers' urge to close the story as soon as they check-in their code. The functionality is not usable unless it is verified by QA and Users and signed-off.

So assume you took 6 stories worth of 15 story points in iteration 1. And you completed (meaning Done criteria including QA/UAT) only 8 points worth of stories. The second iteration you are not supposed to take new stories for more than 8 points. Then assume the team completed the 7 points from 1st iteration and 4 more from 2nd iteration, then the third iteration scope is only 11 points worth of stories. In 4-5 iterations, the team will reach their natural velocity, say 13 story points; then that will be their general velocity with very limited variance (+/- 10%)

The problem is when scrum masters (or team over powered by the developers) demand that the team takes another 15 points worth of stories in Iteration 2 because the stories are development complete. That is the trap people walk in to, in the name of loading the developers. That means the definition of the team is changed to 'Developers' only and the 'done criteria means dev complete' only.

Another issue with developers is that they think their 'task' is complete as soon as they check-in their code, however buggy it is. At one point I put a -ve point for every defect the developer's code gets and +ve point for every defect tester finds and used it as a (not the only) measure to determine their year-end bonus. After a year my dev:tester ratio came down, and the savings are passed to the developers

When I started working in 1994, we didn't have the specialty called QA team in my team. So we are required to test our own code. And we could not mark the "task" complete until we are sure the s/w works as it is expected.

Similarly in SDLC, the tasks are marked completed as soon as the coding is complete and QA tasks are defined separately at the end of the project plan. Even if you are using SDLC, if you write your project plan in such a way that all the activity related to a piece of functionality is put together and your task is not complete unless it is accepted, your critical path might look differently.

at the end of the day 'Yat Bhavam Tat Bhavati'. All these methodologies are to improve the efficiency and effectiveness of an organization. When it is viewed as a tool to make one's work life productive and utilized properly then it becomes very effective. It is same as a knife in the kitchen. The tool has no karma on its own and it will not achieve any karmaphala of it's owner's actions.

Abhijeet · Post by **Abhijeet** » 09 Nov 2012 20:24

Back from the NASSCOM Product Conclave in Bangalore, a 2-day event designed to promote software products coming out of India. Very well organized event with a number of good sessions and everything running very smoothly.

There is lots of activity in this space and many smart people who are now comfortable stepping out of the outsourcing companies' shadow. There are two major hurdles that I see: (1) lack of early stage funding and (2) lack of a large enough domestic market for most software products (which I've written about before).

The early stage funding scene is slowly getting better and investors are gaining domain expertise and confidence in certain areas (e.g. ecommerce). Small market size for most products will remain a problem -- it means that most startups are still focused on offline-online hybrid models or foreign markets.

pgbhat · Post by **pgbhat** » 10 Nov 2012 07:46

negi wrote:Well I figured an easy way to stay out of all this process oriented BS, work for smaller orgs (small in terms of total number of employees) . You get to work on lots of different stuff, no hard and fast rules on whether to break an egg from big/smaller end, no dress code and more importantly people at the top tend to be hands on sipahi types so they tend to relate to a code junkie's pain. Did my share of flying in and out every week when I was at EMC but all that glamour of consulting doesn't last more than a month, what will I do with hotel/air reward points when weekends are spent doing expense reports, laundry and preparing for next week's assignment ? More importantly no weekly/daily status reports.

+1 plus No time sheets. WFH and you get to make up your own processes.

symontk · Post by **symontk** » 10 Nov 2012 12:51

So assume you took 6 stories worth of 15 story points in iteration 1. And you completed (meaning Done criteria including QA/UAT) only 8 points worth of stories. The second iteration you are not supposed to take new stories for more than 8 points. Then assume the team completed the 7 points from 1st iteration and 4 more from 2nd iteration, then the third iteration scope is only 11 points worth of stories. In 4-5 iterations, the team will reach their natural velocity, say 13 story points; then that will be their general velocity with very limited variance (+/- 10%)

The problem is when scrum masters (or team over powered by the developers) demand that the team takes another 15 points worth of stories in Iteration 2 because the stories are development complete. That is the trap people walk in to, in the name of loading the developers. That means the definition of the team is changed to 'Developers' only and the 'done criteria means dev complete' only.

This is not SCRUM or Agile, this is only a short waterfall of 2 weeks or 4 weeks. Agile methods insist that testing happens together with the code development. So there is no way that developers are resting and testers are testing. Both are part of development team and should be working together

BTW, I havent figured out the way on how to do it in my project

Apart from S/W industry, any other industry uses Agile? What is the result? Can we travel in a car / plane developed thru Agile?

Arjun · Post by **Arjun** » 10 Nov 2012 13:15

Abhijeet wrote:There is lots of activity in this space and many smart people who are now comfortable stepping out of the outsourcing companies' shadow. There are two major hurdles that I see: (1) lack of early stage funding and (2) lack of a large enough domestic market for most software products (which I've written about before).

Abhijeet, wouldn't the fact that 'most people in India have limited mental faculties' also act as a major hurdle to success of Indian product firms?

Abhijeet · Post by **Abhijeet** » 10 Nov 2012 14:12

Ha - touche! Yes. Poor employee skills is definitely a major problem as well -- somewhat mitigated by the fact that product companies do not need as many employees as services companies.

I see the other factors as more immediate gating factors, but you're quite right that poor human development is another major issue. What's happening is that a few smart people -- generally recent college grads -- band together and form a product company. Most product companies are still in this stage of very early development with a few cofounders. Once product companies need to scale up rapidly in terms of employee numbers to SV levels, they will have a very hard time keeping up employee quality.

Abhijeet · Post by **Abhijeet** » 10 Nov 2012 15:31

To add to the comment above: it would be flat out impossible IMO to build a Google type organization consisting of thousands of very high quality people in India, because it would be impossible to find very smart people on that scale, or to make them relocate if they were outside India. Google Bangalore is pretty small on the prod dev side for this reason. Many "product" companies that have scaled up -- for example Flipkart and other online retailers -- can make do with fairly average people in operations, as long as the people at the top are high quality.

However, I think it will require access to capital and addressable markets to expand significantly before Indian product companies achieve enough success to make this a gating problem.

gakakkad · Post by **gakakkad** » 10 Nov 2012 21:51

lack of product companies in India is mainly due to lack of creativity ..

markets don't exist ..they have to be created ... air plane market did not exist when wright brothers invented it in 1903...neither did exist the market for web search targeted advertising before g-chacha was created...

likewise you don't find smart people on a large scale... you take regular people and smarten them on a large scale...the problem in India is however the inability to spot smart people...

There is an interesting story behind the simplicity of g-chacha interface..When the search engine first went online the founders of google (Sergey brin and larry page) did not know HTML...so they had to do with a simble bare minimum interface...

http://alan.blog-city.com/an_evening_wi ... _mayer.htm

Now supposing the 2 were born in Yindia turning up for interview at infy or any other Yindian company , they would likely not have been hired for there inability to encode in HTML...narrow minded Indian employers would never have gone past there inability to encode in HTML...

g-chacha is an example of amreeka spotting the talent it has ...it is surely not an example of amreeka having more talent...

pentaiah · Post by **pentaiah** » 10 Nov 2012 22:08

lack of product companies in India is mainly due to lack of creativity

Very true Saar ji

Look at the tenders of DRDOs OFPs
Ak-47 ammo
Diesel engines
UAVs
Electro optical transducers sensors

You name it
We want ready made screw driver technology and then make tall claims indegenius built

Not many IIT B Techs in Agni projects all local engineering college guys doing wonderful job under Madam Tessy Thomas team

Average guys pulling more than super duper IITians who are more in CDS to take credit

Arjun · Post by **Arjun** » 10 Nov 2012 22:32

Abhijeet wrote:To add to the comment above: it would be flat out impossible IMO to build a Google type organization consisting of thousands of very high quality people in India, because it would be impossible to find very smart people on that scale, or to make them relocate if they were outside India.

It would be flat out impossible in the US to scale up as well with non-immigrant Americans - which is precisely why the US has the H1B visa system.

The advantage the US has is that folks would be willing to relocate to the US - enticed by its economy & the excitement of being part of Silicon Valley. This same advantage is likely to start accruing to India within the next 30 years.

As for which country can scale up for large-scale high-end work - India is already the #1 by far in the high-end offshored R&D domain, across Software and Engineering. Most analysts (& this includes strategy consulting top dogs like Booz) don't see this market leadership withering even in the long-term.