There is a constant debate about what is best for managing Agile or Waterfall projects. Flexible methodologies seem to be better because the result is immediately available, and you can stop at any time. The cascade method is more applicable to large projects, such as the construction of a nuclear power plant.
These arguments have always been and always have been incomprehensible to me. After all, first of all, we must meet or exceed the customer’s expectations, so the project management system must be such as to interact with the customer as much as possible, demonstrate results, form expectations, and discard unnecessary things. It doesn’t matter whether you fill in the Backlog or WBS, whether you allocate the Product Owner role or not. It has already reached anecdotal situations when the” fashion” for the word Agile is so secure that employees can only express their attitude about the effectiveness of this method in a whisper in a private conversation, so as not to pass for retrogrades and ineffective employees.
We must admit that many coaches use these disputes only as a speculative opportunity to attract attention to their courses. But some believe that Agile is something new, modern, previously unknown, and Waterfall is something archaic, useless, and labour-intensive.
Yesterday, for example, I came across an interesting article, “4 Reasons Why Waterfall isn’t a Fit for your Team”.
In it, the Waterfall is blown to smithereens, and seven assumptions are used for this purpose. Or at least I counted that many.
Assumption 1: A Waterfall is an approach where one stage sequentially follows another.
Of course, this is not the case. Any project manager knows that the most obvious way to speed up work is to parallelize it. Only in this case, we also know that integration risks are increasing, and we need to provide additional effort on testing the results obtained. We even know that there are projects of this scale that are divided into dozens of parallel threads, the results of which are tested at certain points, called “quality gates.” And it would be impossible to complete these projects without a calendar plan or a technical task. Therefore, we can say that Waterfall not only does not prevent us from performing work in parallel but also suggests that we will need to do something with the integration of the results obtained.
Assumption 2: Waterfall prevents changes.
It does not prevent but allows you to identify the need for changes and evaluate them. You can’t do without an analogy here. Imagine that you are building a house. It has windows of the same size, and the supplier is ready to ship you windows of a different size. It would be better if you did not have a plan where you calculated all the loads, the necessary overlap and the number of bricks? Or is it better to evaluate the changes in advance and choose the best solution: take new windows and redo the project or search for windows from other suppliers? In some cases, refusing to change is not a bad thing. For some reason, we have begun to forget that following the plan is a good thing, and changes do not always add value. Moreover, having a plan allows us to understand that we are dealing with a “change” that deviates from the original task statement.
Assumption 3: Waterfall is not focused on creating a product.
This means that when we see only works in the work plan; we focus on “work,” completely forgetting that we need to get something “product.” So is this a lack of method or omission of the project manager who did not provide for the regular receipt of “products” in the plan and an assessment of their suitability for the customer? You decide what to put in your plans: a description of the work performed or a story of the necessary results. This is entirely independent of the method used. You can also use agile to plan “work execution” rather than” getting results.”
Assumption 4: the Waterfall is a wasteful detailed planning work.
This is a common problem for new tasks: I can imagine what I need to get, but I have absolutely no idea how I should get it. So why should I plan ahead until the very end if I don’t know what will happen in a month? The answer is that you don’t need to plan something you don’t know. I first got acquainted with PMBoK when it was already in the third edition, but I am sure that in the first edition, the “incoming wave” method was already present. The essence of it is that you plan only the period closest to you and evaluate all the others expertly, with the degree of accuracy that is sufficient for you to make a decision about the feasibility of implementing the project. As a result, you have a detailed estimate of the cost of the next work and an expert view of the value of the entire project. We use similar methods, such as planning poker, in agile.
Assumption 5: The client doesn’t know what they want, and Waterfall exacerbates this problem.
First, the client does not always is unknown what he wants. I had projects where the client knew exactly what they wanted. Secondly, if the client still does not know what he wants, he can still think about it in advance, spend time on it. Have you ever found yourself in a situation where the client says “great” after the first, second, third, or fourth sprint, and after the fifth, “this is not what I wanted”? Just as Waterfall does not cancel regular communication with the customer, Waterfall does not prevent the consistent demonstration of results and validation by the customer. Here the problem is not in the method, but in the fact that we need to regularly check with the client that we are doing what he needs.
Assumption 6: Waterfall involves testing at later stages when any changes are costly.
This is not a question of the method, but the project manager. If we see that the schedule involves later testing, these are additional risks. Testing should be carried out immediately after the development, and you should organize the work in this way in any method of organizing project management.
Assumption 7: In Waterfall, the client can be blackmailed with fixed requirements.
Also, a theoretical argument. We all understand that a satisfied customer is the foundation of any business. A happy customer will come to us again, bring their friends. Therefore, no one will usually shake the signed requirements in front of the client if the client is important. On the other hand, it is useful to remind the client that we deviate from the original task statement, so that decisions will be more balanced and conscious. Moreover, you can also do this by referring to a series of completed sprints during the implementation of the agile project.
As you can see, there are no terrible project implementation methods as well as there are no management methods that guarantee better results compared to others. When choosing a project implementation method for yourself, first of all, do not turn off your head, evaluate which way is best suited to a specific situation, and, if necessary, combine them.
No comments yet.