What to expect from a dev team?
June 3rd, 2009
There are many dimensions to software development: scope, duration, cost and quality. Software development is an art, not a standard process. It is not mass production where you can quantify and predict everything. Attempting to get fixed values on all these dimensions is a big mistake. Here is why.
Customers often come to me with a fixed scope, duration and cost in their mind. Think of it as asking a research team to build a 400 HP electric engine that can run for 500 KM in no more than 90 days without exceeding the budget. It can look pretty on paper, but at some point, some of these variables will actually need to vary. This is what will happen to quality when everything else is fixed. Sacrificing quality is the classical recipe for writing terrible code, which in turn results in extended durations, cost increases and reduced functionality due to this technical debt.
Customers do not like this idea, but there is a solution. In agile development, we can fix the duration, cost and quality while allowing the scope to remain variable. The customer may not get everything they ever wanted in any one Sprint, but they get a high-quality product increment that contains the highest priority features completed, while minimizing technical debt. Let me give you a simplified example.
A hypothetical customer wants an online store. He wants a checkout process with a payment system. He also wants users to rate and comment on products. Users should be able to sell products to each other and have a private messaging system to facilitate communication. The PM system will allow managing contacts and import them from third-parties. The customer has a fixed budget and needs to get it done by a certain date. The deadline doesn't have any margin for error. This project will most certainly fail. But, if you allow the scope to vary, developers might still deliver a quality project within the allocated time and budget. It might exclude contact management and importing, if it had a "nice-to-have" priority.
Notice how we can play with the scope and still deliver a great product that will start generating money for the customer. If we had constrained the scope, another variable would have suffered, leading to project failure.
The next time you talk to a development team, keep this in mind. Having the idea of the century is not synonymous with a successful project. You must admit that everything cannot be written on paper before you start the software development. Once started, you have to learn to make sacrifices, and do them in the right place.
Previous: php|tek 09 Next: Flex: non-UIComponents in the Display List