Agile misconceptions and 'fake news'
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 (newer/popular ones are in bold).
"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)
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, 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.
'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. Don' t try and solve the problem of poorly run projects by decreeing that the concept of a project should no longer exists.
Remember Duck Theory - 'if it looks like a duck, swims like a duck and quacks like a duck - it's a duck!'. In the same way, 'if it looks like a project, feels like a project and sounds like a project - it's a project!'
Projects are only 'output' focussed if they are badly set up and badly run. A good project and a good project manager will be outcome and benefit focussed. 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.
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.
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)
Although the creators of the Agile Manifesto value 'responding to change' - they haven't changed it in 17 years!
There is a big difference between a 'Kanban board' and 'Kanban'. It is similar to the difference between an apple and an orchard.
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!).
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 consultancy 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!
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.
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 involved 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. (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!
The primary purpose of a stand-up meeting is about understanding progress and planning accordingly. It is not about 'communicating'. With this in mind - they should usually take 10 minutes at most.
"If the kids (or team) are united (or empowered), they will never be divided (unlikely to let you down)". (with thanks to Steve Langan, Aztecha)
See also: https://agilekrc.com/blog/185/can-agile-learn-something-sham-69
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'.
Testing and testers
Testing suffers more than anything else when a project overheats. This is because everyone else has overrun and the testers have to pick up the pieces and do their work in half the time.
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
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'.
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.
Agile is more about 'converging on an accurate solution' than 'getting it right first time' (with help from Dean Wrigley, MHR)
Don't eat soup with a fork
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).
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'. It needs boring things need to be done like documentation, following a process and having 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. (1) it isn’t – you also need to do boring things like follow a process, do documentation and understand who is doing what. (2) There is no common agreement on what that mindset actually is!
Collaboration and Empowerment
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.
The 'waterfall approach'
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'! It 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.
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'?
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!
Do you have any agile 'fake news'?
If you do, send it in an email to: firstname.lastname@example.org - thanks!