Over the last 20 years or so, software development has moved away from what is called the waterfall model where everything is defined at the start of a project and sequential steps brings us towards the finished product. This might sound intuitive and like a good approach but it comes with several problems. First of all it requires you to know, in detail, every part of the application before you even start implementing it. In our experience this is never the case since the creation of software, like most other things, is a creative process where you get new ideas of features or how to solve things as the development progresses. The other major drawback of the waterfall model is that you effectively have no working product until at the very end. This means that if things change (which they tend to do) you have limited possibilities of addressing that change.
An agile, iterative approach has come to take over as a way of dealing with these problems. Instead of deciding everything in detail at the start, a rough outline is drawn up in order to clarify the vision of the project. Then development is an iterative, cyclical approach where each week or two (or day, or month) you decide what is the most important thing (out of everything the outline and the work up to date show) that needs to be addressed at the moment.
With an agile approach you don’t have to know every detail of a project up front. As work continues, both customers and developers, gain a clearer idea of both what needs to be done and how to do it. You also have the freedom to change direction at any moment without throwing away days or even weeks of initial analysis and planning. Perhaps the most interesting part, though, is that at any time during development you have a working product with the most important features included. This means that you could put out a release early just in time for that special event or before the holidays or to give early access to a third party, even if development has been delayed or the scope of the project has changed.
This freedom and flexibility comes with a “cost”. It isn’t possible to know exactly what you get for a certain budget. This might sounds scary but really shouldn’t come as a surprise. As a software house, we can give you a precise cost of a project, done in a certain way; provided we know every detail about the project before development starts – the waterfall model. We have already seen that this isn’t practical for several reasons. Is this a problem in practice? Not really, because there are many ways to deal with it. If you need to keep to a fixed budget, the agile approach lets you decide, day by day, what goes into the product and when the budget is finished you have the best possible product your budget would allow. If, during development, you decide that the current state of the product is sufficient for your purposes, there is no need to spend more than you already have.
We think that an agile approach, apart from being a “sensible” solution to the problems above, is the most fair approach that creates the best possible climate between service provider and customer. Instead of the customer trying to fit extra things in the budget while the provider is trying to do the least work possible, every day becomes about adding real value to the product. That seems like an excellent way to start a good, fruitful, relationship!
Amazing
Good
Bad
Meh
Pff
