Agile in software services Industry


Any time you mention Agile you hear it is applicable in Product development. It is true agile is used more in product development. This might be due to the reason it is easy to follow agile in product development. It is also due to product development requires more agility to compete.
Let us compare few aspects of product and an application (services).
Product development
Software Services
Requirements
It is in discovery. You start with an idea and develop it. Never frozen. To survive in market need to be two steps ahead of competition.
Requirements are clearer. Before the service provider comes into picture customer spends lot of time defining the requirement.
Quality
High quality is desired. Buggy product is not liked by any customer. Support cost is part of product price in many cases.
High quality is desired but not achieved. High quality costs more.
Budget
There is comparatively more money to spend.
There is limited money for the development.
ROI
ROI is linked to the sales of the product.
ROI is from the usage of the application. It from the improved efficiency or new sales generated due to the implementation.
Product development starts with an idea. Metamorphosis of idea to working application requires agility. During the development phase you will realize what else will be good with this project. Some times product becomes totally different than the conceived idea. Some features which are not thought in the beginning become the most used features.
All these require iterative development. Product owner needs to see the product when it gets developed.  These mandates development of product through an iterative approach and agile development suites this.
Now let us see the phases in a application development.
Business comes with a requirement for an application. This goes through the budgeting process in the organization. Studies are done on the cost savings or new business by this application. If the study is conclusive and there is a requirement for the application budget is approved for the development.
From this multiple paths are followed based on the size of the application. Let me take one example. Organization hires a business consultant to do further studies and come up with the requirement. Business consultant will interview respective business units and write down the requirement. This process usually takes one or two months. Once this process is complete organization starts the selection of a vendor. This process will take few more months. Once vendor gets the contract vendor starts the development process.
Vendor needs to go through the requirements done by the business consultant. By this time business consultant will be doing another assignment. Vendor needs to clarify the doubts with the business users. By this time business user would have forgotten exact requirement given to the business consultant. This results in a new requirement or more gaps in the requirement. Finally after another month vendor has the requirements in some shape.
After this point development team pitches in. Whoever represented vendor for requirement gathering will explain the requirement to the development team. They will raise some more doubts which will have to get clarified by the business user.
Finally after a year of idea being conceived application is delivered to the business user for testing. By this time business would have changed. This results in some more change requests and some more development.
What is the solution for this issue?
Follow agile SCRUM. As soon as customer decides there is a return on investment hire a vendor who knows how to develop in agile way.
Zero sprint:
Zero in on the technology to be used. Decide the release plan. Let the team build the infrastructure required for the development. This will take one or two weeks.
First sprint:
Decide which features are highest priorities. Let the team work on them and deliver it by the end of the sprint.  Demonstration at the end of sprint will give the business users enough idea on how to use the application and what other features they want.
Second, third …. Sprints:
Continue adding features, make the required changes. After any of these sprints application will have the required features to use it in the organization. Decide at this point to deploy and start using the application.
If you follow this approach cost might be comparatively higher. But you can get the benefits lot earlier which will negate the higher cost.

Comments

Popular posts from this blog

Greedy computing with API

ChatGPT for cavemen

Event driven architecture for micro services