Even though I have been working in project management for over 10 years, I first heard about agile methodology in 2017 when I started participating in more IT projects.

Initially, it seemed like a trendy new term to me. I thought that instead of teaching various methodologies, it was more important to understand the needs of the project and the people involved and to carry out tasks with transparent communication.

However, my desire to learn and my dislike of criticizing anything without understanding its details led me to complete an Agile Project Manager course at one point – and I had to eat my words because I learned exactly what I had been doing instinctively, but in a structured form.

So, what does Agile mean?

What does it look like in theory, how does it work in practice according to my experience, and how do many people misunderstand and misapply it in reality?

I would summarize agility as a methodology that helps manage complex projects with many unknowns. But I don’t think of it as a methodology so much as a mindset, because I see it as focusing less on technical details and more on the approach you take to an unfamiliar task.

Although agility is primarily used in IT projects, this mindset is valuable in any other field where we tackle something complex. The core principles of agile methodology – such as continuous communication, adaptation to change, sustainable work pace and environment, teamwork, and regular feedback and review – can contribute to the success of any project.

The theory is, of course, very comprehensive, supported by several frameworks (e.g., SCRUM, which most IT professionals have heard of), and the essence of this theory is to cover everything and be applicable to any large, extensive, and complex project.

And I think this is where many companies get lost when they start introducing agile methodologies into their daily routines – they suddenly want to apply every single element to themselves and forget that the most fundamental part of Agile is tailoring the methodology to the specific team, project, and complexity. What works for a multinational company will not work the same way for a smaller company, say with 50 employees. Sprints and continuously delivering results are important, as well as having regular feedback, but the resources and tasks required for this are different in each case.

I’ve also seen several times when a company’s management puts on the micromanagement hat under the guise of agile, which is one of the biggest contradictions I’ve ever seen. One of the fundamental principles of agile methodology is not to micromanage team members but to understand and properly motivate them to do their tasks as effectively as possible. (I’m not a fan of micromanagement, and I wrote a bit more about this in the “How I Work” post.)

In any case, I believe that agile methodology is important because it helps us manage changes flexibly and efficiently, and continuously improve processes and results during the project. However, the most important thing is not to forget that a methodology applied for its own sake, without understanding, sometimes does more harm than good.