How Should Your Software Be Built?
There are two major methods of developing software: waterfall and agile. If you’re considering a development project, you should consider how your software should be made.
Waterfall development goes through distinct stages, with requirements gathering in the first stage. In the waterfall method, a group of decision makers think, imagine, script and whiteboard how the system might be used. These working sessions create a set of requirements for the application. After the requirements are set, the waterfall method flows down to future stages of development, testing and deployment.
In contrast, agile development breaks a project down into small stages. Each stage tackles a small area of the application, gathering requirements, building, testing and then putting the growing application into the hands of users. This process allows requirements to emerge over time, as users and developers learn together exactly what the application needs to accomplish.
Waterfall development assumes the requirements of a system can be fully predicted and codified before any development begins. Agile development assumes requirements only fully emerge during the process.
Waterfall development aims at a stationary target. Agile development aims at a moving one.
So which method is best?
The Stacey Matrix below is a helpful tool for evaluating a potential development project.
Waterfall development works best for simple systems, when there is a great degree of certainly regarding exactly what the application will do and there is a high level of agreement within the organization regarding those functions. When systems are complicated, complex or chaotic, waterfall development is increasingly likely to fail. When the system has many users, complicated uses, the need to evolve over time, or there is disagreement over requirements, agile development can guide the process toward a successful deployment by breaking down the overall project into simpler sections.
So why does evaluating a project matter?
Waterfall development lends itself to off shoring. Once requirements gathering is complete, the development company can “disappear” to develop the application. There are few reasons I can think of to engage a domestic waterfall development firm that offset the significant increase in cost over off shoring.
But agile development requires an engaged, local team. In complex scenarios off shoring leads to failed projects and sunk costs. We’ve seen complex, off shored projects in need of rescuing time and time again. The fault is not usually on the off shore firm, but on the method used.
So before you engage a development firm, check the Stacey Matrix. Is this a simple project with low complexity and high agreement that could be off shored? Or does the complexity of the project make a local, agile team (like Highland) the right choice?
