We've Just Busted Our Favorite Agile Myths (and We Didn't Cry)

When I first stepped into the field of Kanban, I have to admit that I was almost clueless about what exactly Agile is.

I remember that the first question I asked was, “Guys, is Agile a methodology, a method, a framework, or a philosophy?” I received the answer, and then I spent the rest of the day researching what’s the difference between the four.

Two years later, I still check what’s the latest on the web, just in case some new explanation blossoms.

And unfortunately, many of the myths we will look at today are included as reliable information in many Agile guides. Enough is enough. Let’s bust the most widely spread myths about Agile that still pollute the Internet.

Myth 1. Agile Is a Methodology

This is the most important Agile myth to debunk. Is Agile a methodology?

There is a lot of misconception and controversial information on the Internet about whether or not Agile is a methodology.

A methodology will describe a step-by-step process of how to do things or how to achieve a goal. In this sense, Agile is not a methodology.

Agile is a philosophy, а mindset that describes a set of values and principles coined in the Agile Manifesto. In fact, the authors don’t mention anywhere in the Manifesto that it is a methodology, they describe 4 core values and 12 principles that they follow.

Organizations use different Agile methodologies and approaches, such as the Kanban method or frameworks such as Scrum, Extreme Programming (XP), etc.

Myth 2. Agile Equals Scrum

How often have you heard the expression “We are doing agile project management,” and under agile, the presumption is actually “We are doing Scrum?”

I hear it all the time.

Often, people assume that Agile equals Scrum, but they are not the same thing. Primary because Scrum is a framework, while Agile is a mindset, an approach that follows a set of values and principles that many methodologies have adopted, such as Kanban, DSDM, and XP.

So Scrum is one of the many methodologies that fall under the umbrella of the Agile principles and values, coined in the Agile Manifesto.

Myth 3. Agile Is Anti-Documentation

The myth that Аgile doesn't favor documentation is very likely to come from misinterpreting one of the Agile Manifesto values:

"We value working software over comprehensive documentation."

The other confusion might come from the fact that Agile prefers face-to-face communication rather than entirely relying on written words.

It is essential to understand that Аgile is not anti-documentation. It's more accurate to state that Agile doesn't urge any team to do documentation only for the sake of having it.

It's more important to deliver a working product to our customers than having detailed documentation upfront.

To conclude, documentation is treated like any other deliverable on an Agile project.

Myth 4. Agile Means No Planning

This myth is one of the most surprising to me. Have you heard about the Agile planning onion?

It represents the idea that Agile planning is applicable at every slice of the onion.

The important aspect of Agile planning is that it’s iterative - you develop and adjust your plan multiple times, as you find necessary. The goal is to invest time in planning at the best possible moment and adjust to changes easily if they occur during the execution phase.

Let's take a look at how much planning we conduct in our Marketing department:

1. Daily planning: our team does daily planning with the 15-minute daily stand up meeting. Еxcept that we discuss what we have accomplished the day before, we explain what we plan to do today and why we plan to do it.
2. Weekly planning: each week, we plan our team's work on our Kanban replenishment meeting.
3. Quarterly planning: each quarter, our team holds a meeting, where we plan our quarter goals. We visualize and track them through the help of initiatives.

However, planning is often less visible because agile teams pursue planning as a series of smaller, recurring activities to ensure that their plans reflect the realities of the present.

This way, agile teams develop plans the same way they develop products - by revising and adapting.

You can see that Agile isn't anti-planning; it's anti-static planning. And if you had any doubts about whether agile is anti-planning, by now, they should be busted.

Myth 5. Work Must Fit in a Sprint

Not exactly. Actually, not at all. From busting Myth #2, we already know that Agile doesn’t equal Scrum, which means that you can have an Agile organization that doesn’t have to fit work into sprints.

In Businessmap, we apply the Agile Kanban method, which doesn’t require “sprinting.” Instead, we rely on continuous flow and apull-system. By having historical data for our flow cycle time, we can relatively accurately predict when a given task will be finished. And even if the task is not finished this is not a big problem, as we rely on the continuous improvement model. Explained shortly, it is a never-ending strive for perfection in everything you do.

But what happens if you try to fit your work at all costs in a Sprint, even when the capacity of your team is already depleted? Your team members may experience a burn-out, leading to a series of mistakes such as delivering a low-quality product and even a decrease in overall performance (e.g. a task that typically takes 30 minutes to finish may take 2 hours).

Now, don’t you think that this isn’t a very efficient approach to improve a team’s performance? It’s way more natural for the team to continue pulling tasks based on their availability, rather than thinking about them in a time-framed box.

Myth 6. Employees Get to Do Whatever They Like

Which is not true. Employees don't get to do whatever they like. Actually, it's the vice versa - Agile needs well-disciplined teams.

From my discussions with more traditional project managers, it seems like they fail to grasp the differences between Agile and the traditional waterfall-oriented model - a collaborative and iterative process, which involves adaptation based on discussions between the team, building the product, and the client.

This means that each team member should be ready to help its peers whenever they need help, should collaborate with them, and be open to acquiring new knowledge so that the team could deliver a faster and higher quality of work.

This is definitely something that cannot be achieved through anarchy but by having well-disciplined teams.

Myth 7. Agile Doesn’t Work for Projects with Deadlines

Again, this is another myth that Agile doesn't work for fixed deadline projects. Probably the confusion comes from the fact that you don't have to put deadlines on every task related to a given project. However, the whole project can have a deadline.

