Rotate your device for best experience from site.
Agile Basics

Top 30 common misconceptions about Agile

by agilekrc
Learn the truth about Agile - dispel the myths and enhance your knowledge today by reading the full article.
Copied!
SHARE
Agile myths

Introduction

Over the many years I have spent delivering agile training and consulting, I have been surprised at the number of common misconceptions about agile that have become so prevalent. These misconceptions and myths about Agile have become so common that they have become established in many people’s minds as established ‘facts’. It’s where agile myths and misconceptions become more akin to being ‘fake news’.

So, what are the most common misconceptions about Agile?

In this article I have listed over 30 common misconceptions about Agile that it is worth listing in the hope I can debunk the many ‘falsehoods’.

Common misconception about Agile #1.

A vision isn’t needed.

“Responding to change” doesn’t mean you work out the vision after you have started.

Avoid the Tigger approach to Agile! (From Winnie the Pooh, allegedly)

Piglet: “Where are we going?”

Tigger: “I don’t know, but we’re taking the shortest route!”. (With thanks to Niels Malotaux.)

When you encounter a serious problem on a project and you suddenly realise that you are in an awful lot of trouble – using a fancy phrase like ‘we need to pivot’, doesn’t make the situation any better or in any way desirable.

Common misconception about Agile #2.

The customer doesn’t know what they need.

It is hardly ever the case that ‘the customer doesn’t know what they want’. They do – they just don’t know EXACTLY what they want. And in the unlikely event that they really don’t know what they want, no one should be working on delivering it.

The customer typically changes their mind during a project because they don’t know ‘the detail’ at the start. It is not because they are crazy, weird or an idiot.

The best way for a customer and supplier to work in an agile way, is to share the risk that uncertainty brings. This is because the customer knows that they don’t know exactly what they want. The supplier also knows that the customer doesn’t know exactly what they want. The customer also knows that the supplier knows that, and the supplier knows that the customer knows that the supplier knows that too.

Common misconception about Agile #3.

A Scrum Master = a project manager.

OK this is a Scrum myth, but it makes the list!

A great way of checking the credibility of an agile coach is to ask them to explain the difference between and project manager and a Scrum Master. If they say that ‘they are basically the same thing’ – they have no credibility. If they describe one as better than the other – they have no credibility either.

Common misconception about Agile #4.

We don’t need projects.

‘Fewer projects’ – maybe. ‘No more projects’ – a lot of pain is on the way!

To solve the problem of poorly run projects, run projects well. Do not try to solve the problem of poorly run projects by decreeing that the concept of a project should no longer exist.

You will not solve the problem of poor project management by replacing it with Scrum. You need to replace it with good project management or agile project management.

Remember Duck Theory – ‘if it looks like a duck, swims like a duck and quacks like a duck – it is a duck’! In the same way, ‘if it looks like a project, feels like a project and sounds like a project – it is a project!’

Projects are only ‘output-focused’ if they are badly set up and badly run. A good project and a good project manager will be outcome AND benefit-focused. Perhaps the hashtag should be #nomoreBADprojects

If you are an agile consultant and you think that projects do not (or should not) exist, can I suggest the following. Whenever you start (or you are about to start) an engagement with a customer/client you immediately make it absolutely clear, that you think projects do not, or should not, exist.

The reason I say this is that you will then be in a ‘no lose’ situation. If the client is gullible, you will be able to make a lot of money from them and if they are not, you will save both of you, a lot of time.

Common misconception about Agile #5.

Documentation isn’t needed.

If you are using Agile you still need documentation. It may be lighter, and it may be more informal – but you still need it.

If you meet someone who says, “agile means no documentation”, make sure that they are not working on anything important. Even better, make sure they are not working for your organisation.

Common misconception about Agile #6.

We don’t need a plan.

“Responding to change over following a plan”, doesn’t mean you shouldn’t have a plan! (with thanks to Dean Wrigley, MHR.)

Although the creators of the Agile Manifesto value ‘responding to change’ – they haven’t changed it in over 20 years!

Saying you are ‘agile agnostic’ is a bit like saying that you are ‘cutlery agnostic’. It is pointless saying it because it is 100% obvious!

Sorry to be a ‘mood hoover’ but it is pointless saying to people that they should be ‘agile agnostic’. It is like saying you should be ‘cutlery agnostic’. It is good advice, but does someone really need to tell you that?

Common misconception about Agile #7.

Kanban and Kanban board are the same.

There is a big difference between a ‘Kanban board’ and ‘Kanban’. It is similar to the difference between an apple and an orchard.

Common misconception about Agile #8.

Lean startup is about value.

