One of the many questions you will need to answer when implementing a new software – and certainly one of the most important – is which project methodology to use. In recent years, this choice is typically between two options: Waterfall or Agile.
Certainly, the Agile methodology has been floated as something of a panacea for the problems which always seem to plague IT projects. However, be warned…it is far from a magic bullet, and – used unadvisedly – can cause a host of unexpected problems.
This post will provide some guidance as to when it is advisable to use Agile for your project, and when it is not! As usual, we will start by defining the two strategies.
AGILE AND WATERFALL: THE DEFINITIONS
Just as water flows over a series of falls and rapids as it moves downstream, the Waterfall methodology assumes that the various project phases occur in sequence, with one project phase being completed before the next phase begins. (i.e. all requirements are gathered and signed off before any part of the solution is developed; the solution is fully developed before the testing of any part of the solution takes place).
To continue with the ‘water’ analogy, if the Waterfall process is based on everything following a nice, neat, sequential stream, the Agile methodology accepts that solution development will follow multiple
streams at the same time, and that these streams will move at different speeds. (In the Agile world, these independent streams are called ‘sprints’.)
As you can imagine based on the descriptions above, the Waterfall methodology is somewhat easier to manage, but can take a while to get to the ‘delivery’ stage. The Agile strategy, on the other hand, can be very challenging to manage, but it delivers the solution (or portions thereof) relatively quickly.
With that said, let’s take a more detailed look at the Pros and Cons of both methodologies.
PROS AND CONS
Some of the ‘Pros’ of the Waterfall methodology are:
- The more ‘orderly’ flow of the project makes it somewhat easier to manage, document progress and report on status.
- IT and the Business agree on what will be delivered early in the project lifecycle. This makes planning and designing more straightforward.
- Progress is more easily measured, as the full scope of the work is known in advance.
- The solution can be designed based upon a more complete understanding of all deliverables. This provides a better design with less likelihood of the “piecemeal effect” (which sees pieces of code being developed ‘ad hoc’ and which may or may not fit well with the overall solution).
However, there are some fairly common ‘Cons’ to the Waterfall method as well:
- Gathering and documenting requirements in a way that is meaningful to the customer is often the most difficult part of software development. It is sometimes difficult for customers to conceptualize their requirements in the context of updated business processes or a new technical solution.
- It is sometimes a struggle to have IT and business stakeholders dedicate the time necessary to create a thorough requirements document. A lack of detail/understanding at this stage could easily cause
problems during solution development and testing. - Once requirements are confirmed, the customer may not see the solution again until they become involved in testing. This can often lead to the solution being miles away from what the customer wanted, which in turn leads to massive confusion and extensive re-work, with the resulting impact on time and cost.
- The Waterfall approach can be slow to deliver, as waiting for all stakeholders to complete a particular phase before the project can move ahead can bring some inefficiencies.
Some advantages of the Agile approach are obvious:
- Because the customer is intimately involved with each ‘sprint’, they have frequent opportunity to see the solution as it is being developed and tested, and therefore can provide feedback at any point during that cycle.
- The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
- If time-to-market for a specific application is a greater concern than releasing a full feature set at initial launch, Agile can more quickly produce a basic version of working software. This can be built upon in successive iterations.
- Development is often more user-focused, because of the direct involvement of the user community.
Some of the disadvantages of Agile are:
- The very high degree of customer involvement may present problems for some customers who simply may not have the time or interest for this type of participation.
- Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints
(beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation. - The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible.
- The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.
(Reference: “Waterfall vs Agile: Which is the Right Development Technology for Your Project?” Segue Technologies, July 5, 2018)
WHICH PROJECTS LEND THEMSELVES TO AGILE VS WATERFALL
Pros and cons are one thing, but ultimately we need to make a decision as to which methodology to choose. To be sure, there are projects which have characteristics that make them ‘Agile-friendly’ and there are projects which have characteristics which make them ‘Waterfall-friendly’. The link below (from Segue Technologies, published on July 5, 2018) provides a summary view of these characteristics:
ORGANIZATIONAL CONSIDERATIONS
Even though I have used the plural ‘considerations’ in the title for this section, there is one organizational consideration which, in my opinion, outranks all the others (be they organizational or project-centric in nature): does your organization have substantial experience/expertise implementing projects using Agile? If the answer to this is ‘no’ then I would caution against using Agile, especially for larger, strategic projects. The rationale for this recommendation is simple: Agile involves many, many moving parts, and if you don’t have experience in managing them all, you are courting disaster. In this situation, I feel Waterfall wins by default.
You may ask “But if I never undertake any Agile projects, how can I gain the necessary experience?’. And this is a fair point. In response, I would propose two options:
- Hire an individual (or individuals) who does have extensive Agile experience; and/or
- Select a smaller, more tactical project to be your Agile ‘guinea pig’ and use it to begin to grow your expertise.
Again, I hope you found this article useful. Happy to answer any/all questions.
And, FYI, next week’s blog will concentrate on another important ‘methodology’ question: Big Bang or Phased Approach to delivering your project? Hope to see you then!