At the end of the day, your clients need to know when the projects will be completed, but what's not required is the exact finish day for each task.

As in Kanban, with the help of the continuous improvement model and the application of a pull-system, deadlines on the micro-level are unnecessary. However, with the help of a metric, we track - the average cycle time, we are able to better predict the deadlines of our initiatives.

Myth 8. Agile Works Only on a Small Scale

I've heard this many times: "Agile won't work for our company. We are too big."

While Agile works best when implemented in small teams, this doesn't mean that it won't work for larger organizations. It means that you will have to start small and then scale the implementation of Agile within your organization.

Let's say that your company consists of 500 employees. What will happen if one morning you decide to switch from Outlook to Gmail in one batch, without the proper preparation of your employees?

I will tell you - it will be chaos. The same will happen if you decide to implement Agile on all levels at the same time.

When implementing Agile, you need to consider the culture within your organization, the leadership, and your employees' willingness to embrace this change. Remember that Agile is not a methodology, but a set of values and principles.

From this point, Agile must be implemented in small batches, perhaps in small teams, working on small projects so that you can quickly receive feedback, reflect on it, make the proper changes, and start the next implementation batch.

When larger organizations are embracing Agile, continuous integration of the process on a daily basis is a critical success factor. And if you are a larger organization working on large projects, Agile is more likely to help your organization achieve better results.

Myth 9. Agile Is a Silver Bullet to Success

It's not uncommon for the Agile fanatic to tell you that your organization's problems come from the fact that you are not using Agile as a way to manage projects.

Unfortunately, Agile is not the silver bullet to success, as there isn't such. You can fail with Agile as you can fail by using any other traditional project management approach.

At least, by using Agile, you will fail faster because of the project visibility and transparency it brings.

If implemented right, Agile project management brings to the business a new paradigm for achieving the best quality and value for our products, projects, and clients. Still, it's not an excuse to stop thinking.

Myth 10. Agile Equals Software Development

It's a fact that the Agile Manifesto describes Agile in the context of software development. However, Agile as a set of values and principles, can be applied successfully in any business environment.

These days, Agile is used for all forms of product and project development, from cloud-based software-as-a-service to physical products.

Through the development process of a product or the execution of a project, many departments are involved, which can be Agile too. In fact, they must be.

Imagine having an Agile product development approach but a waterfall approach from the Sales and Marketing teams. This will inevitably lead to dysfunction in the organization.

There are plenty of real-life Agile organization examples out there.

So no, Agile is not only for software development.

Myth 11. Agile Trades Speed for Quality

One of the origins of this myth comes from the perception that speed and high-productivity are traded for the quality of the delivered work. The other source comes from the project development practices that, in Agile, there isn't a specific role for testing and quality check.

However, all those people who claim that in Agile, quality suffers, ignore the fact that testing and quality check, actually happens within the team.

Here is another example of our marketing department. When we produce new content, launch an experiment, or prepare a new marketing campaign, we test and review everything within the team.

The quality check is implemented in each team's workflow. So each task/card passes through the quality check process, and not once, but twice. On our Kanban board, each task is reviewed by two different peers.

Myth 12. Agile Is Undisciplined

I don't know where this myth comes from, but the truth is that Agile is a super disciplined way of delivering projects and work.

One of the biggest misunderstandings about Agile shown on the image above / Credit: https://marketoonist.com/2018/05/being-agile.html/

Here is an example from our Marketing or Onboarding team. If we want to make the slightest change on our homepage, such as testing a headline, we will have to conduct the following:

• Have a viable hypothesis for the change;
• Ask the "5 Whys;"
• Test different headlines by starting an experiment;
• Measure the result;
• Get feedback from the team;
• Synchronize the change with the leadership;
• Implement the change;
• Verify the change;
• Launch the new headline version (goes live);
• Document the experiment (myth #3).

Do you think that this is easy stuff? The truth is that it takes a lot of courage to admit that there is a better way, it takes a lot of hard work and discipline to deliver the end result.

Myth 13. Everyone Needs to Be a Generalist in an Agile Team

This is also a popular myth about Agile that each team member should be able to do everything. Which is false. It's unrealistic to expect from each team member to be proficient in all skills required from a whole team.

What agile teams value is individuals who possess skills in multiple disciplines or those who are most likely to adapt and develop different skills.

For example, my expertise is in SEO, however, I do write well, I understand design, and if necessary, I can make a demo of our product.

I am not required to do so, however, these additional skills are valued, as my team can count on me if they need extra help.

And this is called agility, being able to contribute to different areas which don't mean you have to be a generalist to do so.

Myth 14. Leaders Have No Role in Agile

It’s very likely that the misconception comes from the fact that Agile companies try to keep their organization hierarchy as flat as possible, empowering leadership on every level.

Leaders (traditionally called managers) do have a role in Agile, but it is not to micromanage people.

Instead, they may have the following five leading roles:

• Set objectives;
• Organize people and work;
• Motivate and communicate;
• Measure;
• Develop people.

In Conclusion

With all these Agile myths debunked, we hope that you may reconsider your perhaps, distrustful attitude towards Agile. Or, if you are already doing Agile, but we just showed you some of the cracks in your organization - you will take action and embrace the change.

Let me know of your favorite Agile myths, we would love to add them to this list.

Happy myth-busting!