When Agile Won't Work

Agile, among other flexible methodologies, does not lose its attractiveness and popularity. Like most flexible solutions, agile is supposed to minimize risks by splitting the development process into multiple short iterations, each taking about 2 weeks and not more. Each iteration consists of standard development process steps, like planning, design, development, testing and creating documentation.

However, using agile approach is not absolutely reasonable in all cases. Obviously, agile works the best in smaller projects, provided that all agile principles are respected. Due to proper usage of user stories, understanding between the customer and the team is easily reached. For customer, it takes less time to set up priorities, explain goals, make corrections. Developers have better understanding of client's needs. Moreover, the gap between the expectations and the result is smaller due to short iterations, which allows easily adjust the process and avoid misunderstandings.

However, agile is not a silver bullet and in certain cases using it won't be reasonable.

Obviously, agile won't work when used just to be used, just because it's trendy and many teams claim they use it. Using agile looks like you belong to some secret society, but this is simply because agile is deceptively simple and it has no strict rules. As the result, implementing agile sometimes becomes just a formal procedure, which does not change the actual flow.

Agile is mistakenly used for minimizing costs on projects involving complex logic and algorithms, when user stories cannot cover all hidden logic and when thorough planning and detailed analysis are crucial. In the end, neither the team nor the customer are able to estimate the effort needed to create the product.

A big mistake would be to use agile methodology for a large-scale multi-functional project, which involves a complicated architecture. Implementing user stories during short iterations may lead to overlooking fundamental principles that are vital for the project. As the result, the team will need to rework functionality partly or from scratch. Also, after few iterations it may become clear that selected technologies do not meet all project requirements and the project requires completely different technical stack.

Finally, agile is not the best approach for startup teams. Startup companies do not have enough balance and stability, established workflows and processes are missing and the teams are not stable. In  well-established teams with organized workflows and stable processes agile brings flexibility and fresh air. In startups agile approach just brings more mess.