Let’s bust 6 common myths about Agile
Agile is a project management and product development approach that prioritizes flexibility, collaboration, and customer satisfaction. It emphasizes iterative and incremental development, allowing teams to adapt to changing requirements and deliver value in small, frequent releases.
As a methodology, it has become central to how Product works, but it’s also become one that’s pretty commonly misunderstood, used to justify some bad habits, or just altogether abused.
Before we take a whistle-stop tour through some of the biggest myths surrounding Agile… fancy a cheeky lil’ history lesson?
The humble origin of Agile
The Agile methodology and its associated frameworks, such as Scrum and Extreme Programming (XP), evolved in response to the challenges and limitations of traditional project management methodologies.
Its roots can be traced back to the 1970s and 1980s, with various influences contributing to its development. Let’s take a look at some of the key milestones that led up to Agile as we know it today…
🚀 Critiquing the traditional waterfall model (1970s): The traditional Waterfall model, which follows a linear and sequential approach to software development, faced criticism for its inflexibility in accommodating changes and responding to evolving customer needs. This led to the exploration of alternative approaches.
🚀 Iterative and incremental development (1980s): The idea of iterative and incremental development gained popularity as a response to the drawbacks of the Waterfall model. This approach emphasized breaking down the development process into smaller, manageable cycles, allowing for regular feedback and adjustments.
🚀 Dynamic systems development method (DSDM, 1994): DSDM was one of the early Agile frameworks and emphasized active user involvement, iterative development, and the importance of delivering a product quickly. It contributed to the principles that later became central to Agile methodologies.
🚀 SCRUM framework (mid-1990s): Jeff Sutherland and Ken Schwaber introduced the Scrum framework in the mid-1990s. Scrum is an Agile framework that emphasizes collaboration, flexibility, and delivering a potentially shippable product at the end of each iteration. It introduced roles like Scrum Master and Product Owner, and popularized the concept of sprints.
🚀 Extreme programming (XP, late 1990s): Kent Beck and his colleagues developed Extreme Programming, another Agile framework that focused on practices such as continuous integration, test-driven development (TDD), and pair programming. XP aimed to improve software quality and responsiveness to changing requirements.
🚀 Agile Manifesto (2001): The term “Agile” was officially coined in 2001 when a group of software developers met at Snowbird, Utah, to discuss lightweight development methods. The result was the Agile Manifesto, a set of guiding values and principles for Agile software development. The Agile Manifesto prioritizes individuals and interactions, working solutions, and customer collaboration over processes and tools.
The Agile Manifesto, with its four key values and twelve principles, laid the foundation for the Agile movement. Since then, various Agile methodologies and frameworks have been developed and refined, and Agile principles have been applied in a wide range of industries beyond software development.
So… how about those myths?
Now we’ve refreshed our knowledge about where Agile comes from, it’s time to go myth busting!
It’s not a specific set of tools or techniques.
Some people mistakenly think that Agile is a specific set of tools or techniques, for example, using a particular project management software may be considered “Agile”. I know before my first formal product role, I’d certainly heard people describe certain tools as being “Agile” — and for a brief period, I thought it was a feature on JIRA.
Really, Agile is a mindset and a set of principles and values outlined in the Agile Manifesto. While there are specific Agile methodologies and practices, Agile itself is not tied to any particular tool or technology.
It’s not an excuse for a lack of planning.
Some may interpret Agile as an approach that does not require planning, documentation, or a structured process. So, while Agile does indeed emphasize adaptive planning and responding to change over following a rigid plan, it does not mean there is no planning.
Agile planning is continuous and involves frequent reassessment and adjustment based on feedback and changing circumstances.
It’s not a silver bullet for all project challenges.
There’s a misconception that adopting Agile will magically solve all project-related issues and challenges. I’ve certainly worked with organizations who have adopted Agile, thinking it would fix all of their operational issues, only to be shocked when they realize that it’s not a remedy for these.
While Agile can bring about significant improvements, it’s clearly not a one-size-fits-all solution. The success of Agile depends on factors such as team collaboration, commitment to Agile principles, and organizational support. It’s not a guaranteed solution for every project or organization.
It’s not an excuse for a lack of documentation.
Some believe that Agile teams do not document their work or that documentation is not valued in Agile. And others simply don’t want to document in the first place because it’s a dull task.
While Agile values working software over comprehensive documentation, it does not mean that documentation is neglected. Agile encourages just enough documentation to support the development process, and it places more emphasis on communication and collaboration.
It’s not about rushing or sacrificing quality.
Agile is sometimes misunderstood as a methodology that prioritizes speed at the expense of quality. I remember one particularly stubborn, more experienced PM who told me exactly this, and it was only a few years later that I realized that the quality issue was a result of Agile being misunderstood and misused.
In reality, Agile promotes sustainable development and places a high value on delivering a potentially shippable product at the end of each iteration. This requires a focus on quality and the ability to maintain a consistent pace of work.
It’s not only for software development.
Agile is often associated exclusively with software development, and some believe it doesn’t apply to other industries or types of projects.
While Agile originated in the software development industry, its principles have been successfully applied in various fields, including marketing, finance, manufacturing, and more. Agile’s adaptability makes it suitable for a wide range of projects and industries. Indeed, I’ve used it in UX-facing roles with UX teams.
What are some Agile myths or misconceptions that you’ve come across in your career?
In the meantime, if you want to learn more about Agile and Product Management, check out my full introductory course “Product Management 101”, available from Tech Outcasts.
Follow me for more, and connect with me over on LinkedIn. 🪐
