Know agile. Not habit. (जानामि Agile न च मे प्रवृत्तिः)

You can build a prototype using agile. But agile and prototyping are different. Many people are confused about this. They talk agile and prototyping in the same breath. Both look similar to people without a background in agile. To give clarity let us check what are the differences. Prototyping Agile Goal is to develop an incomplete version of the software. Goal is to develop production ready software at each iteration. Prototyping is the first step before traditional methods take over. Agile follows same process in each iteration. Prototype may not follow the design or architecture required by the end product. Even though there is refactoring all development follows the required architecture and design. Agile methods can be used for developing prototype. Agile follows some of prototyping techniques. Also there is a agile methodology called DSDM which extends the prototyping. For more details on pr

This is the question everyone asks when they learn about agile. There are many ways it can be done. One is big bang approach. Another is slow and steady approach. I prefer the second approach. I will start with this first. Slow and Steady approach Start slowly. You may not need to announce that you will be going agile. You can do it after you have finished one or two sprints. By this time your team will be comfortable with agile. 1. Start with short sprint. Plan for a release (demo) to the customer after a month or 6  weeks which ever is more convenient. Try to get the actual customer for the demo. Convince the person responsible from the customer organization to bring in the end user. This is critical for success of SCRUM. 2. Start with daily SCRUM meeting. You can call it daily strategy meeting, or daily status meeting. SCRUM Just make sure you discuss three things. What was accomplished yesterday. What will be done by the team member that day. What is preventing the team member from

What is the incentive for the vendor to deliver good quality product in lesser time? Most of the time agile projects have time and material contracts. This does not give good incentive to the vendor to perform well. If project gets closed early vendor looses billing. There are benefits of earned goodwill. But this does not last for long time. Customer organization can have changes and all the good will is lost. There should be additional incentives for delivering early and better product. How to quantify these benefits? This is a tough job. One way out is taking average time taken by industry for a similar complexity project. Based on this number incentive can be calculated based on the ROI expected. This will be a win win situation for customer and vendor?

Traditional project's cost of change. What is the cost of change? Above diagram will tell you it increases as project progresses.This diagram is from PMBOK which tells cost will grow exponentially and stakeholder influence will reduce as time progresses. Probably this is not a good thing as stakeholder should have influence throughout the project. In any dynamic business changes are inevitable. Business is dynamic and will require change in the project when the project is progressing. This model puts a high price for the change which cannot be avoided. Now let us see why the cost increases in the traditional projects. Traditional projects are executed by a plan. Plan is used to reduce the cost of the project. There are no reusable (automated) tests. Team need to work as a plan. If plan is not followed there will be wastage of effort. This is blasphemy for a traditional project. Since there is a separate testing phase whatever is developed is not tested or not ready for delivery. Th