SCRUM | Waterfall – Project Organization Classic and Agile Methods

Project organization classic and agile methods — what is behind it? The content of this article deals with the main aspects of projects and in this sense with the models “Waterfall” and “SCRUM” as project organizing methods. General procedures and characteristics are presented and placed in the project-related context.

Not only we at Inpsyde are experiencing a change in our project organization. Whereas in the past the “waterfall method” was the core model of all project-technical organizational structures, more and more agile models have come to the fore for a few years now. Starting with “KANBAN” and today’s “SCRUM”, there are two standard models of agile project organization.

For the operational project business of internal and external projects, a choice is often difficult, as a certain mindset prevails in an organization and it just has to change.

The process model “Waterfall” is a very project manager-led instrument. Compared to agile approaches, it is very “rigid” and in the sense of “readjustment” quite critical. Agile methods, on the other hand, demand from a project team a great deal of self-organization and maturity of all persons involved far from the respective project role.

Dimensional properties of projects

Before going into project organization as such, it is important to highlight projects as such. What are projects? What do we (Inpsyde and the general public) understand by that?

Projects are characterized by the following characteristics:

1. uniqueness
2. limited resources
3. fixed time frame
4. project-specific organization and coordination
5. new and unique
6. A variable share in terms of individual complexity

Example

• The software should be adapted for the customer to the special requirements A
• the customer provides the sum Z as material resources for this scope
• The project completion should take place on the date D
• the organization O of the project is provided and coordinated from the contractor
• the project P is unique and is implemented in this form F only singular
• these requirements, whether with regard to the entire project or only for partial aspects, are new and have a certain degree of complexity KG

The influencing factors are influenced by the respective project participants and the environment:

• contractor
• external stakeholders (e.g., customers, government institutions, “customers of the customer“ or competitors, market environment or trends)

In a project structure, two forms of project organization are familiar in order to ensure the essential action sequences of a project organization and thus to be able to implement projects as successful as possible. These are basically “waterfall” and the agile “SCRUM”. Both are phase models whose characteristics are very different and have corresponding purposes.

Introduction to the method “waterfall” of the project organization

Typical phases of “waterfall”:

• Systems Engeneering
• Analysis
• Design
• Coding
• Testing
• Maintenance

In the “waterfall model”, these project phases are gradually and strictly traversed. The purpose of this approach is to capture and analyze all the requirements of a project in its entirety in the first phases. From this, the actions (design/coding) are derived and the project is finally made productive by (customer) tests and maintenance. In the “waterfall model” everything is strictly hierarchical “processed”. Clearly defined project phases, taking into account all requirements regarding the project to be worked on / implemented, form the basic tenor of the model. Each phase has a strict start and finish time and builds on each other.

Introduction to “SCRUM” as a method of project organization

By contrast, “SCRUM” follows a “small-scale” approach to software development. This is an agile approach that represents the “agility” of a project implementation structure as the core of all activities. It is based on the constant flow of information and creates in theory “ordered chaos”.

The entire project is broken down into individual fragments in order to develop them within a short time (sprints 1-4 weeks usually). As a result, all project tasks and requirements are clearly outlined. After that, the team already starts with operational development. This also means that the team in the project organization in “SCRUM” can react flexibly to ambiguities or even new challenges before costly reworking of an overall system becomes necessary.

“Waterfall” vs. “SCRUM” Phases

In the “waterfall model”, the six phases are processed hierarchically one after the other. Before a phase can begin, the previous one must already be completed. At the same time, this enables and requires a complete set of requirements in the sense of the overall project. In addition, the completion of a phase means at the same time a form of “immutability” with respect to the phase.

An example is the design phase:

Once a system is designed and approved by all internal and external stakeholders, no changes are scheduled. As a result, the path of the first three phases, especially in complex projects, can “outrun” and these phases can be estimated in the temporal distribution of ~ 50% of the overall project.

Practice shows, however, that change requests must also be incorporated in the further course of the project. This happens, e.g. through new versioning of partial implementations or (new) customer-specific wishes. This circumstance means in a “waterfall model” that replanning is required. These, in turn, affect the system design and thus the project time, in some cases sensitive, since all phases have to be adapted and run through again.

In order to be able to shorten changes or even planning times, or to make better use of them, an agile process organization is an option. The most common here is “SCRUM”. In “SCRUM”, the project phases run partly parallel to each other. Plans are, as described, organized in the “SCRUM” Sprint style, which, depending on the complexity of the project and its design, can last between 1 and 4 weeks.

The basic attitude of the “SCRUM” or route guidance should be limited to one sentence:

“SCRUM is the attitude to deliver the best possible output on the set terms.“

Regarding the set conditions, the total project length is to be understood in relation to the results to be achieved and the number of sprints. Each sprint contains fragments of the overall project and should be chosen so that they can be taken productive within a sprint. Since planning sessions and results are collected at the beginning/end of a sprint, changing project requirements can also be included in active development.

“Waterfall” vs. “SCRUM” pros and cons

The main advantage of “waterfall” over “SCRUM” lies in the planning security and, as a demarcation between each other, also means the advantage of “SCRUM” over the “waterfall”. While the very hierarchical “waterfall” is very focused on the structural planning work, the “SCRUM” works rather “bit by bit”, which is advantageous due to the freer planning form with constantly changing scopes.

Furthermore, the different seeming hierarchical approach is a key point of the corresponding project organization. While in a “waterfall” the requirements and therefore the respective implementations, the relevant implementations reach the development team from top-level to down-level, the approach in the “SCRUM” is a free development and influencing of all involved project members.

“SCRUM” can be introduced quite quickly, but requires a high self-motivation and the co-design needs of all project participants. A core thesis of the “SCRUM” is that the respective project team is managed as far as possible and requirements are taken up by developers and implemented in system design. The additional component of the SCRUM master is that it enables the development team to work as barrier-free as possible in terms of technical or even human obstacles. In short, a SCRUM master should make itself “superfluous” in the medium term. He is the procedural head of the team.

The product owner accepts the requirements, processes them and designs/controls them accordingly with the entire team. In the “waterfall” this role usually falls to the project manager. This not only takes on requirements, but at the same time also specifies a concrete development goal, so that a corresponding development team only has to ensure the “pinpointed” implementation of the requirements.

The differing focus regarding the system design vs. steady development may favor one of the two systems depending on the project.

Summary

While “Wasserfall” is the more seeded project model, more and more project managers are relying on “SCRUM”. The customer-related need for individualization and transformation means that planning certainties are becoming more and more obsolete. In order to take this into account, “SCRUM” as an agile project organization approach is the appropriate means, which, however, can reach its limits.

If projects from beginning to end have a fixed goal, a corresponding design in terms of the requirements and “uncertainties”, a project organization by means of “waterfall” is to be preferred. Especially in very complex systems, e.g. Modular mutually conditional an implementation by means of “SCRUM” is often less appropriate, because the joining of sprint fragments may well have its pitfalls – in the sense of mutual interactions. This is especially true for very large and/or security-critical projects.

A stigmatization of “waterfall” or “SCRUM” should be considered critical as both have their right to exist. Depending on the project, the “fitting” model should be selected in the sense of a goal-oriented project organization. There are few basic rules in the sense of “what” is used “when”. From Inpsyde’s practice, however, it is becoming increasingly clear that the trend or transformation process is increasingly moving in the direction of agile methods, but depending on the project, “waterfall” also finds application.

This is the true core of successful projects that apply methodological knowledge to an existing problem. It plays an important role today to select the appropriate project organization method for a corresponding project or problem.

“Plans are nothing, planning is everything.”

Dwight D. Eisenhower