An MVP (Minimum Viable Product) is primarily about ‘learning’ and not about ‘revenue’.

Common misconception about Agile #9.

We only deliver ‘Musts’.

When using MoSCoW prioritization technique, under normal circumstances, if a team only completes the Must Haves in a timebox – there is no cause for a celebration. This is called ‘turning up for work’.

Saying ‘it is a Must have’, is only half a sentence. To make it a complete sentence, you need to include a ‘when by’.

A correctly run agile project will never do all the ‘Must haves’ first. If you are shopping in a supermarket, you don’t buy all the ‘Must Haves’ first, either.

A ‘Should have’ should be delivered. That is why it is called a ‘Should’.

They are NEVER all “Must haves”. (Well, I have never seen a genuine case in 20 years!)

Common misconception about Agile #10.

We don’t need a PMO.

A well-run PMO can add a lot of value where you are running projects in an agile context.

When a highly paid consultant from one of the large consulting companies says, ‘Agile can reduce your headcount because you no longer need a PMO’. Get them out of the building as soon as you can.

Do you think that running your projects with agile means that you can save money because you no longer need a PMO? What this actually means, is that you don’t know what Agile is, and you don’t know what a PMO does either!

Common misconception about Agile #11.

PRINCE2 is waterfall.

PRINCE2 is a project management framework that can be configured to support an ‘agile way of working’ or a ‘waterfall way of working’.

PRINCE2 is not a ‘waterfall approach’ to project management.

There are two types of project manager. There are those who think PRINCE2 is a ‘waterfall approach’ and there are those who know it isn’t.

There are two types of people who work on projects. There are those who think PRINCE2 is a ‘waterfall approach’ and there are those who know it isn’t.

There are two types of people who work on projects. There are those who think sushi is raw fish and there are those who know it isn’t.

Common misconception about Agile #12.

Programmes can be agile.

There are no such things as ‘agile programmes’ or ‘agile programme management’. The correct terms to use are ‘programmes’ and ‘programme management’.

…unless, of course, you are managing a programme whilst balancing on one foot in front of a wind machine.

Common misconception about Agile #13.

Projects start with a backlog.

On a project, you may at some point have a ‘backlog’ – but you never ‘start with a backlog’.

On a project, if the four constraints (deadline, budget, quality level and scope/requirements) are all fixed, you will get a winner and a loser because all projects have a degree of uncertainty.

Alternatively, you can share the risk (between the customer and the supplier) by agreeing which constraint can be varied. When using Agile, the variable will usually be the scope/requirements.

A project that creates a ‘replacement’ is fine, a project that is a ‘rewrite’ is not.

If you are involved in a ‘rewrite project’ you are in a bad place. You need to treat it as a ‘replacement project’.

There are two types of people in the agile community. There are those who think project management is about waterfall thinking, bureaucracy and ‘command and control’. And there are those who know it isn’t.

Common misconception about Agile #14.

Scaled agile frameworks are better than Scrum.

If you think scaled agile frameworks are better than Scrum – it means you don’t understand either of them.

Before you implement scaled agile, it is a good idea to get Scrum to work first.

Common misconception about Agile #15.

Scrum can be used to manage projects.

OK, this is another myth about Scrum, but it is still in my list!

Scrum is not an approach for managing projects. You can use Scrum ‘on’ a project, but you cannot ‘manage’ a project with Scrum.

If you meet anyone using the expression ‘Agile Scrum’, or (even worse) ‘Scrum Agile’, buy them a coffee, sit down with them and explain what they both are. Unless they are an agile consultant, coach or trainer – in which case, you need to make sure they are a long way away from your team and your organisation.

Saying, ‘Agile Scrum’, or (even worse) “Scrum Agile”, is a bit like saying, ‘athletics running’ or ‘running athletics’ – i.e. it makes no sense. (With help from Dave Smith.)

There isn’t a project manager role in Scrum. This is because Scrum it is not a project management framework.

The fact that there isn’t a role for a project manager in Scrum, does not mean that an organisation ‘going agile’, doesn’t need project managers anymore. (With thanks to David Tomlinson.)

If you happen to meet someone who has failed the Certified Scrum Master exam on the same day as you meet a unicorn – buy a lottery ticket – quick!

Common misconception about Agile #16.

We can have Scrum projects.

Any another Scrum myth!

If you are working on a ‘Scrum Project’, you may have a bit of a problem. No such thing exists!

Common misconception about Agile #17.

Stand-up meetings are about communicating.

The primary purpose of a stand-up meeting in Scrum is about understanding progress and planning accordingly. It is not about ‘communicating’. With this in mind – they should usually take 10 minutes at most.

