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

Agile manifesto tells Individuals and interactions over processes and tools . People often mistake this as no process in agile projects. Some agile practitioners (!) also believe this. They also miss first part of the manifesto Individuals and interactions. Wikipedia defines process as "Act of taking something through an established and usually routine set of procedures or steps". There is value in process and Agile projects also need process. What agile tells is process should not undermine Individuals and interactions. It is people who create software. They need interaction to understand what is required to be developed. Any team needs some time for forming. Till team is normalized it is better to take help of a process. Take precaution not to force a process on to the team. Team should form their own process. Let the team decide a time for the stand up meeting. Let the team decide the iteration duration along with the customer. Team should decide  Once this process is defi

All hotels have a reception area. Most companies have a reception area. But most homes don't have one. Why? Because we don't need a reception at home. Then why do we build features which are not necessary in an application?  Below is the standish survey for state software projects. Even though this survey was done in 2002 this is still a good representation of feature usage. Most of the time this happens when a fixed price contract is given to a vendor. I have first hand experience in developing some features which I was sure will not be used anytime in the life span of the application. To give an example: Most applications have a master data maintenance section. This is to be used by system's owner or administrator. People spend enormous amount of time developing this. Out these master data administrator might use them once or twice to make some tweaks. Otherwise this data is pretty static. Why spend time on a feature which is not going to be used. Use agile model and deve