beckmarkwith - Fotolia

The top 10 myths about agile development

Examining some of the most common misconceptions in the growing field of agile software development

This Article Covers

Management skills

RELATED TOPICS

To be flexible has become vital for a business in today’s global markets, and therefore, the ability for IT systems to be equally flexible is essential. The purpose of agile is to allow organisations to react to the increasingly dynamic opportunities and challenges of today’s business world, in which IT has become one of the key enablers.

Agile is defined by four values and 12 principles found in the Agile Manifesto. The manifesto provides an umbrella definition, in which there are many other delivery and governance frameworks, such as Scrum or extreme programming, for example.

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!

Download a chapter from Peter Measey's book, Agile Foundations

Peter Measey explains the key principles of the Agile Manifesto in this extract from his book, Agile Foundations.

Computer Weekly readers can use promotion code CWB3 to get 20% discount from the BCS shop.

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?

Agile research findings

Is agile important and relevant in today’s IT world?

In research by Computer Weekly and TechTarget, 46% of IT professionals predicted their 2015 budget would increase compared with 2014, with 40% of that increase expected to be staff-related.

Agile topped the list of software development-related activities planned in 2015 for 38% of respondents.

Separate research by VersionOne showed the top three benefits of adopting agile have remained the same for the past four years. These are managing change priorities, for 87% of this year's respondents; increased team productivity, for 84%; and project visibility, for 82% of respondents.

What causes agile to fail and what are the barriers to agile adoption?

The top causes of failure are lack of experience with agile methods (44%), company culture/philosophy at odds with agile (42%) and lack of management support (38%).

The top barriers to success are the ability to change culture (44%), not enough personnel with agile experience (35%) and organisational resistance to change (44%).

How many organisations use agile?

Some 94% of all organisations surveyed by VersionOne now practice agile. Approximately 24% of respondents to the latest research worked in organisations that have practiced agile for greater than five years, up from 19% in 2013.

In 2013, the majority of respondents had fewer than 1,000 people in their software organisation. In 2014, however, approximately 35% of respondents had more than 5,000 people in their organisation, and 20% worked in very large organisations with more than 20,000 people.

In addition, 45% of the 2014 respondents worked in development organisations where the majority of their teams are agile. Contrast this with the 2009 report, which found that 31% of the respondents worked in organisations with only zero to two teams practicing agile. 

Agile is spreading geographically, too. From 2012 to 2014, the percentage of respondents who had distributed teams practicing agile jumped from 35% to 80%.

Sources: Computer Weekly/TechTarget 2015 IT priorities survey (UK). VersionOne’s ninth Annual state of agile survey 2015 (study conducted between July and October 2014, 3,925 people analysed)

 


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.

This was last published in June 2015

CW+

Features

Enjoy the benefits of CW+ membership, learn more and join.

Read more on IT management skills

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

These reasonable balanced to me. I've seen most of these problems at organizations. One thing I would suggest is yes, actually do read books. Most people don't read the book, they pick up the "gist" from a website, or attend a training and just hear one instructors opinion. Yes, coaching is good, yes, deep dives and training are good - but for many people, reading a book is an improvement!
Cancel
Reading a book is definitely a good start, I agree. Bringing in an agile coach, in my opinion, would be the ideal way to go if at all possible. It really helped our team.

Our agile process has been slowly evolving for years. We've arrived at the point of having a pretty mature process now, but we do still struggle at times with the design/architecture bit. Sometimes, it makes sense to have the entire team sit down and at least get a high level idea of a design for a new system. It really helps with a lot of questions and confusion that can otherwise come up down the road.
Cancel
The problem is there are so many BAD books, just like there are so many companies implementing Agile practices poorly.  Too many times Agile gets blamed for why projects slip, when in reality they aren't Agile at all.
Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close