Agile mindset and myths around it

The term “agile” has probably been heard by many people in different contexts – talking about dog training, talking about IT and software development, organizational management topics, and more. Agile thinking focuses on exploring the surrounding environment and figuring out how to achieve your goals as well as possible with as little effort as possible.
I will write down 9 myths that circulate around the term “agile” and that I have often encountered in my work.

Myth No. 1: Agile means doing fast and over the top

This is the myth I have encountered most often in Estonia, for example, conversation snippets along the lines of: “Well, we don’t have time for a lot of planning here, let’s get it done, agile, well” or “This solution is quite flawed, but we did it agilely”. Unfortunately, there is not a single grain of truth in these sentences.
Agile teams need to be highly disciplined to succeed. Planning is critical in an agile approach, but the difference is that you don’t plan EVERYTHING in detail, only a small section of the near future, and if something needs to be changed, the plan is quickly redone. If agile development is done correctly and each work is constantly tested immediately after completion, the number of errors in the project will be minimal.

The reason for the myth is probably the incomplete implementation of agile development methodologies and the lack of awareness of the true nature of agile.

Agile principle No. 9 states that “By keeping technical perfection and good design in constant focus, the speed and flexibility of software development are ensured.”

Myth No. 2: Agile is the same as Scrum

If someone says that they use agile methodology, I always ask them to specify which one exactly? Agile is essentially a way of thinking that includes a number of different methodologies such as Scrum, Kanban, XP, etc. The methodology gives you a specific guide on how to do something. Agility, on the other hand, means values and principles on which many different methodologies can be based.

The reasons for this myth lie in the fact that Scrum is the most common agile development methodology in the world, with more than half of agile teams using it according to studies (source: State of Agile Report 2020).

Myth No. 3: Agile is always the best option

Agility is not always a panacea that works, it is especially useful in those environments and situations that are uncertain and can change. Changes may be due to, for example, the fact that it is not yet known exactly what users need most, or that the surrounding environment may change unexpectedly, or some other external factor. In any case, the strength of agility is being able to cope with changes that happen at any given time.

There are situations where agility does not provide any significant advantage – for example, a project where every detail is already in place and fixed with 100% certainty, or the project is not very large, novel and complex, or you simply do not have the necessary resources for agile – a professional team and knowledge of agility.
I have encountered such situations, but they have been few and far between – usually we live in a whirlwind of constant change.

Myth No. 4: There is no planning in agile development

A myth that I have also often encountered – in agile, you don’t plan much, you just start doing it right away.
If you haven’t heard anything about the Agile Planning Onion so far, here it is:

Agile planning consists of 6 different levels – quite a lot, isn’t it?
The first three (Day, Cycle, Reliis) are done by the agile team, the next two (Product, Portfolio) are on the Product Owner’s dashboard and the last one (Strategy) is carried out at the management level.

As discussed earlier, all agile plans are open to change and nothing is set in stone, but plans are always there. So, agility means planning, but not creating a rigid plan.

Agile Principle No. 2 states that: “We understand changing circumstances, even if they occur in the final stages of development. Agile methods turn such changes into a competitive advantage for our client.”

Myth No. 5: There is no documentation in agile development

This myth probably comes from four agile value phrases, which say that “We value working software more than comprehensive documentation”.

An agile approach does not value tens and hundreds of pages of documentation written before the project, where the entire functionality is tried to be established down to the last comma and button placement. This does not mean that a proper analysis is not necessary before the project. It’s just that people’s direct communication is valued more than the written word on paper.

In an agile project, the customer does not require the development team to follow a detailed terms of reference document to the letter, as in the old days in the case of waterfall projects, instead, the details are specified before the start of each development cycle and written in the Product Backlog (which is also part of the documentation). This approach provides an opportunity to adapt to new changes on an ongoing basis and ultimately create greater value.

In agile development, documentation is like regular delivered work, to the extent and volume agreed upon with the customer.

Agile principle No. 6 states that: “The most efficient and effective way to share information in a development team is a face-to-face conversation.”

Myth No. 6: There is no project deadline and budget in agile development

This particular myth, or rather fear, can be found among business people, e.g. “Agile development never ends” or “It is impossible to say the final price of an agile project”.

All my agile projects have had a specific budget limit and even more specific deadlines. The key is that during the project, the customer’s product owner can freely decide what to do with the money and time, i.e. the scope is not fixed down to the smallest detail.
In agile projects, the development volume and complexity are ALWAYS assessed in advance, based on which the product owner makes a decision whether the ratio of the business value to the cost of execution, i.e. ROI, is good enough to complete the development.

Agile principle No. 1 states that: “The most important thing is to ensure customer satisfaction by delivering the necessary software as quickly and often as possible.”

Myth No. 7: Agile is only suitable for small projects or businesses and does not scale

It’s true that agile teams are small, up to 10 people. However, this does not mean that it is not suitable for larger projects, because in this case, several agile teams work in coordination on the same product or service.

Nor is the statement “We have a company of 500 people, agility is not for us.” Agile organizations are our future, but agility cannot be applied to an entire large company at once, it is impossible. This is done step by step in smaller projects until the entire business culture and processes are based on an agile mindset. This journey is long-term, but the results are very valuable from a business point of view.

There are specific agile methodologies that are used to scale agility, e.g. Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Scrum of Scrum (SoS), etc.

Agile principle No. 8 states that: Agile software development processes promote sustainable development. This means that the project can be continued at the same pace for an indefinite period of time.

Myth No. 8: Agility is a new and niche thing

The world’s largest agility survey, the State of Agile Report 2020, uses data from more than 40,000 companies from different fields of activity. According to the survey, 95% of companies use agile methods. True, only 18% of companies have agile teams.

Thus, agility is very widespread, but there is still room for improvement – especially in the full understanding of the agile mindset.

Myth No. 9: Agility is only an IT issue

Today, agile principles have spread far beyond software development, mainly in the direction of organizational management and operation – you have probably heard the terms “agile management” or “agile organization”.
Agile no longer only means product development, it includes the entire development process of the company, including the work of management, finance, human resources, marketing, IT, and other departments, with the aim of ensuring that everyone works in a unified and adaptable way like one big agile organism. The agile transformation process is carried out in companies by agile coaches who have at least 5+ years of experience with various agile methodologies.