Over the years of working in the agile arena, I have been surprised at the number of misconceptions that become so prevalent that they more or less become facts, whereas they are more akin to being 'fake news'.
Here are just a few statements that are true and are intended to correct those misconceptions.
The Agile Manifesto
"Responding to change over following a plan", doesn't mean you shouldn't have a plan! (with thanks to Dean Wrigley, MHR)
It is hardly ever the case that 'the customer doesn't know what they want'. They do - they just dont 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 becasue 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, and the supplier also knows that the customer doesn’t know exactly what they want, and the customer knows that the supplier knows that, and the supplier knows that the customer knows that the supplier knows that too.
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 anyone who says, 'Agile means no documentation!'. Make sure they are not working for your organisation.
An MVP (Minimum Viable Product) is primarily about ‘learning’ and not about ‘revenue’.
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's a MUST", 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 of the 'Must Haves' first. If you are shopping in a supermarket, you don't buy all of 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!).
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.
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.
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.
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 of, the deadline, the budget, the quality level and the 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 invloved in a 'rewrite project' you are in a bad place. You need to treat it as a 'replacement project'.
If you think SAFe is better than Scrum - it means you don't understand either of them.
Before you implement SAFe, it is a good idea to get Scrum to work first.
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.
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'.
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.
Agile in General
Agile is something you use or adopt. It is not something that does things to you.
Agile is not about less control. It is about staying in control.
For all of the 'pink and fluffy' agailistas 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. ...or do you prefer 'out of control'?
Do you have any agile 'fake news'?
If you do, send it in an email to: firstname.lastname@example.org - thanks!