Busting the myths around Agile

Busting the myths around Agile


Author bio

With the advent of unprecedented digitization, the world today is spiraling into a volatile, uncertain, complex and ambiguous (VUCA) environment. Organizations are increasingly looking at a way to not just survive but thrive in this fast-paced, ever-changing environment. In this hour of need, several organizations are turning towards Agile. While Agile is the buzzword in the market today, it is a concept that is often misunderstood. Is Agile a methodology? Does it work in a non-software context? And so on.

As the buzz around Agile grows, so do the questions about it. When these questions are not answered adequately, several myths have cropped up around it. These myths can either prevent organizations from adopting an Agile way of working or make them choose it for the wrong reasons. Both scenarios are undesirable because they result in organizations not leveraging the full power of the agile way of working.

In this blog, we bust the three common myths associated with Agile. This would hopefully help organizations make informed decisions and adopt the agile way of working in the right manner.

Myth 1: Agile is a METHODOLOGY

This is possibly the most common misconception about Agile. Organizations and people tend to be confused that agile is a methodology that needs to be adopted and executed. Some people also think of agile as just doing iterations, retrospect meeting, daily standups, etc. So, what is it really then? Agile is a MINDSET – a way of thinking or philosophy. Mindset is one of the most important elements and something that is actually missing in the agile manifesto. Before we go any further, let’s first look at the agile manifesto.

4 values of Agile:

12 Principles of the Agile Manifesto:

As you can see, the Agile Manifesto is all about 4 values and 12 principles. It does not mention anything about methodology. Perhaps, it is the misinterpretation of the manifesto over years that has led people to believe that Agile is simply about implementing a set of rules or practices. However, Agile is more about a set of principles to guide you in the decisions you take. Agile is principle-driven (mindset) and not rules-driven (methodology).

According to Wikipedia, “Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing and cross-functional teams. Agile itself has never defined any specific methods to achieve this, but many have grown up as a result and have been recognized as being ‘Agile’.” Words like Scrum, Kanban, XP, etc., that you must have often heard of are actually methodologies based on the agile values and principles.

Being agile, on the other hand, is a way of thinking primarily focused on the customer. Therefore, to deliver what the customer demands, in real-time, teams must focus on collaboration, continuous improvement and commitment to quality, focus on people and delivering value, empowerment and self-organization.

In other words, successful agile transformation starts with changing how we think—specifically, in my opinion, how we think about priorities and failure. Priorities become linear and organized instead of reacting based on what is broken. Failure is no longer looked upon as something to be feared; instead, we embrace failure as a learning experience.

Successful agile transformation requires an organization to be prepared to undergo a meaningful shift in both methodology and mindset. It’s not just changing what you do, it’s changing how you think. Once you make this shift in perspective and fully embrace it, you derive a higher chance of reaping the rewards of agile.

Myth 2: Agile works only for the TECH teams

Probably the number one question we get asked in the Agile context, is this – “isn’t Agile for software development only?” After all, the Agile Manifesto was born in the world of technology by a group of developers wanting to write software better, and to simplify and find commonality in the software development life cycle. But, why do you think the agile principles don’t work in any other context (non-tech)? Probably, not just because of Agile’s origin in the software domain, it could also be because of words like “software” and “development” that are seen very often in the same. Let’s just pull out the agile manifesto again and have a glance at the 12 Principles of agile. Though the word “software” is seen a few times, just try and replace it with another like a ‘product or project’, and you can see that it will still make sense.

Agile has come a long way since its inception back in 2001. Though it was initially meant to aid software development, it has evolved with time and a lot of non-tech teams and industries have begun adopting agile significantly. Any project with a high degree of uniqueness, unpredictable environment, higher potential of change, continuation and complexity, and shorter feedback cycles is well suited for agile. Agile works for any team – software or business. It is important though to implement Agile thinking and build Agile mindset at an enterprise level, for the goal to be met.

Agile, these days, is used for all forms of product development, from physical products to cloud-based software-as-a-service. But beyond product development (both hardware and software), agile principles are now being applied successfully in a wide range of industries like marketing, legal, human resources, communications, manufacturing, healthcare and financial services:

Though it took a while to catch on, Agile has found significant success among non-technology teams and industries and has seen major adoption and is only starting to spread its wings to various other streams.

Myth 3: Agile means just action and NO DOCUMENTATION.

The highlighted area in the above image is one of the primary reasons for this misconception, resulting from a misunderstanding of one of the values in the ‘Agile Manifesto’: ‘Working software over comprehensive documentation’    

However, this doesn’t mean documentation has no place in an agile approach. Now, as you can see there is no indication that agile means no documentation or that documentation is not needed, it is just that the focus should be on delivering a working product instead of investing major time in creating detailed documentation that may reduce the probability of success in delivering a working product.

Therefore, we need to step back and understand the true essence of the agile manifesto –  ‘While there is value in the items on the right (working software/product), we value the items on the left (documentation) more’. A better way of looking at this is that Agile doesn’t do documentation for documentation’s sake. There cannot be any excuse for abandoning documentation in an agile approach, documentation is just as important in agile projects, though it is often more focused and value driven. Therefore, Agile does not support little or no documentation—Agile advocates the “right” documentation, just ‘enough’ that is required for a project, at the right time.

The level of documentation needs to be appropriate to the project you are working on and the level of maturity of the team. For example, think about the minimum viable information that needs to be captured, with whom it needs to be shared, how to document it in a collaborative way, and how that documentation might help you continuously improve. “Right” documentation also helps to save time and cost during the project development process.

Documenting key decisions and rationale also helps teams from repeating mistakes. The key to documentation is that it needs to be created when truly needed and contain details that will be used going forward. Ideal way to go about this would be to set a process to centralize and share all the documents that have information about the product and the overall project. This repository would also ensure that nothing is lost if team members are swapped or leave in the middle of the project, thus ensuring smooth functioning.

What other “facts” have you heard about that need to be addressed? Think about it this way, if it isn’t making sense to you or if implementing something is creating more chaos than helping you, chances are that you are either doing it wrong or you have understood it incorrectly. While the Agile Manifesto has stood the test of time, it cannot give us direct answers to everything. It is there to guide us on our journey to being agile. So, while you take a copy of the manifesto and pin it near your workstation, also take a minute to really understand what the values and principles are, and how they apply to you, your team and your work.

To make things easier, talk to us at KNOLSKAPE. We’ve got an awesome new simulation that is a surefire way to help you start your journey towards Agile.

New call-to-action

[ca-sidebar id=”9729″]

keep up-to-date

Subcribe to Our Newsletter

Sign up for our free newsletters, including tips to improve workforce capability through technology. We don’t spam!


KNOLSKAPE is a global leader in experiential learning with a mission to help organizations and employees become future ready. Using a large award-winning portfolio of simulations aligned with 100+ competencies and cutting-edge talent intelligence, KNOLSKAPE produces stellar outcomes for more than 375+ organizations across 75 countries. Driven by research and thought leadership, KNOLSKAPE offers its products and solutions in a flexible subscription model powered by omni-channel delivery.

Hit Enter to search or Esc key to close