In a previous blog post, we wrote about the benefits of the SCRUM methodology, but we did not point out that it is not always suitable for all participants in the project to be satisfied.
Basically, SCRUM requires strong involvement from most of the stakeholders in the project in order for the product to eventually be produced in the right form. Importantly, the first appearance and early adopters of SCRUM were teams working on the development of their own product, the idea holder of which was always able to form an integral part of the team. However, in software development as an industry, there are not only teams working on their own product, but in many cases, a project is made for a customer.
Basically, an external development team alone does not mean that the SCRUM methodology cannot be successful, however, there are requirements for the team to be effective that may not be met in all cases.
The most important element, which often does not work perfectly for custom projects, is that the client or his representative be an integral part of the SCRUM team throughout the project, or have the capacity to work with the dedicated team member (PO) often.
But why is it wrong if this is missed? In short, because hiding behind the agile approach, because we will “redesign later if it is not good”, due to improperly thought-out planning, the development time may increase unnecessarily, and thus the development framework can easily be exceeded. Unfortunately, if we take an agile approach to a project, the “I’ll see when it’s done in the end” attitude doesn’t work on the part of the client either.
Typically, customers from classic industries with an old organizational history and management views that have not changed over time are those who are not always suitable for a SCRUM-type collaboration to date. In these cases, it is worth starting with a thorough planning phase, after which the finalized and approved plans can only be modified once the development is complete. Of course, this is not the most ideal operation for the development team, however, there are times when this phase is inevitable.
With a thorough design phase and appropriate technical and functional plans, the frequent stack, which has undergone many developments in the past, can be avoided today and, due to inadequate specifications, the software is created at the end of the process that is unsuitable to meet customer needs. The importance of this needs to be understood with the client and without it, one should not embark on a project built on a waterfall model because this way we can further reinforce the negative stereotypes about the methodology.
Does it depend on the customer?
It would be easy to say, “don’t undertake projects where the client isn’t fit to apply agile methodologies,” but life isn’t black and white. Providing the client with the opportunity to participate in agile training at the beginning of the project can be a good starting point, but this is not a guaranteed solution in all cases either. It is based on these when it is worthwhile to work with the client within the framework of a classic, although administratively more time-consuming waterfall model, which will have tangible results for the client later, the project takes place in a more concrete and manageable way.
How to implement the waterfall model?
What needs to be highlighted in connection with the waterfall model is that since the model assumes fairly thorough documentation and its acceptance and adherence, the development is typically difficult to adapt to if customer demand changes on the fly. This can be beneficial from a development side, as the waterfall also provides a framework for the customer side that it must adhere to. Of course, it would be too idealistic an attitude to say that everyone always follows the rules laid down, but with a heavily controlled client, this is entirely possible.
In short, a waterfall model is good if we are perfectly aware of both the starting point and the destination, and can plan the path to reach the goal together, without any doubt, but the biggest risk is to deviate from the planned path.
