Debunking Agile: 8 Top Myths
Every organization should be flexible in today’s global market, and thus, the importance of IT systems to be flexible is critical. Agile methodology provides tools for organizations to face the challenges of today’s business world successfully, in which IT has become one of the key aspects.
Agile approach is defined clearly by the principles from the Agile Manifesto. The manifesto provides a global definition, in which there are many other delivery and management frameworks, such as Scrum or Kanban, for example. In this article we’ll expose some myths about the agile approach.
1) Agile is a new method.
That’s not true. Agile methods exist around for a long time. The methods that are now well known as agile mainly appeared in the late 1980s and 1990s, which means agile is mature and very familiar to many people.
Also, agile is all about enabling control and management in dynamic environments where variability is present. This is a basic principle of, for example, evolutionary theory. It is also the way human beings interact with the world almost every day – and it is the only way human beings can interact effectively in a complicated and complex world.
2) Agile will give you quick progress.
The introduction of agile approach can bring you large benefits, but in reality – the majority of transformations will go step by step. As people and organizations are adopting the method slowly, the delivery capability could actually decrease, before it makes the step-change upwards and begins to achieve the expected progress (performance).
3) Agile is easy to implement.
Organizations normally find it easier to make things more complex than to simplify them. Sadly, what happens in some organizations is that they try to implement an agile operating model or a single agile framework “by the book” and without understanding of the transformational complexity. Therefore, they either fail to implement agile, or they do achieve some success but at significantly higher cost and pain than they would have done if they had managed the transformation more effectively.
Such organizations inevitably fail to achieve true benefits of agile. You can theoretically learn to fly a plane by reading a book, but don’t expect me to sit next to you on your first take-off!
4) In Agile you need no documentation.
This myth probably originated from a misunderstanding of the Agile Manifesto, where it states: “Working software is more important than complete documentation”. You should notice that the manifesto does not say that documentation is not required; it says the focus is on the delivery of working software instead of spending large amounts of time creating detailed documentation up front.
Efficient agile approaches will allow to produce clear, value-driven, business-improving documentation that will provide the organization to use the product effectively, and the technical team to support and maintain it. If you don’t create appropriate documentation – you will face many technical debts in future.
5) Agile means only coding, without architecture or design.
Direct coding in agile means to assemble together an IT system with little or no design or architectural thinking.
The Agile Manifesto says that “permanent attention to technical excellence and good design upgrades the agility”, and many agile frameworks provide the tools and techniques for the team to deliver a very high-quality code. E.g., in extreme programming, some practices are dedicated to ensure that the quality of the product being delivered is as per client requirements.
6) Implement Agile as in the books.
Understanding agile approach is not a straight-forward thing, that can be done by simply reading a textbook. It is a good idea to get some of the agile books from the top agile authors and read them, but just reading a book cannot replace practical experience that is essential to enabling an agile behavior and successfully transforming an organisation (or team) to become agile.
7) Agile only means software development.
The fact is that the Agile Manifesto describes agile in the context of software production, but agile can be applied successfully in business environments that are not only software-related. In reality, agile method is suitable for all dynamic business environments that encounter changes, such as marketing or business switch.
8) You can start Agile with no planning.
Large number of agile methods require frequent, regular and evolutionary planning. If the team does the maintenance work or defect repairs frequently, or there is no need for the client to look any further than a couple of weeks when creating a product, the agile team will probably plan its work in single iterations/sprints.
When the client needs to understand the total baseline definition of the product in a baseline time and cost, this could be delivered in multiple releases, or in an agile project. If an agile project is started, then global definitions of the product baseline and plans will be needed. However, these are intentionally left at a high level, since it is assumed that things will change – as more is uncovered about the product.