Agility is now widely recognized as the framework for software development. Waterfall or V methodologies are seen as old and ineffective ways of working. Instead, we now rely on frameworks like Scrum, Kanban, and XP to guide our projects.

However, the question remains: how agile are the implementations of these frameworks?

We often encounter a significant dichotomy when implementing these frameworks. On one hand, we have the dynamics of our chosen framework, and on the other hand, we must consider the demands of the business, the market, the client, and the project itself. Scope and quality are concerns, but the notion of "time is money" frequently undermines the intentions of building a project based on Agile, where intrinsic estimates are neither viable nor practical.

This is especially the case when we frame an Agile project in a roadmap stretched out over time, where planning is more based on prescription than on adaptation.

In a development project based on a budget determined mainly by the time factor, it is taken for granted that we know what the solution to the problem must be. However, in reality, we usually learn more about the problem during the construction of the solution, leading to readaptation of the solution. This is where agility comes in.

In an iterative and incremental development cycle, where MVPs are built based on the hypothesis of a solution to a real business problem, agility allows us to arrive at the best possible solution. Therefore, in an agile framework, there are projects based on the hypothesis of a solution, with a very limited scope in time that allows us to learn and have feedback from the business, users and clients, to direct the following stages in the continuity or adaptation of the project to build a complete solution.

When we build an Agile project based on predictability, extensive roadmaps undergo various changes, leading to inaccurate estimates, frustration of the teams, endemic rework, and waste of time.

To avoid transforming our agile way of working into a rigid process, we can put these good practices into practice:

• MVPs with a limited scope
• short roadmaps with a general definition,
• technical teams that understand and are committed to the business,
• a business that understands technical challenges and trusts teams to manage the project,
• definitions designed by both the business and the technical team,
• fast and constant delivery of value to the business, and feedback from the business to continue projecting the solution, based on the impact of the value delivered for solving the problem.

Otherwise, no matter how hard we try to train, certify and apply an agile framework, we will not see its advantages. Instead, we will be changing names, labels, and applying marquee changes to previous work methodologies, and obtaining the same results, i.e. increased costs, and frustrations.

That is not good business.

‍