Agile is a mindset described by 4 values and defined by 12 principles that guide how to create and respond to change empirically in scenarios of uncertainty. Organizations adopting this alternative way of working can expect teams to become self-organized, innovative and capable of overcoming challenges. It puts the focus on customers’ needs, enabling organizations to improve each day the way people interact with each other while delivering business value. However as it’s not prescriptive (“do this and then do that”), many organizations and people find it confusing or lacking detail.


The roots of Agile are in professional software development where software developers’ main goal is to codify rules in order to produce a system that meets a set of business objectives. In this kind of context, there isn’t a full understanding of what the solution to the problem will be until the solution is completed. This uncertainty means the solution starts to take shape and be clearer as the project progresses. Unfortunately, history tells us that it’s tempting to conceive an analogy between software development and construction or civil engineering. This analogy is the source of why the waterfall model was usually the methodology of choice, by small or large organizations, when developing software projects.

Going deeper into this subject, the waterfall model includes a strict sequential chain of different project phases to anticipate all possibilities beforehand. The next phase starts after the current one is concluded. All requirements must be defined as detailed as possible and deadlines must be accomplished, but at an early stage, it’s often very difficult to reach such a definition since requirements change and should change during the project based on market changes, new ideas, or what can bring the most value to customers. Most of the time, projects weren’t delivered on time, ended up with several issues and bugs, development teams were stressed and burned out, and finally, customers were not satisfied.


Software developers thought that there must be a better way, a better way of working and delivering value to customers while team members keep their sanity and motivation. Therefore several methodologies and practices were tested and applied in different contexts during the 90s. To understand the context, we have to picture ourselves in that era, an era where e-business, e-commerce and the web as a medium to sell products and services was rising.A group of 17 highly experienced and highly skilled individuals, representatives from Extreme Programming (XP), Scrum, Crystal, Feature-Driven Development (FDD), and others, gathered in 2001 to find an alternative to the waterfall and heavyweight software development processes that were the norm at that time. After that meeting, the term Agile software development was coined and all participants signed the Manifesto for Agile Software Development. However, even if the main sources pinpoint the birth of Agile as a movement to that 2001 meeting, several practitioners were already experimenting with different ways to develop software products way before that date. Based on the outcomes, it seemed that a combination of close collaboration between a cross-functional team and business stakeholders, while frequently delivering business value, was the path to evolve experimentally and have satisfied customers.

Being Agile – A mindset not a prescription

The first sentence of the Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it

This captures the main idea behind a mindset of empiricism, collaboration, transparency, and trust. It’s what separates Agile from other approaches since it is not aiming to dictate the way people do their work but to guide teams to interact and improve using the appropriate practices for their context.


Agile requires a culture of change in the organization with this new way of work. We know that:

  • Organizations and people have memories
  • Sometimes complex processes in place
  • Skill silos
  • Not simply used to let teams work closely with business stakeholders and figure out how they are going to deliver value

Therefore, it’s common to find several organizations “doing” Agile instead of “being” Agile: they focus excessively on how to apply the set of practices in their environments, like Scrum or Kanban, and less if the described values and principles are being experienced.

Although Agile has its roots in software, it reaches well beyond that field, by being introduced in organizations seeking for Business Agility. One thing is certain, to be truly Agile, the organization must be ready for a journey of collaborative improvement, and experimental evolution, always with the focus on their customers.



David Cunha is a Agile Consultant and Software Engineer with more than 7 years of experience, specialised in building scalable applications, teams, and businesses.

His wide knowledge and experience in several domains provide him the ability to see things in both a holistic and detailed perspective, which capacitates him to facilitate the transformation that your organization and people need.

Like this article?

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on Linkdin
This website uses cookies to improve your user experience.