Sharing IT Best Practices with youSharing IT Best Practices with youThis article describes the arguments when to use waterfall or an incremental and interative approach.
The Agile way of working consists of building increments rather than a complete product or service. Each increment has an added value. The architecture of the product / service has to be designed that it allowed to evolve.
The Agile way of working consists of cyclical building of a product and/or service. These cycles may be fixed like in Agile Scrum of may differ per delivery like in Kanban.
The waterfall approach means that there is one flow from requirement to delivery in which the complete product is delivered. The steps of the DevOps process (see article DevOps process) are the same, however in the waterfall approach they are only executed once.
A waterfall project uses the waterfall approach to realize a product or service. However, a waterfall project may consist of phases in which the product is realized. When using phases, the product breakdown structure in which the product functionality is described will be coarse at the start of the project and will get more detailed per phase.
An Agile project starts with a business case, roadmap and release plan that is realised cyclical by realizing of an increment of a product or service. At each cycle, part of the product backlogs is realized. Priority and sequence has been identified in the roadmap and release planning, but can change per cycle if necessary. Per cycle, a product is put into use. It also checks whether there is still a business case, or that another project provides more added value for the business against less time and money.
One of the most important discussions when starting with Agile project management is whether or not the Agile way of working can be used for all projects. Since Agile states that products and services should be build incremental and iteratively. Each increment should add value to the business. DevOps even does one step further and states that “done” means “running in production”. However, in most organization 20% of the projects are creating monolithic solutions. This means that the added value is only experienced after the completion of the whole project. So, using DevOps for these kinds of projects still can be done but the whole concept of adding value per cycle is not in place. The DevOps team might even feel uncomfortable to use DevOps for these projects. This article gives the arguments to choose for a DevOps approach or a Waterfall approach for a new project.
In a survey conducted at ten organizations [Best 2015], it has been found that all organizations that Agile project management also do still have Waterfall projects. However, the ratio Agile: Waterfall often is 80:20. There are good arguments whether or not to choose for Agile or Waterfall approach. The following criteria are relevant.
Agile project management is useful as:
Agile project management is not useful as:
The core message of DevOps is that ‘done’ means that the user gets a working product at the end of each cycle that adds value to his business process. However, many organizations use a DevOps approach to save the final result until a release is deployed after a number of cycles have been completed. In itself, this is not a wrong approach, but it means a delay in the time-to-market and feedback loop.
The disadvantage of waterfall projects is exact this deviation of the Agile project. The added value is achieved much later. As a result, the Return On Invest (ROI) is also much worse.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.