Agile Journey - Most common misunderstandings

José Ángel Labbad

Project Management Office Director

Jul 19, 2022

In this article:

Summarize this blog post with:

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.

Frequently asked questions

What is the most common misunderstanding about agile?

The most common misunderstanding is thinking that agile means working faster or setting weekly goals. Agile is about delivering valuable software frequently, collaborating closely with the client, adapting to change, and improving how the team works. Speed can be a result, but it is not the purpose of agile.

Does agile mean there is no planning?

No. Agile does not eliminate planning; it changes how planning happens. Instead of defining every detail from the start, agile teams plan in smaller blocks, review progress often, and adjust based on feedback. This is useful when requirements may change or when the team is working with technical uncertainty.

How should progress be measured in an agile project?

Progress in an agile project should be measured by working software and business value, not only by hours worked or completed task percentages. A team can be busy without moving the product forward. The real question is whether each delivery helps the customer or reduces uncertainty.

When is agile a good fit for a software project?

Agile is a good fit when requirements may change, the team needs regular feedback, or partial deliveries can create value before the full system is complete. It also works better with mature teams that can self-organize. Without enough team maturity, agile can become confusion with meetings.

Software Engineering