Agencies mostly work with external companies to write for these web and software applications. These external companies are usually represented by their specialist departments, which have budgets. Precise project cost estimates are often necessary here since the decision-maker can argue with the specialist department and his management with exact figures. However, fixed prices can only be achieved using the waterfall method. At the same time, however, corporate customers feel they need to plan projects quickly. “That’s the task of the IT company” or waiting a long time for results, which in turn requires the agile method.
Therefore, a mixed method makes the most sense for an agency. A fixed price is given in which the entire project is assessed. At the same time, a good salesperson is needed who can show that change requests will create additional work. Internally, in the agency, Agile is then used, and towards the customer, the project looks a bit like a waterfall since there are quick updates to the latest features. Still, the customer is not constantly dealing with user acceptance testing (end customer testing and acceptance of the functionalities) and similar agile practices.
Software companies create IT solutions, which in most cases, are provided to their customers in a kind of license model. Again, the Waterfall is the more appropriate method. Often there could be better time pressure, also because the quality of the functionalities, the system’s stability, the architecture’s maturity, and the absence of errors are in the foreground, and it is less about satisfying management structures.
Company departments also work better with Waterfall (e.g., internal projects implemented by their developers/employees). Here, too, the properties mentioned in the previous point, such as the quality of the functionalities, etc., are much more important than meeting a deadline or a budget. In most cases, full-time employees will work on the project. These “cost” items/salaries do not necessarily need to be described to management. In the case of critical systems, a system failure is, in many cases, much worse than excessive project time.
External Allocation Of Projects Via The Specialist Department
This point goes back to the specialist departments which assign projects. Here it is usually easier to assign via Waterfall because it is understandable for a layman who works in the specialist department. Especially from the point of view of the department, in companies, Agile makes little sense. The commissioned IT company can then use this method internally to implement the project. See also the point above, “Agencies.”
External Assignment Of Projects Via The IT Department
In many cases, the IT department is competent in carrying out customer-side tasks in an agile project. Agile is the right choice here because project expenses are easier to recognize and assess for an IT expert from the IT department. This way, the costs can be kept within reasonable limits, even without a waterfall.
Core Systems In Companies
Important systems, which make up the heart of a company, should always be created using the waterfall approach. Or from a mix of Waterfall and agile. It is better to develop slowly, as Agile envisages, also because such core systems are crucial to the success and failure of such companies.
Innovative Projects And Young Teams
Agile can be the better method for innovative projects with young teams. Startups, in particular, can benefit from such processes. Most of the time, however, it is simply a matter of the method being very modern and everyone being able to learn it simultaneously. In young teams, there is usually no tendency towards waterfalls because most are not familiar with them from practice.
Software projects that should be successful in the long term should be implemented with Waterfall. Agile elements and other methods (e.g., Kanban, etc.) should be incorporated. A complete Agile development can only make sense if the systems are not too critical. This is often the case with software for specialist departments in companies. For example, it can be tolerated if the HR software fails for a day, runs a little slower, or is not visually appealing.