5 Common Myths About Agile & Their Impact on Projects

Even though Agile has been around for less than a quarter of a century, it's been long enough for it to gather a number of myths around itself. Maybe it's precisely because it's "new" that there exist so many misconceptions about it. The less something is understood, the more likely it is to be speculated about.

The original Agile manifesto's appeal was its simplicity among other things. Yet with time, Agile has become a buzzword thrown around the industry rather carelessly, accumulating new connotations and misconceptions.

We're here to debunk 5 common myths about Agile and highlight the impact this mythical thinking has had on Agile projects and teams. Here's what they are:

• Agile teams don't track time
• You can do Scrum without Agile
• Using Story Points makes you Agile
• Agile is for IT and developers
• Agile is a mindset/methodology

Myth #1:Agile teams don't track time

​Time tracking, specifically project and task tracking, is deemed "anti-Agile" by many, including Agile project managers and Scrum masters. Their argument is that once you've made the transition from hours to Story Points (SP), tracking time is not only useless but detrimental to the Agile mindset (assuming it's a mindset to begin with – more on that later).

There are pros and cons to Agile time tracking but upon closer examination it's obvious that the pros outweigh the cons, provided you can organize your time tracking process effectively. The reality of many Agile teams is that they work in a larger corporate context and for external (taxes, billing) as well as internal (project management, utilization, resource allocation) reasons they track time on tasks and benchmark hours to Story Points.

When Agile project teams adopt an "anti-time tracking" policy they miss out on crucial insights mentioned above:

• Resource planning
• Team utilization
• SP to hour ratio

One thing that is true about Agile and time tracking is that the latter is never at the center of an Agile process. However, it doesn't mean that timelines or time tracking is "anti-Agile". They can and do go hand in hand.

Myth #2:You can do Scrum without Agile

Adopting Scrum without Agile practices is all too common and extremely detrimental to Agile projects. "We work with Scrum so we can do twice as much work in half the time" is an attitude incompatible with agility.

After all, Scrum is a framework within Agile; its core purpose is to help teams achieve agility. You can't skip Agile practices and only implement Scrum, especially not in a team of inexperienced developers whose project managers want to improve utilization and, quite simply, get more work done in less time.

Teams new to Agile may use Scrum for progress updates but never for highlighting challenges, roadblocks, and other things that impact other departments. This kind of reductionist misunderstanding of Scrum leads to reduced agility and poor project management.

One could argue that there's no agility to speak of when project teams working with Scrum lack an understanding of technical Agile practices. It's not enough to have Scrum to be able to boast agility. 

Myth #3:Using Story Points makes you Agile

Story Points is a trademark of Agile, which makes it bait for inexperienced teams wanting to seem "more Agile". User SPs is just one tool and its implementation does not make you Agile. Nor do daily stand-ups, sprints, or retrospectives.

A situation all too common is teams claiming agility and yet having their daily stand-ups exceed the 15-minute timeframe well into an hour. The same can be said about sprint creep. By only adopting a select few of the Agile tools "on paper" but failing to implement actual Agile practices, teams perpetuate a cycle of inefficiency and a lack of trust in the Agile process.

Using SPs does not make you Agile. What is more, you can do Agile without Story Points. No one isolated Agile practice suffices to guarantee agility. The least wannabe Agile teams can do is avoid meeting and sprint creep and make sure their daily stand-ups in fact last 15 minutes. 

Myth #4:Agile is for IT and developers

​To say that Agile is for IT or for software developers only is to miss the point of Agile completely. While it's true that Agile is not a one-fits-all answer to all use cases under the sun, its application extends far beyond software development in IT companies. Just to name a few "non-traditional" applications of Agile:

• Marketing
• Human resources
• Banking
• Manufacturing
• Education

Rather than focusing on applying Scrum, non-IT teams implementing Agile strive for better organization and autonomy. After all, Agile is a version of Lean, which itself is a version of Toyota Production System with applications far beyond the organization of work life.

The fact that Agile is "withheld" from non-IT projects means a lot of teams are missing out on its benefits. The truth is that when stripped of the IT and development slang, the 12 Agile principles and tools like retros and stand-ups would enhance the work of any team and advance any project, be it education, HR, or banking.

Myth #5:It's a mindset

Picking up on the previous myth, thinking of Agile as "a mindset for developers" is a grave misconception. Treating Agile as a mindset is how some people start viewing it as a tool that automatically reduces friction, solves interpersonal problems, and makes everyone feel good.

Some would argue that Agile viewed as a methodology is a myth in and of itself. The argument here is that the rigidity that comes with treating Agile as a methodology is contradictory to the flexibility of Agile. Agile is neither a mindset nor a methodology, it's an organization's strive toward agility.

Viewing Agile as a mindset is expecting it to work by itself, without changing the larger rigid organizational structures or adopting the entirety of the 12 Agile principles. Agile does not solve interpersonal problems or work by itself. Only full commitment to agility can produce Agile projects. 

Wrapping up

Being a big industry buzzword, Agile breeds mystery and ambiguity, especially when implemented without a complete understanding of its principles or in isolation from an anti-Agile larger context.

In this article, we reviewed the 5 biggest misconceptions about Agile and the impact these misconceptions have on projects. There will always be more to say about Agile as new myths emerge but for now look out for the 5 described in this article to make sure you're not doing more harm than good to your Agile projects.