Vendor's dilemma with Agile

-
Companies which use agile development for development are usually product companies. There are few odd companies which use agile for software services also. They are successful but they are not in mainstream software service business.

I want to analyze why agile is not adapted in most of the offshore companies.

Some reasons attributed for this are:

  • Communication is difficult and agile requires daily communication.
  • Agile is not suitable for offshore (outsourced) projects.
  • Agile is for product development.
  • Developing in agile is expensive and not cost effective.
  • Etc….

All these do not hold good. Without communication you cannot achieve end results in any kind of development. It is proper application of agile which will prove otherwise.

My reason for non adaption for agile by outsourcing companies is lack of trust and lack of understanding. To understand this we need to check the conflict of interests for customer and vendor.

Developing in agile will result in these benefits. Please check my earlier blogs for details.
  • Application is developed faster.
  • Main features are ready for production earlier.
  • Customer does not have to spend lot of times visualizing every minute details. Only important feature for the next cycle.
  • No change requests which eat up budgets.

Let us see what the implications on the vendor are:

  • Developing faster means loss of revenue.
  • Typical offshore company cannot charge more for delivering early. There is no incentive.
  • Giving demo every 4-6 weeks takes more discipline and puts more pressure.
  • Agile requires automated tests. What is the benefit if someone else maintains the application in future?
  • Refactoring and simplifying the design will result in smaller changes and less maintenance.

There is lot of things for vendor to loose. This is the main reason vendor (offshore outsource) will not take initiative for moving to agile. Main driver for offshore is cost and agile just cuts down the margin.

But there are good reasons to move to agile and get benefitted by it. Even a offshore company can benefit by working along with the client.

Comments

Post a Comment

Popular posts from this blog

Greedy computing with API

-
Image
 We all know computing resources have a cost. Memory, long term storage, transportation and computing all have their own costs. There are lot of scenarios where your API end point won't be able to respond in time. These are scenarios where you need to use more resources to provide a response. Let us be greedy with our resources and explore different patterns which can solve this. Polling  This is a commonly used pattern where the caller initiates a process. Then keeps on checking if the process is complete. If the process is complete then the caller reads the data needed.  This is a good pattern when both systems are part of the same organization. At least developers of caller and callee should be able to discuss this implementation.  Call back This is an improvement over polling pattern. Here the caller supplies a call back URL to the long running process. Once the process is complete it calls the callback URL and informs the caller that process results are availabl...
Read more

ChatGPT for cavemen

-
Image
I heard a lot about ChatGPT and thought to come out of my cave to find out what the hype is about. Is it going to eat all my lunch or eat me for lunch?  Like any product I gave it all my details and signed up. I asked it about quantum computing an it gave some answer. So far so good. Next day I wanted to check its blogging skills. So I opened chatGPT and I got this . I checked throughout the day and it is still down. So it won’t eat me till it is fed few more servers.  Continuing after it was up.  I asked it to write a blog about itself. Here is what was generated by chatGPT.
Read more

Event driven architecture for micro services

-
This is a work in progress. I am designing an event driven architecture to be used in systems using micro services. Micro service architecture is popular because it solves few problems in development process. While it solves some problems it also brings in new problems to the table. Bad designs impact micro services harder than monoliths. But this is thought is for another time.  How micro services talk to each other. In a monolith you have one gigantic database, or you can easily call another component to process the information. In a microservice you can use a Que (or event bus) to pass the information. This is the problem I want to discuss. Main issue with que is it is not designed for this scenario. There are few products which give a good solution by providing a subscription-based approach. But these are large implementations. Using these is similar to bringing an excavator to plant a sapling in your garden. Yes, many people go with using these large implementations to resolve...
Read more