Have you experienced the sensation of applying the latest trends in Agile methodologies, and even though you are experimenting with

- Delays in deliveries
- Multiple errors in Production
- Poor estimations and extra hours
- Time wasted doing things not aligned with the desired functionality
- Lack of knowledge transfer
----- chaos

You are not alone. I have been involved in multiple projects with the same feeling, and I’m going to point out some reasons why those projects ended that way. But first, a little bit of contemporary history. Agile methodologies shortened documentation to the minimum needed to "move forward." This change in mentality, though young people may not be aware of it, led to many improvements compared to traditional waterfall methodologies. However, with this change, new unaddressed problems arose: the lack of formal documentation led to internal team dependencies that, in the end, made the projects not feasible in a timely manner.

One of the most controversial phases, in my opinion, occurs during estimation. Estimation using planning poker or similar methods, in which the entire team estimates how long a task will take, is common.

In such ceremonies, both experienced and junior members provide their time estimates for tasks. But this experience isn’t passed from the experienced to the junior members, and in a matter of minutes, they are forced to estimate tasks that could take several days. Experienced people, in terms of technical skills and domain-specific knowledge, tend to underestimate the effort required if they don’t have time to fully analyze the problem.

Some people might argue that the solution to this is for team members to learn from their underestimations. But that never happens because::

- Nobody wants to appear as someone who foresee to takes too long to complete an easy task.
- The budget isn’t unlimited, and overestimations are not well-received. Even directly refused by the Product Owners

To make accurate overestimations, you need solid arguments, and to have arguments, you need a detailed analysis and design of the problem to solve. This isn't possible without proper analysis. So, my advice to overcome this limitation includes several tips:

- Always include an analysis phase where every task has a detailed breakdown of subtasks.
- This analysis should take place in a Sprint before the Estimation Sprint (two-phase approach).
- All team members must have read and understood the analysis before entering the estimation phase.
- The analysis should be done by experienced members, but if that's not possible, newer members should be involved.
- The analysis should not be a return to waterfall methodology. Practice Agile Analysis.

These tips, are the base of the methodology called the "Know-aware Methodology," that have been successfully applied in multiple projects, leading to real improvements in efficiency.

I was very happy to learn that after several years, the team I started applying this methodology with is still using it, and reluctant to change