More and more often in the world of work we hear about Agile. But what is this Agile really? And how does it differ from traditional Project Management?

With this article I will try to answer these questions and make it clear what is meant by these terms. Below is a short video to introduce you to the topic:

Waterfall methodology

The waterfall approach to software development is highly sequential and can be divided into distinct phases. There are a number of steps that must be completed one after the other. For example phase two cannot begin until phase one is completed.

The stages in the traditional methodology are:

1. Conception: the idea stage, when developers decide what they want to design and why. This phase depends on the type of project and company. If we work in a consulting company then this phase will be done directly by the client, while if we work in a start-up, for instance, this phase will be carried out by the members of the work team.
2. Requirements Collection and Functional Analysis: This phase involves gathering and documenting what the software development project will require, including system and software requirements for the product or project.
3. Design (technical analysis): In this phase, developers determine how they want their piece of software to work and determine which pieces are needed.
4. Coding: this phase involves writing the code for each part of the software, as well as integration based on the architecture chosen in the design phase.
5. Test: system-wide software will be tested; it may include user testing, and in the event of a bug it is expected to go back to fix any specific problems.
6. Release: In many cases, this means delivering the “finished” product to stakeholders or bringing the developments into “Production”.

Advantages of the Waterfall methodology

• Clear and defined plan: There is a clear understanding of the timing and results of the project before it begins. The entire scope of the project is agreed in advance by the development team and their stakeholders.
• Documentation: Each step of the process is documented in detail to eliminate any misunderstandings or shortcuts.
• Shared Load: Doesn’t always require all the time and attention of a development team. Depending on the stage, individual team members can focus on other aspects of their work.
• Initial Customer Contact: Once the initial design and project plan are in place, there is no need for ongoing customer presence until the review stage.

Potential drawbacks

No approach to software development will always work, for every team. There are some drawbacks to the waterfall approach.

• Low Customer Engagement: An approach where the customer is only initially involved is not suitable for every type of project. Some customers will want to be more engaged as this progresses. If there is no plan for such involvement, the waterfall approach could lead to frustration on both sides.
• Editing Can Be Difficult: The whole point of the waterfall methodology is that it follows clear steps over a set time frame. Once these elements are defined, it can be difficult to make changes if the development team runs into an obstacle. Adaptability is a crucial part to consider in software development, especially since it can be difficult for customers to have a thorough understanding of the project before it begins.
• Last minute tests: once again, one of the disadvantages of the traditional methodology compared to Agile is that the tests are carried out close to delivery and therefore there is much less time to be able to remedy in case of unexpected events, or that these can cost a lot in economic terms.

Agile Development

The main difference between agile and waterfall could be summed up by saying that the waterfall approach values ​​planning ahead, while the agile approach values ​​adaptability and engagement.

There are several types of agile development that share some basic similarities. These include:

• Extreme Programming (XP)
• Scrum
• Kanban
• Lean Software Development
• Agile Unified Process

The agile methodology has two fundamental elements: teamwork and time. Instead of creating a timeline for a large software development project, Agile splits the project into individual deliverable parts. These “time-boxed” phases are called “sprints” and last an average of 1-4 weeks. Once each sprint is completed, the feedback from the previous stage is used to plan the next one.

Fundamentals of agile development

There are several fundamental principles that any agile development project will follow:

• Adaptability: Agile development highlights the importance of being able to change design, architecture, requirements and deliverables on the go.
• Customer Engagement: Due to constant changes in design and deliverable units, agile software development requires close collaboration between the stakeholder and the development team.
• Lean development: the aim must be to make the final product as simple as possible. If the same end result can be achieved with two steps instead of five, agile development will aim to design the software accordingly.
• Teamwork: As we said above, Agile values ​​teamwork almost above everything else. Teams need to continually evaluate how they can become more effective and adapt the project as they go. Extreme Programming (living up to its name), for example, insists that developers work in pairs on the principle that two heads are better than one.
• Time: the development duration is divided into very short time slots called “sprints”.
• Sustainability: Instead of pushing for faster deadlines in exchange for an unfinished project, agile development values ​​setting a sustainable pace for software development.
• Test: Unlike cascade approaches where there is a separate testing phase, agile approaches insist on testing at each stage of the project (in each sprint).

Benefits for Agile Development

The advantages of agile development have everything to do with customer satisfaction and the final result of the project and are:

• Stakeholder Engagement: Adopting an agile approach enables - and actually encourages - ongoing engagement between the development team and the customer.
• Flexible Results: Agile allows stakeholders to prioritize deliverables in order of importance. In other words, if a customer wants to release the core software before the full suite, this is exactly what agile enables.
• Adaptability: We mentioned adaptability above as a crucial element of agile development, and it’s also one of its main advantages. As customers get a better idea of ​​what they need from the software, development can adapt planned sprints accordingly.
• A superior quality, easy to use product: Because customers can provide feedback after each sprint, products developed using the agile methodology often end up being very user friendly and more robust.

Potential drawbacks

Agile can have disadvantages for certain situations or teams and they can be:

• Intense engagement: Unlike the traditional mode, agile development works well only when the entire development team is committed to the project throughout its duration. This could be a challenge for some development companies that have a lot to do at the same time, and it could even prove challenging for individual developers.
• Potential for higher cost and longer deadline: While time-boxed sprints allow for planning, it is always possible that some deliverables will not be completed on time. Creating the necessary additional sprints can mean a higher project cost.
• Communication: Since agile requires a high level of collaboration, development projects using this methodology will also require a high level of communication.

So summarizing when should Agile be used and when the Waterfall method?

Classic project management works great when the requirements are clear and what you are trying to develop is somewhat similar to something that has been developed in the past.

In the event that your project does not have clear and defined requirements or the customer is unable to define their wishes, then the Agile methodology can be for you. This will certainly prevent you from arriving close to delivery with a product that is not in line with the expectations of the stakeholder.