What Does Anti-Agile Mean?

The majority, if not all, of the people reading this will be working in agile teams. That will mean different things in different organisations but that isn't necessarily a problem.

Agile isn't one size fits all, a drastic over simplification of agile might be "try things, do what works".

But when does something become anti-agile? When does it actually stop us from achieving our goals?

Interrupting the Flow

An important aspect of agile is effective and on-going communication, with the most valuable form of which being face to face.

Something is anti-agile if it gets in the way of people just talking and figuring stuff out.

This can come in many forms, poor division of work and resources causing constant blockages by being reliant on others who are siloed with there own problems.

By having a needless hierarchy creating ineffective lines of communication where the people who can work through problems are communicating via proxies.

An agile mentality assumes that if smart people are given the time and room to work with each other they will produce results, this process cannot be forced or controlled it just requires trust.

Build Something

Some other processes place a large importance on having a plan, its a misconception of agile that it doesn't involve a plan.

Agile does involve a plan, the difference is the scope, we don't plan to take over the world we just plan to make a start towards doing it. We realise that users can't use plans but they can use the things we build.

Anything that gets in the way of building something is anti-agile. This is nearly always caused by a fear of the unknown, how do we know this is the right answer?

The truth we have to swallow is your never going to know in advance that your doing the right thing, you cannot plan to succeed you can only plan to have your best stab at it.

Users tell you if you doing the right thing and they do that based on the product you put into their hands not based on the plan of what you intend to one day give them.

Listen Don't Tell

In a similar vain your best chance of succeeding is when you listen to what people want.

Users will tell you what they want, users aren't always right and sometimes you will need to persuade them that your idea is a good one but you won't be able to do that effectively and you want be able to adapt if you don't understand where your users are coming from.

Developers will tell you how they can best work effectively, they are the ones who have to make your vision a reality, if you don't trust them to know how to do that you've put together the wrong team, you need to succeed because of your team not in spite of them.

Its anti-agile to assume you have all the answers, an agile team will embrace their ignorance and see it as an opportunity to learn, to find out what people want and deliver it.

Flex Don't Snap

The theme running through these points is the need to be flexible, with agile the clue is in the name.

Questions can be hard to define, answers can be wrong, people can make mistakes. You can either spend a long time following a clearly defined plan moving slowly towards failure or you can accept the fact that there will be rough seas that require changes in direction.

Something is anti-agile if it prevents you from implementing change when you know its the right thing to do.

It sounds crazy to think that a team could know they are doing the wrong thing but carry on anyway, but it happens all the time when that team is operating in an environment that isn't agile.

Either the people that know this is wrong aren't communicating, your not finding out from the user if they want what your doing or your machine is so big that it simply cannot change direction.

You can't be told how your team can work in an agile manner, you have to figure that out for yourself, but there are guidelines you can follow.

You'll find your own way you just need to be able to recognise when your heading in an anti-agile direction and hit reverse.