Skontaktuj się z nami

Five traps that agile methodology lets you avoid

The traditional development seems to be stable and predictable. It is, in fact, prone to mistakes. It is easy to avoid them with the agile methodology

Contrary to the traditional methods (for example – waterfall) the agile one operates on sprints. After everyone, the project is reviewed. The Product Owner, in cooperation with the rest of the team, sets up new goals to reach in the next iteration.

The flexibility of the scrum methodology makes many traps of traditional planning and development easy to avoid.

1. The sunk cost

Sunk cost refers to the value, that cannot be recovered, yet it has already been incurred. In the software development, it applies to all the redundant features the development team wasted time for. Sometimes all the project may be sunken cost itself.

In traditional programming, it is hard to see, that there are sunken costs in the project. According to the documentation, all the features are crucial. What’s more, all the testing and implementation may be only done after all the code had been written.

On the other hand, the agile programming focuses on delivering the Minimum Viable Product as fast as possible. The client gets the first version and may (or may not) apply some changes to the project. And, what’s even more important, it is possible to rethink all the product when reviewing the MVP. If the solution is already usable, are all the features necessary?

2. The wrong assumptions

All the project documentation is based on assumptions. The company designs the solution with the client's data and business processes. Before the first test, it is troublesome to check, if the assumptions were right.

Again, the MVP makes testing much easier than when the software is being delivered at once. Every iteration allows the customer and the Product Owner to redesign the solution.

And when the assumption is wrong? The result may be as comic as catastrophic. In 1995 Microsoft assumed, that the interface based on the image of the living room would be better than the traditional desktop. That’s how the Bob Graphic User Interface was created. To launch the notepad, the user had to click the pen and paper on the desk. If he had got lost, he could ask Rover, the dog-mascot, for some hints.

Even Melinda Gates as marketing manager of Bob could not stop it from being the most known failure of Microsoft. The product was widely criticized and axed shortly after the launch. PC World’s included it on the list of “The 25 Worst Tech Products of All Time[1]”. The paper clip assistant in Word was one of the last artifacts of Bob in Windows operating system.

The agile methodology lets the company verify the assumptions long before the delivery. Therefore, there is no modern “Bob” in Windows 10 or any other popular OS.

3. Inaccurate expectations

Opposite of the assumption, there is an expectation. Although the client usually knows what he wants, it is usually not the thing he needs. Henry Ford, in (not[2]) his famous quote, said: “If I had asked people what they wanted, they would have said faster horses.”

The same problem is present in the IT business. Many customers cannot precisely tell, what do they want. IT is not about building the old stuff on digital steroids. It is all about the reinvention of the business processes. And it is much easier when done in iterations, with agile methodology.

4. Wrong time and costs estimation

In the old-style programming methods, the cost and time were fixed up before the project. That’s why the delays were frequent. What’s more, the software house tended to overprice the project with some “unexpected work” in mind. Not the win-win situation at all.

With the agile methodology, it is possible only to pay for used “time and materials”. Contrary to fixed price model, the product can be cheaper and faster delivered.

5. Need for some deep changes in the end

In the early stages of the project, it is much easier to redesign the solution. Software development may be compared to an iceball, getting with time bigger and harder to stop. In the end, it may be impossible to change the course or the architecture of the solution.

In agile methodology, each sprint is an occasion to rethink and redesign the software. Reviving the course frequently during the process makes testing and applying the changes much more natural.

The traditional way makes the deep changes complicated, if not impossible.


The flexibility of the agile methodology is not to underestimate when it comes to reducing the cost and amount of work in delivering the software. It is also a great tool to avoid the mistakes. That’s why it is more common for development teams to work in that model – it is all about the client satisfaction.