As I mentioned in another article (“How do we deliver a project?“)there are different ways in order to execute a project, being the two more important “Waterfall” and “Agile”. I am not going to describre the difference between them (one vs another style) but rather mention what makes people use an Agile method.
To begin with, Agile methodology is used in more “abstract” deliveries, as sofware programs or products that need of a high level of iteration with users entering new needs or testing along the way.
Product Quality along the way
While it is true that projects should be delivered against a certain quality standards, there are many occasions in which those are jeopardized as it falls behind the expected delivery and go-live time, the costs or the resources.
With Agile you can control in a much better way all those without giving up on the quality. For those not familiar with Agile, in this methodology you run something called “sprints” every certain time (usually between 1 and 4 weeks). During this time not only do you care about introducing some functionalities, you also test and make sure you can progress in an organized way. With other methodologies, where testing is left to the end, you run the risk of discovering something very wrong that can not be changed without altering the overall project, causing chaos as the project may have to be re-delivered from beginning.
Better Project Control
As the say goes “divide and conquer”. That is exactly what you do with your projects when delivered in Agile. You can expect to implement a big project with many features and far too many expectations hoping that it will all go well at the first go. You need to have a control method that will allow you to see how everything is going along the way so surprises are avoided. Putting the features needed in a sort of “product backlog” and introducing them in every sprint in an orderly manner and checking them before the next sprint will save you lot of time and effort as you are progressing versus completing a fully tested and operational product (…or not).
A project is not a project without a surprise, and all projects have surprises. However, it is not the same to have a surprise while you are delivering a sprint (so control is there and you can revert whatever changes or implementations back to the previos version which was just a few days ago) than finding a major failure or feature mistake when it is too late in the process.
There is also something that people forget and is the fact that products evolution and requirements change. With and Agile methodology you can introduce changes in scope or functionalities not thought of previously. This does not mean that anything can happen and evolution your project in any possible way. It means that Agile gives you the agility (thus the name) to be flexible if needed. Should the changes be so major that maybe those will need to be implemented in a complete different project, once the current one is closed.
Advantage in the market
Sometimes the company does not dictate when a product has to be launched. In many occasions when competitors are also challenging customers you are obliged to send something to the market, even if it is not finished. How many times we have bought a product and we receive updates and new versions every so often, some times even inmediately? This is not done to upset customers. It is to ensure that customers buy a certain product before they buy something from the competitors (This is the so called “time to market”).
Trasparency and customer experience improvement
When your customers are part of you project, surely enough they will be more attached to you than to other products from somewhere else. You make them part for the process in which their desires and expectations are taken into account when developing the product. It is also very common to allow users to test, to be part of the “preview program” or “beta testers”. This not only give programers the chance to see where they may be mistaken, but also to set loyalty among those consumers that may consider other options if they are not satisfied with the final product. Engaging them at an early time will help in keeping those customers loyal. This is a common practice in game-developing companies where trying a certain program as beta will probaly make them stick to them (as usually being beta-tester means that the customer has also paid for a pre-order).
New Agile with old practises
While Agile gives you the flexibility to introduce changes to your project, new requirements, change in time or even cost, there are people that think that the methodology is meaningless as they want it done their way…or else. In those cases, why bother with a new methodology? Just stick to what you want with a methodology that will not give you as many “headaches” as Agile may introduce. Think that applying Agile is not about delivering a product, it is also all the resources that have to be available during all the interactions as to make sure that the project flows as it should.