16 August 2012
The choice of a relevant and effective development model is one of the key factors in determining the success or failure of a software company. Key factors that influence the decision are the type of product being created, time restraints, and the resources available to support the chosen model.
By far the two most common models in use today are the Waterfall Model and Agile Development. The various benefits and drawbacks of these two models have been discussed in detail elsewhere, so I’ll simply offer a quick summary.
The Waterfall Model involves planning the entire development of a project from the initial idea to its completion in a step-by-step sequential process. Each phase cannot begin before the previous phase is completed. The model is best used in smaller projects where the product is extremely well understood from the outset, with well-laid-out timelines.
Agile Development is based on the idea of completing bits of the work in small chunks called sprints. The product is built bit by bit, feature by feature, and at each stage, analysis takes place to see if the product needs to evolve from its original scope. This process works best on larger projects that are easily divided into discrete features.
However, in an agency environment, where the client and the producer of software are two different entities—not always with the same goals and opinions—which development model is going to work better ? The answer is: neither and both.
Agency projects are usually generated by clients’ ideas . These ideas are often loose and ambiguous, and it’s the agency’s job to translate them into something that will suit the client’s needs. Thus, the best strategy when beginning a project is to treat it like the Waterfall Model. Design the product and timeline in whole and get client sign-off on the plan.
However, in the fast-paced churn of agency development and project-based work, it is a mistake to expect that the original plan and design will not change . Because each project is different, and there is limited time for discovery, you rarely know what you are getting into during the planning phase. A client personnel change during the project, technical limitations discovered during development, design implementations not working out—there are a hundred reasons why changes might need to be made on the fly during the project. The most common breakdown of the Waterfall Model is during the QA phase, where many of these problems come to light.
So how do you get over this hurdle? Our approach is simple—by planning the Waterfall Model through QA as only the first part of development . After the QA phase, abandon the original plan and establish a new timeline to work in a more agile way. Create sprints based on the remaining work and the client feedback, keeping the client in the loop regarding how much time and resources each sprint will consume. This process lets the client see changes rapidly and assures them that they are being listened to and that the agency is devoted to producing the product that will actually fit their needs, not just sticking to a flawed plan.
Which model works better for your project? It all depends on the project’s size and complexity. Smaller, simpler projects usually benefit from the Waterfall Model , while larger, more complex projects are a better fit for the agile model.
The key is to be flexible and find what works for your agency and your clients.