Agile misconceptions. Just saying...

Keith Richards
3 Jun 2018
Agile
AgilePM/DSDM
General
Governance
PRINCE2 Agile

Agile misconceptions

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 ones in bold)..

'The Customer'

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.

Documentation

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)

Kanban

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

Lean Startup

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

MoSCoW Prioritisation

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

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.

Programmes

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.

Projects

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'.

SAFe

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

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)

Sham 69

"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

Story Points

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.

Agile Techniques

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 a incredibly agile aircraft. It does not achieve this agility through a lack of control or a lack of governance.

Agiile is more about 'converging on an accurate solution' than 'getting it right first time' (with help from Dean Wrigley, MHR)

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.

Words

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:  enquiries@agilekrc.com - thanks!