Agile compared to traditional approaches

Agile can be applied to a wide range of tasks and projects. Next, we'll illustrate Agile by comparing it with the traditional way of working.

In the software sector, the traditional step-by-step working method is referred to as the waterfall model (see image below), but its stages are identifiable in a wide range of other work. We encourage you to consider what steps your work involves or whether you have already partially progressed to a more agile way of working.

The first stage of the waterfall model is requirement analysis, followed by design, implementation, testing, and, finally, deployment. The work begins with an analysis of the desired end result and its qualities. This stage results in an analysis document containing a detailed description of the expected outcome from the product or service user’s perspective.

The analysis stage is followed by a design stage in which solutions that fit the end result are designed based on the data in the analysis document. This stage also results in a document, but this document describes the internal structure of the end result as accurately as possible to make the work process easy and explicit. The actual work will be carried out during the implementation stage based on the design document. The implementation stage is followed by the testing stage. This stage ensures that the outcome works and that the expectations recorded in the analysis document are fulfilled. If the end result is found defective, it will be corrected. Finally, the finished product or service will be transferred to customers or end-users.

This is a classic description of the traditional waterfall model, in which separate project stages follow each other.

The traditional, stage-based way of working is problematic for the following reasons:

• The analysis stage carries too much weight in relation to the other stages. The success of all other stages depends on identifying and describing the requirements for a product or service in advance.

• If the team or customer detects new needs during the development process, the analysis and design stages must be carried out again at least in part. This makes changes difficult and costly, and in practice, leads to the avoidance of changes.

• Often, different work stages are divided between several people or teams. For the project to be successful, communication between the people and teams must work seamlessly. In reality, communication is often poor, leading to problems and misunderstandings during the project.

• The customer may outsource the various work stages to different parties. Contract agreements are often made based on the original analysis or design documents and do not take into account any additional needs that may arise along the way. If the analysis or design documents are unclear or incomplete, disputes about what is included in the price may arise, or the budget may be exceeded.

• The first feedback from the actual product or service users won't be received until the end of the testing stage, and the feedback will come too late to be used in the design, as most of the project’s development work will already have been carried out. It is not uncommon for users to reject a product or service developed using the waterfall model as useless.

• The traditional waterfall working method involves plenty of coordination and bureaucracy. Therefore, a successful project requires a project manager. At the same time, agile projects may not require a project manager at all.

Agile product or service development differs significantly from the traditional way described above.

Significant changes to the plans may be necessary during the project, and this fact must be recognized to make agile methods possible. Changes are always aimed at achieving the best possible outcome for users. Instead of sticking to the original plan, the aim of agile development is to create a framework that enables learning, insight, and change. This way, planning is done and updated continuously—not on a one-off basis at the beginning of the development project. At the same time, the aim is to make improving the product’s or service’s quality as easy and affordable as possible.

There are no separate stages in the agile working method: all parts of the work are done in every iteration or sprint.

In practice, the agile working method differs from the traditional way of working as follows:

• Development is carried out in periods of 1-4 weeks, known as an iteration or a sprint. Each development cycle involves all the different tasks related to the project, such as analysis, design, implementation, and testing. If necessary, the product or service can also be deployed once or more during the sprint. In ideal circumstances, the first cycle already includes deployment.

• The aim is to create a light but high-quality basic version of a product or service as early as possible and introduce it to at least a small group of users. This aims to ensure that the feedback and experience gained will guide further development.

• The work will be carried out by a single team with all the knowledge and skills needed for a finished product or service. This reduces the need for continuous communication with experts outside the team, which speeds up the process.

• The team carrying out the work is as self-managed as possible. It's given sufficient power and responsibility, which increases the sense of meaningfulness, motivation, and commitment among the team and improves the quality of work. An important component of Agile is how a team or organization is assembled. In other words, working methods are not the only decisive element.

• Work management is based on a list of tasks (backlog) indicating the individual sub-objectives. The backlog doesn't have to be “complete” at the beginning of the project (like a traditional requirement specification document); instead, it changes continuously. Items can be added to or removed from the backlog at any time, and existing items can be changed. The backlog is available to the whole team; with self-management, this reduces the need for coordination.

• The team’s working methods such as interaction, tools, rules, and responsibilities are evaluated and developed in each development stage along with the actual development work.

According to the Standish Group, a foundation that studies performance in business and in the public sector, an agile project can be up to six times more likely to succeed than a project using traditional working methods. Success has been assessed, on the one hand, in terms of timing, budget, and achievement of objectives; on the other hand, on the value of the project and on the users’ satisfaction with the output. The image below illustrates the difference between the traditional waterfall model and the agile model with regard to value creation. Agile enables faster value production—that is, various benefits for the recipients of the product in question.

Agile aims to provide value as quickly as possible.

Agile emphasizes product thinking, and the whole lifecycle of a product or service is seen as a continuum and not just as a single project. The aim is not to “complete” a project and then let go of it; instead, the lifecycle approach involves continuous iteration as needed. The product or service will be developed for as long as development adds value to the product’s users. Therefore, adopting an agile working method can significantly change the way work is organized within an organization.