But is this REALLY Agile?

Debunking the 7 Major Myths That Can Lead to Frustration in Agile Teams and Cause Projects to Fail

Agile is the solution. But then, why does it seem like it’s not working?

Throughout my career in technology, I’ve seen Agile go from a developer’s utopia to the crème de la crème of large corporations, and this question has always intrigued me.

Of course, it’s difficult to assign specific statistics, because although there are many sources claiming that X% of Agile projects fail, it's challenging to pinpoint the failure cause as the organizational structure of work or even define what constitutes failure itself. However, all it takes is a casual conversation or a quick search on your preferred social network to find stories of frustration related to what’s understood as "agile processes." But could these root causes of frustration actually define a project or company as being truly agile?

Companies invest millions in certifications for their employees, pay for dozens of agile coaches, hire experienced scrum masters, buy tons of post-its, and add more boards in their offices because the ones they have aren’t enough to stick all the post-its they've purchased. However, none of this seems to yield the expected results.

When observing the dynamics of these projects on the surface, everything looks great: All the roles described in the Scrum Guide are present, all the events, all the artifacts. But even with all of this, things don’t seem to flow.

Over time, I’ve realized that Agile principles have been overshadowed by "replicable formulas" that, not only do they not align with the original concept of agility, but in many cases, they go in the exact opposite direction of what being truly agile means.

That’s why I decided to demystify seven topics that might be leading your team down the wrong path.

1. Maybe You Don’t Need a Daily Meeting

Let’s start with a controversial statement, but one that will help break down several important concepts to understand the following topics. Agile refers to a mindset, not a set of processes and tools. The Agile Manifesto introduced, in 2001, a way of thinking focused on delivering better software products, with its heart in the value-driven approach. Therefore, focusing on applying practices without fully understanding their purpose doesn’t make logical sense. Surely, you’ve heard something like "Scrum isn’t a methodology, it’s a framework." Beyond the technicality, this statement is extremely important because the concept of a methodology refers to a set of systematic practices and processes to achieve a specific goal, whereas a framework refers to a set of components that can be applied to solve problems. Thus, it’s essential to analyze the problems at hand and, using the concepts provided by Agile frameworks, apply specific practices.

In the case of daily meetings, their purpose is to ensure the team is fully aligned on priorities, the progress of planned tasks, and that team members can offer each other support to achieve the Sprint goal (no, the purpose of it is not to provide a daily status update to the Scrum Master or PO). In most cases, a daily meeting is indeed valuable for giving everyone the opportunity to discuss important issues. However, if the team's maturity has evolved to a point where such alignments happen organically without the need for a regular ritual on the calendar, then yes, the daily meeting could be eliminated. Speaking of Scrum, let’s move to the next point.

2. Agility Is Not Equal to Scrum

This is a common misunderstanding since the Scrum Guide was introduced in 1995, six years before the Agile Manifesto itself. At the time, with Scrum being the main known framework, it was natural to associate Agile principles with Scrum’s events and artifacts. However, today there are several other frameworks that offer different approaches and are extremely useful in the toolbox of a good Agilist. Limiting yourself to Scrum and disregarding the possibility of creating Agile teams outside of this framework’s concepts can limit your team's opportunities.

3. Agile Teams Won’t Complete Tasks Faster

A misconception often attributed to the book published by Scrum co-creator Jeff Sutherland, titled "Scrum: The Art of Doing Twice the Work in Half the Time." The truth is that both Scrum and other Agile frameworks do aim for faster delivery, but not by reducing the time required to perform a specific task. Instead, the faster delivery comes from the incremental cycle they propose, where implementation and verification of value happen earlier in the development cycle compared to traditional methods like Waterfall. This way, you can validate business hypotheses and start using what has been completed without waiting for other parts of the project to be finished. And since Waterfall was mentioned, the next point can’t be overlooked.

4. Agile Is Not Better Than Waterfall

If you’re still with me, you’re ready for this statement. Agile and Waterfall are two different ways to organize work, and due to their characteristics and particularities, they will apply to different scenarios. It’s common for Agile frameworks to be seen as newer than Waterfall methods, leading some to think of Waterfall as outdated. However, it’s important to remember that there are products and industries with different needs where a Waterfall approach might lead to more success than an Agile approach. To better understand, I’ll present two examples for us to analyze:

• Company A: A healthcare device company specializing in robotic surgery equipment. Changes to the software of these devices need to be defined in detail well in advance to ensure they comply with regulatory bodies and compliance policies. Given the complexity of platform integration, the scope is often fixed, with predetermined budget and deadlines. This allows for extensive end-to-end testing, ensuring the safety of updates.

• Company B: A healthtech startup that connects healthcare professionals with patients through an app with innovative features. All new functionalities are based on hypotheses that need to be validated by users through beta versions to test their viability. With proper process management, updates can be released quickly, which is extremely beneficial since time-to-market is essential to stay ahead of the competition.

In the scenarios above, we can see that Company A would likely suffer more drawbacks than benefits from an Agile approach, and Waterfall might be the recommended method. In contrast, Company B would gain numerous advantages from establishing processes that ensure the early delivery of its features to validate business hypotheses. In short, there is no one-size-fits-all solution, and we must always consider the specific needs of each context to propose different ways of working. The business model should always be at the center of any decision, and this leads us to the next point.

5. Agility Is Not Just About Software Development

Besides the fact that Agile principles can be applied across teams in various fields and are not limited to IT teams, it's important to remember that there is no "Business Agility" if the business teams aren’t integrated into this mindset. It’s crucial for operational teams to be introduced to Agile concepts to not only avoid resistance to a change in approach but also to better leverage their expertise in defining value streams that will guide the software development process for optimal results. And I know many might be thinking, "But the user doesn’t know what they want." To which I counter: Yes, the user does know what they want. What they might not be sure of is how to achieve that result, which is why integrating business and technical areas is essential for delivering the value that agility strives for. The proximity of all areas of the company will facilitate scope definition and constant prioritization, which Agile requires, and this brings us to the next point.

6. Agile Requires Proper Planning and Documentation

Contrary to what many might think, Agile processes can require much more structure and discipline than Waterfall projects. This is because, rather than just one phase of detailed planning, in Agile, these activities occur constantly with a much more frequent need for change management. For this reason, it’s important that delivery cycle goals are clearly defined (and not just consider the goal to be delivering all the Story Points), that progress is tracked daily (hence the usefulness of flow visualization tools like Kanban boards and burndown charts), and that dependencies and blockers to workflow are monitored. To assess if the process is functioning properly, there are specific tools that are underutilized, and this leads us to the last point.

7. You Might Need More Metrics Than You Think

It’s common for Agile teams to rely on velocity as their only regularly calculated metric, and because of this, they might use it for purposes where it’s not applicable. It’s important to remember that velocity is a measure used solely to help with future planning, based on a team’s historical data. Velocity is not a performance metric, as it’s based on the average complexity delivered, not on the value added. However, there are many other metrics like Lead Time, Cycle Time, Throughput, Defect Rate, Code Churn, Backlog Health, and many others that can help give a more holistic view of the process and identify areas for improvement.

I hope the points covered here help clarify that agility is much more complex than simply scheduling daily meetings, planning sessions, and retrospectives. It’s an approach that should consider the needs of each team and establish processes and tools that will facilitate the achievement of set objectives. Above all, it’s about creating an environment of collaboration and trust, making Agile principles a natural part of daily activities. As Jim Highsmith said at the end of the Agile Manifesto story: “We hope that our work together as the Agile Alliance helps others in our profession to think about software development, methodologies, and organizations in new – more agile – ways. If so, we’ve accomplished our goals.”