In my current role as a Business Analyst in IT transformation, I work within an Agile environment. Agile is simply a different approach to getting the same work delivered in IT development. Later this week I will delve into Agile mechanisms and why it is becoming the new normal in IT development.
Today, I want to touch up the traditional, and still popular, methodology used by the IT industry: Waterfall methodology. The approach to Waterfall is clearly delineated development stages. The organization creates “tollgates”, otherwise know as checkpoints, to confirm that all the work committed in that stage has been completed before moving on to the next stage of development.
Here are the five stages of waterfall development:
Requirements Gathering
In the first stage, the business undertakes gathering all requirements that need to be translated into IT development work. This includes speaking with subject matter experts (SMEs) within the organization to better understand what their needs are for the development project. These usually include team and departmental managers, specialist units (such as Risk & Compliance) and senior management. Requirements need to be documented and signed off by all the identified stakeholders. From there – the dye is cast! Once documentation is complete, no changes to requirements should take place and IT should be in a position to begin the design.
Design
IT then undertakes translating all business requirements into system design. Depending on the size of the project, this can be a large task that takes a great deal of time. The idea in the design phase is to map out the development work that IT will be doing to ensure that it will be completed to the satisfaction of business. An analogy for the Design phase of Waterfall is the blueprint drafted before building a house. It is important to have the construction plan documented and reviewed by the client to ensure that the home to be constructed aligns with their vision. This is no different in IT development. A crucial part of this stage is for business to review and sign off on the design as the tollgate to move to the implementation phase.
Implementation
This is the core part of Waterfall Methodology. During Implementation, software programming is conducted based on the design agreed upon between business and IT. This phase is typically the longest as development is usually complex and time consuming. Testing the code is often lumped in this stage to ensure that what has been programmed works and to ensure any existing functionality was not impacted by the new development.
Verification
This stage is often dismissed in the “real world” – it is where the new software, once launched, is confirmed to meet customer expectations. I think this is critical regardless of whether your customer is internal or external. Customer feedback is pure gold for companies. It’s up to businesses to satisfy feedback from customers. Listening to your customer = improved customer satisfaction = greater revenues. It isn’t rocket science!
Maintenance
Once the software has been verified, IT is responsible for its upkeep. This includes fixing bugs and ensuring uptime/accessibility for users.
Reasons to use Waterfall:
There are still some compelling reasons to use the Waterfall approach despite the rise in Agile’s popularity.
1. Its structured approach to development allows for clearly delineated stages and tollgates that ensure requirements are satisfied before the project proceeds to the next stage. This is especially important for projects that require sign-off from functions such as risk, legal and compliance.
2. Project scope and budget are much easier to project as requirements are agreed to upfront and there is little wiggle room for any changes to the project once it has cleared the requirements tollgate.
3. Testing is a more straightforward process as clear test cases can be developed in advance based on the agreed to design.
Reasons to pass on Waterfall
There are also some compelling reasons why many organizations are choosing to drop the Waterfall approach in favour of Agile. The top 3 reasons are:
1. Customers are rarely able to map out all their business requirements abstractly without some foundation of functionality as a reference. For large projects, this difficulty is compounded further.
2. The reality is that requirements are not static. They change and can change often as business needs are constantly evolving. The structured approach that separates requirements, design and development does not provide the flexibility required to cater to this reality. This can be increasingly problematic and risky for the organization as requirement changes surface in the later stages of a project.
3. To ensure all requirements are captured, design is accurate and development is complete and tested in different phases, the project speed can be as slow as molasses in some instances. This is in stark contrast to Agile which calls for the requirements, design, development, testing and review of a singular function to be completed in a short period of time (“sprint”).
I’m looking forward to writing about Agile and why I think it is, in many cases, a superior development methodology. Waterfall definitely has its place in the development world and there is also good reason why its reign is coming to an end in favour of a more adaptive methodology.
What do you prefer for development: Agile or Waterfall?