The top 10 myths about agile development

Agile myths

As with any framework or method, myths and misunderstandings can gain credence and become common knowledge over time.

Myth 1 – Agile is new

Agile is certainly not new. Agile methods have been around for a long time. The frameworks that are now known collectively as agile mainly evolved in the late 1980s and 1990s, which means agile is mature and an approach that is inherently familiar to many people. 

In essence, agile is all about enabling inspection and adaptation in dynamic environments where variability is experienced. This is a founding principle of, for example, evolutionary theory. It is also the way human beings interact with the world on a day-to-day basis – indeed it is the only way human beings can interact effectively in a complicated and complex world.

Myth 2 – Implementing agile is easy

It is usually not easy to change a complex systems delivery lifecycle to a simple one. Organisations normally find it easier to make things more complex than to simplify them.

Sadly, what happens in some organisations is that they try to implement an agile operating model or a single agile framework “by the book” and without understanding 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 organisations inevitably fail to achieve the 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!

Myth 3 – Agile gives instant benefit

While a transformation to agile can deliver huge benefits, the reality is that the majority of transformations go through a learning curve. While people and organisations are learning, the delivery capability can actually go downwards before it makes the step-change upwards and begins to achieve the improved delivery capability.

Myth 4 – Agile means no documentation

This myth most likely stems from a misinterpretation of the Agile Manifesto, where it states: “We value working software over comprehensive documentation”. It is important to understand that the manifesto does not say that documentation is not required, it says the focus is on producing working software instead of spending exhaustive amounts of time creating detailed documentation up front.

All effective agile deliveries should allow for and produce focused, value-driven, business-beneficial documentation that enables the business to use the product effectively and the technical team to support and maintain it. Failing to produce appropriate documentation would be a classic example of technical debt.

Myth 5 – Agile means “hacking” code together with little thought of architecture or design

“Hacking” in agile means cobbling together an IT system with little or no design or architectural thinking.

The Agile Manifesto states that “continuous attention to technical excellence and good design enhances agility”, and many agile frameworks provide the tools and techniques for the team to produce very high-quality code. For example, in extreme programming, many practices are aimed specifically at ensuring that the quality of the product being delivered is fit for purpose.

Myth 6 – Agile is a silver bullet

Agile is not the answer to all IT problems. There is no single answer to all IT problems, rather it’s about integrating different frameworks each of which provides part of the answer. The implementation of delivery and management frameworks such as agile must be pragmatic. It must recognise the real-world environment in which a system will be implemented and used, and consider the best integration of agile and non-agile frameworks that will work in that real-world environment. There is no single silver bullet framework.

Myth 7 – Agile: just read a book

Understanding agile is not something that can be achieved by simply reading a book. It is a very good idea to select some of the agile books from the leading agile exponents and read those (many recommendations are made in the BCS/Radtac Agile Foundations book), but just reading a book cannot replace the practical experience that is essential to enabling an agile mindset and successfully transforming an organisation or team to become agile.

Myth 8 – Agile only relates to software delivery

It is true that the Agile Manifesto describes agile in the context of software delivery, but agile can be applied successfully in business environments that are not exclusively software-related. In essence, agile is suited to any dynamic business environment that experiences variability, such as marketing or business change.

Myth 9 – Agile should replace everything all at once in a big bang transformation

When agile is applied in a big-bang approach across large projects, programmes or across the entire organisation, there is a significant risk that the benefits of an agile operating model will not be realised or understood. Often the organisation and its staff will simply continue to do things as they have always done them while pretending – or believing – that they have moved to an agile method.

Transforming capability is a long-term process of learning and change. Businesses evolve and so does the best way to do business. It is therefore a mistake to implement a big bang agile transformation and then just assume further improvement is no longer necessary.

There is an interesting quote, which is generally attributed to Albert Einstein, and referred to as Einstein’s definition of insanity: “Insanity is doing the same thing over and over and expecting a different result.”

This statement nicely sums up failed agile transformations where the organisation is still doing exactly what they have done previously (w’agile – waterfall pretending to be agile) and expecting added value even though they haven’t actually changed anything.

Myth 10 – Agile means no planning, just do it

The vast majority of agile frameworks involve frequent, regular and evolutionary planning. If a team is largely doing maintenance work or defect fixing, or there is no need for the customer to look any further than a couple of weeks when creating a product, they will probably only be planning in single iterations/sprints.

If the customer does need to know roughly what product will be delivered in what timescale and at what cost, the team may be planning in releases containing iterations/sprints.

If there are release plans, a high-level agreement will be in place of what product is being delivered, and at what timescale and cost. However, the agreement and the plans are specifically set up to enable change, and there will be significant regular ongoing planning.

If the customer needs to get an understanding of the total baseline definition of a product in a baseline time and cost, this could be delivered in multiple releases or an agile project. If an agile project is initiated, then high-level baseline definitions of the product and plans will be required. However, these are purposefully left at a high level as it is assumed that things will change as more is understood about the product.

Agile isn’t “just do it” – there is significant planning and re-planning involved when required.

As you can see, these 10 common myths can cause significant blockers for anyone trying to implement agile in their company. But as long as you recognise this by keeping the above information in mind, your chances of getting better results with agile will significantly improve.

If you liked what you read, feel free to engage with the topic by leaving a comment. Are you using agile practices or planning to use them? Did you bump into any of the myths above?

Peter Measey has more than 30 years’ experience in the computing sector and has specialised in agile since 1994. He is CEO of Radtac Ltd, an agile specialist consultancy and training organisation.