In this series of articles, I will focus on the main pitfalls of agile methodology. I will not explain in detail what it is and how it differs from classic waterfall methods – we all know that. If not, there’s an agile manifesto – compulsory reading for anyone who wants to learn more about agile methods.

In the first part of this series, I will briefly summarize the main differences between the waterfall model, fixed price, T&M and agile development in terms of developmental work and client risk.

Waterfall

This is the most classic approach – at the beginning, the requirements, technologies, budget, project scope and people allocation are firmly defined. One phase strictly follows the other and each completed phase must be virtually perfect. Which is very difficult to do in real life, as the situation changes from day to day, and what looks feasible on paper might not work in practice.

Fixed price

This is a classic format that nobody has a problem with. It’s the zero point. The goals and work schedule are set, exact costs agreed upon. However, this collaboration format might not be the best choice for a client who doesn’t know exactly what they want (and who is not an IT company). In which case I’d rather recommend a T&M approach.

T&M

Partly similar to SCRUM, this form of short-term, effective cooperation is used by most modern companies that do not have agile. You simply order the work on a weekly or biweekly basis and keep track of results over time. You pay for the time and materials spent.

Agile

Agile works on the principle of short-distance runs, so-called sprints in SCRUM. There is always one specific thing that is to be completed at the end of the sprint. This is then worked on and, during the sprint, it is not expected that another part of the project will be completed. The measure of success is the amount of software delivered. This methodology is ideal for clients who are not IT companies or do not have a clear idea of ​​the complexity involved in developing software. Thanks to the agile method, the client gets individual, working pieces of the resulting structure, not an interim jumble of separate parts. And this is actually the first lure of agile – the delivered software must already work.

Here is a brief presentation of each approach. Now, imagine you’re a top manager. You are in charge of software development and repeatedly fail to achieve goals. There are several reasons for this, and most of them are quite complex. You need a miracle pill. A magical abracadabra, the solution to all your difficulties – agile. There are several relatively new methods for agile project management, like SCRUM and Kanban. The trouble is that 90% of the companies that want to implement SCRUM are simply abusing the terminology while continuing inefficient processes and an unhealthy decision-making climate. They do not take true advantage of the agile method. In addition, it depends very much on the skills and discipline of the company’s employees. The larger the company, the more this becomes apparent. This is what we will look at in the next episode in our “agile” series.

Reference: Takeuchi & Onaka: The New New Product Development Game