Agile: Los malentendidos más comunes

On a day-to-day basis working with software development companies I hear businessmen proudly say that “we are agile.” This leaves me thinking, “Is agility itself an achievement?” For me, the answer is no. Agility is many things, but not an achievement per se.

When I talk to different people about the best way to lead a project they think that being agile is “having a weekly goal” or “developing as fast as possible.” That is when I ask them,  

The agile manifesto, written in 2001, indicates that:

• Individuals and interactions take precedence over processes and tools,
• Working software takes precedence over comprehensive documentation,
• Collaboration with the client is more valuable than contract negotiations,
• Responding to change is more valuable than following the plan.

This way of thinking, clarified in the 12 principles suggested in the agile manifesto, is what really generates a change in an organization that seeks to improve the way it works. These principles are:

1. Our highest priority is customer satisfaction through early and continuous delivery of valuable software.
2. We accept that requirements change, even late in development. Agile processes take advantage of the change to provide a competitive advantage to the customer.
3. We deliver functional software frequently, between two weeks and two months, with a preference for the shortest time possible.
4. Business managers and developers worked together daily throughout the project.
5. Projects are developed around motivated people. Give them the environment and support they need, and trust them to do the job.
6. A face-to-face conversation is the most efficient and effective method of communicating information to and among the development team.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. Promoters, developers, and users must be able to maintain a constant rhythm indefinitely.
9. Continuous attention to technical excellence and good design improves Agility.
10. Simplicity is essential, or the art of maximizing the amount of work not done.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to be more effective and then adjusts and refines its behavior accordingly.

In contrast to this, I find companies that consider themselves agile and in which situations such as the following arise:

• Managers see any change in software requirements as something terrible and should never happen
  ➔ What happened to the principle 2?
• Entrepreneurs avoid contact between the people who carry out the activities and the end-customers as much as possible, except when necessary
  ➔ Where is principle 4?
• Managers who want to measure progress with the number of hours worked or the PBI completion percentages by developers
  ➔ And where is principle 7?
• Organizations demand constantly late nights from their employees, often wearing them out
  ➔ Where are principles 5 and 8?

Finally, I want to point out that the agile way of working is not necessarily beneficial for all projects.

Some criteria to decide if it is worth working in this way are:

1. Is my development team "mature"?
   1. If it is, you could benefit from self-organization.
   2. If it is not, trying to apply these techniques could harm the organization.
2. Does the project I want to develop have precise requirements from start to finish, and are they not going to change significantly?
   1. If the answer is yes, does it make sense to plan in small blocks instead of planning the entire project at once?
   2. If the answer is no, it would be very beneficial to be able to plan in small blocks of work and receive feedback on each delivery.
3. Does the project have any technical element with which we do not have previous experience?
   1. If it does, the agile approach will probably better handle this uncertainty.
   2. If not, the project could be planned entirely (if the requirements are precise) from the beginning.
4. Could the project's beneficiaries obtain profit or return on investment with partial system deliveries?
   1. If so, it's worth delivering small blocks of work consistently, maximizing short-term value to customers.
   2. If this is not the case, working in small blocks of work can cause more workload and slow down the final delivery of the project, compared to running the development in a single block of work.

I hope this serves as a small introduction to what agility is. Let us know if there is anything we can help you with.