10.03.2021 17:12
maximgorbatyuk 0 471 Источник

The subject of this article is what I mean. Now we work using Agile: Scrum, or Kanban, or any other extended project management way. Agile appeared in 2001 as a result of a long discussion between really smart guys. They just formed best practices of management into the shape of short documents - the Agile Manifesto. But what did they want to replace by the Agile way? Most of you may say that they wanted the Waterfall to go to the past. But what would you think if I tell you that the “classical” Waterfall had been a really rare thing even for those days?

The classic Waterfall

What do you imagine when you hear “the Waterfall”? There are many articles about it, and almost all of them contain the next scheme (or a similar one).

The classic view of the Waterfall
The classic view of the Waterfall

Steps of the Software Development Life Cycle (SDLC) go only after each other, and no arrows are directed back. First, we collect requirements, then create a design of the future system, then we develop, test. The maintenance step is the last one and means the end of the development. Looks quite simple, doesn’t it?

If you are a software engineer, or BA, or QA, or PM, you know that it is very hard to implement the project without a single bug. It seems to me that it is impossible. If there is anything that can go wrong, it will go wrong, Murphy’s law says. Don’t you think that people in the past had another opinion?

Bugs or any other error of implementation, or any change in stakeholder priorities or needs? We have to disrupt the current process and go back to re-design the system. We prepare a new blueprint and start again. What will you say if the customer wants a new version of the software you have developed? Starting again from the first step - requirements collecting and then go further step-by-step.

Hmmm, returning back and redesigning due to errors or releasing a new version of the software… Stakeholder priorities… The described way is similar to the modern Agile!

History of the waterfall

Let’s go to the roots. When did the first mention of waterfall appear? In 1956, Herbert D. Bennington wrote:

…flows from the top to the bottom, like a cascading waterfall (c) H.D. Bennington, “Production of Large Computer Program”.

Also, he introduced the following schemes:

As you can see, solid arrows are “design” but the dashed ones are “Testing”. The scheme shows that the testing and the design go at the same time as parallel. Therefore, it means that developers check that the implementation is correct.

Another SDLC scheme was introduced in 1968 by IBM:

Some steps of the SDLC have intersections between each other and big stages (on the top of the image) include several steps. It says that the Implementation stage includes coding, debugging, and a part of the packaging steps. As we can see, there are no separate development steps in this concept.

Royce’s five steps

Winston Royce published the article “Managing the development of large software systems” in 1970. The article contains a description of different waterfall approaches. For example, the Waterfall model:

Another way of the Waterfall but with some additional interactions:

Royce’s words about the Waterfall are: “I believe in this concept, but the implementation described above s risky and invites failure”. The concept of cascading development was criticized in 1970, wasn’t it? It seems like that.

Instead of the Waterfall, Winston Royce proposed another way of system development. He tells about them as five steps that “necessary to transform a risky elopement process into one that will provide the desired product”.

Step 1. Program design comes first

What does it mean? Program designers work on the design of the system, not developers. Designers allocate e data processing models: database scheme, resources, some kind of non-functional requirements, interface, etc. Then an overview document must be prepared.

The document should be understandable, informative, and current. Each team member must have an understanding of the system, and at least one person must have a deep understanding.

Step 2. Document the design

“How much documentation”, - some of the developers may ask. Royce gives a simple answer: “Quite a lot”. Moreover, he says:

If the documentation is in serious default, my first recommendation is simple. Replace the project management. Stop all activities not related to documentation. Bring the documentation up to acceptable standards.

Why documentation is important? Royce gives some points:

  • Documentation is a way of effective communication.

  • During the early phase, the documentation is the specification and is the design.

  • During the testing phase, the documentation can be considered as acceptance criteria.

  • The documentation help newcomers to understand the system better

Step 3. Do it twice

If your system is original, you want to verify your ideas or concept. Royce recommends creating some kind of MVP of your product to check the ideas. Then, the second version of your product will be finally delivered. The first version may not be provided to final customers/users, but stakeholders want to see a prototype of the product. It may lead to requirement changes, and it is an effective way of the development process. The final version of the product will be closer to market needs.

Step 4. Plan, control, and monitor testing

Testing is one of the most important phases of the SDLC. You check your ideas and concepts, verify implemented system comparing it with system design. Royce recommends inviting the other persons to verify your system. He says that it would be more effective to give a big part of the testing to people who did not contribute to the system during the previous phases. The documentation will help them to test the system better.

Step 5. Involve the customer

The customer of your project and stakeholders should be involved in all phases of the development. They will help to design and implement a system that will meet their needs closer. Moreover, the stakeholder may change their opinion about the system and give you new requirements. You as Project Manager should meet the changes with pleasure because after all your customer will be happy. This is your main goal, isn’t it?

The all steps above describe an effective way of development. They tell us about iteration, MVP, and involving the customer. Very similar to Agile, don’t you think?

Waterfall has never existed?

There are many articles about project management for program systems that appeared before the 2000s. Most of them mention the Waterfall but often tell about iterative development. Project managers always wanted to develop successful products and often reviewed implementation for the following customer needs. If you do not verify results before the final delivery, you may get a product that will never meet the expectations.

Agile is just a set of effective principles and best practices of programming. It didn’t bring something new to IT project management. Therefore, the Waterfall is not evil. Managers know about human factors and take into account possible errors of the implementation. Thus, the Waterfall was never a reason for failures, because some people applied the concept of the Waterfall incorrectly.

Pay attention to the risks of your projects and apply best practices, listen to your teammates and customers, and your project will meet success.

Resources