Planning a software project can seem like you're entering a minefield. Getting the right requirements impacts directly on the functionality, practicality and usability of your development, so ensuring your plans have all avenues covered is key.
But once you’ve opted for bespoke software over an off-the-shelf product, what’s the best planning approach to take? Well, you’ve essentially got two choices: you either go for the classic Waterfall approach, or opt for the sprint-based Agile software development methodology.
We’ve explored the differences between these two bespoke software development methods and which you should use for your project – Agile vs Waterfall. Here at Audacia, we appreciate that a strict adherence to one framework only can be constraining, whereas maintaining an awareness of the pros and cons on each side allows us to combine these approaches to achieve the best of both worlds.
What is a Waterfall software development methodology?
A Waterfall methodology is the more traditional, linear approach to software development. Before the project build begins, all delivery stages are scoped and timescales are agreed between the development experts and the client stakeholders. Each set stage of the project allows for limited flexibility, and the project can only be moved forward as and when the previous stage has been completed. As an example, the development stage might only start once the requirements definition stage is complete – and user testing would follow the development phase.
With this approach, there is an understanding of the full scope of work in advance, so theoretically the resource allocation, budget and timescales can be planned accordingly. Also, using a Waterfall approach might limit client interaction during the development process, since the client would generally be more heavily involved at the requirements definition stage - and at the user acceptance stage when the project is near to completion.
The classic way of representing a Waterfall project would be a Gantt chart, where the left-right scale represents time and tasks are listed within grouped sections on the left. This allows us to show the chronology and duration of deliverables and milestones:
Crucially, this allows stakeholders to easily access a high level view of the project stages, so that they have a clear expectation of when certain milestones will be reached and which tasks have dependencies on others.
The downside of this approach will be immediately evident to anyone who has run a project. The reality is that things always change – if you try and plan a whole project upfront, without allowing for changes along the way, mistakes will be made. Even if by some coincidence the requirements are defined perfectly during the scoping stage, based on the information that was available at the time, the cost/benefit ratio for certain features may well have changed by the time they are delivered. Accepting that scope, budget or time must be malleable is the sensible business decision, so an agile approach allows us to meet this challenge.
What is an Agile software development methodology?
An Agile methodology is an iterative, collaborative approach to project planning. The focus in on allowing teams to work together and respond to change dynamically. Features requested by the client are delivered within strictly timeboxed iterations – typically two weeks. These iterations are often referred to as ‘sprints’, and each sprint has a defined list of deliverables which are committed to before that sprint starts.
When the work is completed at the end of each sprint, the aim is that it is delivered to the client as a complete feature that provides real business value. The client will have opportunity to review the work delivered to evaluate suitability.
This constant feedback loop gives developers and clients the chance to add, amend or remove features regularly throughout the project lifecycle, in line with current business needs. If all the necessary work hasn’t been completed in a specific sprint or phase, any deliverables can be reprioritised and reorganised to recreate a defined plan. Typically this would mean that the process loop outlined below is completed every iteration (e.g. every two weeks) and then repeated until the project is delivered.
Having the ability to rapidly respond to changing requirements is imperative to a successful bespoke software development project. By choosing an Agile development approach, you can see how your development is progressing after each sprint, to get a better idea of the features that deliver most value and calculate how to evolve the software further.
This ability to make changes and re-prioritise workloads within an Agile software development approach brings much more collaboration and challenging of ideas between the two sets of experts involved, which again only bolsters the quality of the end product.
Are Waterfall and Agile approaches mutually exclusive?
The quick answer: ‘no’.
Historically people might have associated PRINCE2 with the Waterfall model. However, it is perfectly possible to manage a PRINCE2 project in a manner more akin to Agile/Scrum. PRINCE2 projects may be split into stages – and if these are short enough, we can draw a parallel here with Agile ‘iterations’ / Scrum ‘sprints’. The ‘Managing a Stage Boundary’ process in PRINCE2 requires that a review is carried out at the end of each stage to ensure work is being delivered within agreed tolerances and that if mistakes are being made, these can be rectified - this is not worlds apart from the ‘Sprint Retrospective’ process. PRINCE2 projects might be expected to be more documentation heavy, but of course the 7th principle in PRINCE2 is to “tailor to suit the project environment” - so a smaller project might agree to maintain a lighter documentation set.
In the real world, we would often see that the structured processes defined by PRINCE2 aim to address some of the shortcomings we might see on an Agile project. As an example, a common mistake is that someone might start an Agile project without seeking a full upfront understanding of the end goal. While this allows work to be addressed in small, sensibly-sized chunks, it might obfuscate an understanding of the real business aims and we might see that re-work is required further down the line if this results in re-work being required at a later stage.
So Agile might specify that we value working software over comprehensive documentation, but here at Audacia we appreciate that good documentation might be vital in enabling us to communicate clearly with clients – thus allowing us to define what “working software” really means to our customers.
In practice it might be sensible to use a more rigid and phased approach for an Agile project that has a hard dependency on external resource for a certain functionality set. On the other hand, if a client is working to a fixed budget we would help them to define the minimum viable project and commit to delivery by a milestone - but still utilise the regular feedback loop to ensure that the project stays on track and maintains an accurate view of the critical path.
Should you choose an agile or waterfall approach?
In the debate between Agile vs Waterfall, it’s all down to what suits your business best. For an iterative approach which calls on collaboration and flexibility to meet the requirement needs of a bespoke software development, an Agile approach is your best bet. If you’re happy to lay out and agree your requirements before commencing development, opting for a Waterfall approach may be your preferred option.
To find out more about how we work on bespoke software development projects, visit our approach page.
