Five traps that agile methodology lets you avoid.

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 agile method will deliver the product effectively.
  • Agile management protects you from losing a lot of money.
  • Using agile you can have a quick delivery of verified business value even at an early stage of product development.

The flexibility of the scrum method 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.

Read more
Read also “Product Owner – the customer’s ambassador”
Read more

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 the Windows operating system.

The agile method 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 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 way of working.

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 method, it is possible only to pay for used “time and materials”. Contrary to a 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, 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 way of working 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.


[1]     https://www.pcworld.com/article/125772/worst_products_ever.html

[2]     https://hbr.org/2011/08/henry-ford-never-said-the-fast

About the Author: Jan Matulewicz

He has been associated with the IT industry in various roles since 2004. Technical documentation specialist, tester, java developer, team leader, project manager, line manager, product owner and finally – the Head of Software House. He is a graduate of Center of International Education at the Lodz University of Technology and Executive MBA at the University of Lodz.

He’s an enthusiast of technology in the service of humanity, information humanism and engineering of miracles. An occasional lecturer and personal development coach. He supports the theory of the world of good, work as a natural human need and the enrichment of societies.

Read the articles:

Want to talk? Go ahead!

2019-08-29T12:32:14+00:00June 25th, 2018|articles|0 Comments

Leave A Comment