Agile is no joke

Agile methods are sometimes perceived as something less serious than the alternatives. Especially by those who have very little experience in using them. A vague understanding of early texts on agile methods such as "The Agile Manifesto" leads people to think that it is all about ditching methods, tools, documentations, contracts, and plans, and nothing more. An unstructured dream for the immature, a nightmare for the rest of us.

But it couldn't be further from the truth.

Emphasis on using structured tools that support changing circumstances comes from hard evidence showing us that it is impossible to create strict plans for product development and expect them to hold. Predictability is not an option, regardless of the method used. Therefore we use methods for planning and forecasting that takes variability into account. Inherent variability doesn't go away by pretending that it doesn't exist. Instead: ignoring it exposes you to a tremendous risk, as available data on expensive IT failures show us.

Building the capability to handle variation in plans caused by unforeseen events gives us the benefit of being able to handle actual changing requirements continuously, even late in the process. While changing requirements could be a side-effect of an organization that doesn't understand what they need, it is more often caused by the growing body of facts about the problem and its possible solutions.

We all know that our body of knowledge about the situation is small early in the process and larger as time goes on. All decisions should be made in the last responsible moment if we want them grounded in facts rather than guesses. By using methods for continuous risk management and prioritization based on optimizing for options, this discovery process becomes more painless than being forced to stick to misguided decisions made way too early.

With a method that can incorporate newly found insights on the needs of the users and the market, we increase the chance that what we build will be effective. Agility isn't about efficiently creating everything that random people in the organization ask for, but being precise in meeting the actual needs of the most valuable users. It is about quickly investigating large sections of the solution space and focus on the most beneficial ones, both cost and value wise. The number of changing requirements is not a negative KPI but a metric of increased knowledge.

In order to achieve this, we can never be in debt. Our product must be ready to meet the current reality. No waiting for tests, for more documentation, for productivity enhancing refactoring, or for improved usability. When we are done with a small increment (which we should be regularly) and have deployed it into production, we are done. Our product is usable. Ready to generate value. Our quality assurance strategy are therefore way better than in the older methods, or else we couldn't have this. Modern proven testing strategies and a lot of automation is at the core.

The way we make these things a reality is by extensive amounts of teamwork where organizational borders are crossed (or crushed) and lots of delegated mandates where the teams has a growing amount of decision making power. Delegation is not about letting things go, but about building capability for self-leadership and responsibility in the collaborations of the organizations.

All this isn't possible if we don't choose to use management principles grounded in modern psychological and mathematical science. The foundations for making these things work have been known since at least the 40s-50s, and today our knowledge in both psychology and systems thinking is way better. It is therefore no joke or hippie dogma when we ask management to update its principles on how value is measured or on how governance and leadership is supposed to be done in an organization.

Agile is no joke. It is for real, it is grounded in solid principles and hard evidence, and if you want it you need to really consider what it requires from you and your organization.