Today, agile software development is the standard project management model. In many ways, it’s an excellent model. It allows for rapid changes to meet business needs, helps ensure quality throughout the process, and ensures that stakeholders have maximum visibility. But there’s one big problem…
How Do You Price Agile Projects?
Since Agile projects requirements are continually refined during the project, how do we know the amount of work to be done? How can we define a timeframe for development if we don’t have a clear picture of requirements? How can I tell you the cost when I don’t even know exactly what you want to do? Certainly I can provide an estimate based on the high-level definition of the project. But agile makes scope creep easy. New requirements can be added or old requirements removed. This means my best estimate may be wildly inaccurate.
How Can Developers Learn to Estimate Projects?
Making things more difficult, developers who have only ever worked in an agile environment will have difficulty estimating project workload. Why? Because they have never had to. Agile is so focused on the now that no attention is ever paid to the larger work of the project.
Future of Agile
The more agile work I do, the more I have mixed feelings about the process. While it allows greater management input throughout development, it suffers from a variety of problems. Sometimes, I even refer to it as (Fr)agile Development. This is just another issue to add to the list. My hope is that the software industry finds a better way to manage development that solves the problems with Agile while still providing all the positive aspects.