Common misconception about Agile #18.

Empowered teams won’t let you down.

“If the kids (or team) are united (or empowered), they will never be divided (unlikely to let you down)”. Lyrics to “If the kids are united” by Sham 69, 1978. (With thanks to Steve Langan, Aztecha).

Note: for any readers unfamiliar with Sham 69, they were a UK punk rock band from the 1970s.

Common misconception about Agile #19.

Story points equate to time.

It is OK to say, ‘I think this story has a value of 5 story points’. It is not OK to say, ‘I think this story will take 2 days and that equates to 5 story points’.

Common misconception about Agile #20.

Testers don’t suffer when things go wrong.

Testing suffers more than anything else when a project overheats. This is because everyone else has overrun and the testers are left to pick up the pieces and do their work in half the time.

Common misconception about Agile #21.

Running sprints and having stand-ups means you are Agile.

If you are running sprints and having stand-ups, this does not mean you are Agile. It means you are running sprints and having stand-ups.

Common misconception about Agile #22.

Agile is quick.

If you think an agile project is about being quicker, or faster, …you are in for a very nasty shock.

Agile is not about ‘pace’ – it is about ‘sustainable pace’.

Agile is about ‘being on time’ and ‘hitting deadlines’ – it is not about ‘speed’ and being ‘fast and furious’.

Agile is only ‘quick and dirty’ when you do it quickly.

Agile is something you use or adopt. It is not something that ‘does things to you’.

Common misconception about Agile #23.

Control is bad.

Agile is not about less control. It is about staying in control.

The Eurofighter Typhoon is an incredibly agile aircraft. It does not achieve this agility through a lack of control or a lack of governance.

For all the ‘pink and fluffy’ Agilistas out there who have a hatred for the word ‘control’. Control is a good word; a positive word and it is a nice thing to have. …and far better than ‘out of control’.

Common misconception about Agile #24.

Agile gets it right first time.

Agile is more about ‘converging on an accurate solution’ than ‘getting it right first time’. (With help from Dean Wrigley, MHR.)

Common misconception about Agile #25.

Agile gives you twice as much.

Agile does not give you ‘twice as much, in half the time’. The only thing you get in half the time is half of what you want.

A 6-month agile project takes about 6 months (not three).

Common misconception about Agile #26.

Agile is just a mindset.

Many people think that agile is ‘just a mindset’. The mindset is important (and is more important than anything else), but successful agile needs more than ‘just a mindset’.

Agile needs boring things like documentation to be done. It needs a process to be followed and it needs clear roles and responsibilities.

‘Happy clappy’ only gets you so far – in fact, ‘happy clappy’ on its own is most likely to lead to failure.

If you think ‘Agile is JUST a mindset or attitude’ – you have two big problems. One, it isn’t. You also need to do boring things like follow a process, write documentation, and understand who is doing what. Second, there is no common agreement on what that mindset actually is!

Common misconception about Agile #27.

Collaboration and empowerment are only for Agile.

These are essential ingredients for agile, but it wasn’t invented by the agile community.

If you are empowered and working collaboratively, it does not mean you are agile. It means you are empowered and working collaboratively.

Common misconception about Agile #28.

The ‘waterfall approach’ is bad.

A well-run waterfall project is far better than a badly run agile project.

The waterfall approach was not created by devil worshipers or someone ‘trying to win a bet’!

The waterfall approach has its place and can be a better option than using agile in many situations. A limitation of the waterfall approach is that it can be slow to deliver initially. However, this limitation is minor compared to the limitation of a badly run agile project which can quickly deliver a disaster.

Common misconception about Agile #29.

Scrum means Agile.

My last Scrum myth before finishing!

Scrum is not the same as Agile. Scrum is just one approach, but not THE Agile approach. We have dozens of Agile approaches, methods, frameworks – Scrum, Kanban, Lean Startup, XP, the list goes on. They are all Agile in their own ways. If Agile were vegetables, Scrum, Kanban and XP might be potatoes, carrots, and onions!

Common misconception about Agile #30.

Liking an Agile myth on LinkedIn shows you truly understand Agile.

Just remember, when you decide to ‘like’ any of the agile myths and falsehoods on places such as LinkedIn. You had better hope your boss is equally naive or doesn’t see it, because you will not be doing yourself any favours!

Learn from agile leaders

agileKRC has helped shape agile thinking by leading the teams that developed AgilePM® and PRINCE2 Agile®. We take a practical, success-oriented approach. We begin by taking the time to listen and understand your needs, before offering our real-world experience and expert guidance.

This website use cookies. Learn more