What sometimes gets lost or at least confused is the notion that ‘Agile’ is at its core it is a form of project management, a style of planning. One of the main benefits of Agile is that it is restrictive and limiting. It forces focus and prioritisation and it limits work in progress, it mandates reflection and improvement. Doesn’t sound very Agile at all does it? Terms like “Limits”, “Mandates”, “Restricts”, “Imposes” are commonly used in most Agile Frameworks. But in comparison to most of the traditional planning frameworks it is a very flexible way of planning a project. But the flexibility is controlled and structured – the Agility refers to the plan, not to the framework.

Far too often it is misinterpreted – (probably deliberately) as being an excuse not to plan, an excuse not to limit work and an excuse for not prioritising. How often have you read in forums or heard people complain that not being able to change direction during a Sprint is not Agile, or that “we are too Agile for Scrum”, “we can’t predict what our priorities will be for the next iteration”.  But before you can have an Agile plan you must first have A plan.

The term Agile is too often used as an excuse not to plan, it’s success and popularity have meant that the term is commonly used and often by those that don’t know what it means but are looking for a ‘framework’ to justify their disorganisation, their failure to plan or as an excuse for cutting corners.

My experience is that Agile is not about reducing work, or about reducing control, it is the opposite. Adoption of Agile methodologies does not reduce work, it focuses you on doing the most important work first, and to do that work to a defined and consistent quality standard. It imposes control and restrictions, there are rules in all of the frameworks, many of them rigid, or at least have a significant cost to unplanned change.

Anyone that thinks adopting Agile will be easy, or that adopting Agile means they don’t have to plan, or document or design or prioritise, has missed the point entirely.

If your organisation is too busy to plan, doesn’t impose quality standards, and flits from one task to the next often without completing the current task or project, simply reacting to the immediate crisis – and there are many departments and organisations like this – then Agile will look very inflexible and restricting, it may feel far less agile when first transitioning to an Agile Framework. But ironically organisations like these where there is little or no planning are probably more in need than those following traditional planning methodologies.

The archer must know what he is seeking to hit; then he must aim and control the weapon by his skill. Our plans miscarry because they have no aim. When a man does not know what harbour he is making for, no wind is the right wind.
Seneca

Seneca uses two analogies there that I find extremely useful conceptually for describing the importance of planning. The first is the Archer, when planning a shot an archer needs to know his target, and he needs to understand his environment and then he pulls together skill, experience and focus to make that shot, if he is interrupted before the shot is made it is likely wasted effort.

Similarly for a ship, if it makes for one harbour one day because the wind is favourable and then another the next day, the ship could be zigzagging all over the place without ever reaching any harbour. Or possibly if the harbour is chosen because of the wind, it is likely not the desired destination, just an easy one. Neither alternative gets results, although in each case the ship is likely making good speed. Rather like many project plans where we feel satisfied if everyone is busy even if we are not actually completing anything.