Fundamental Principles of Agility

I think a lot about fundamental principles. I've found that a solid understanding of principles allows me to derive understanding of more complicated things.  Within the Agile community I hear a lot of talk about culture, methods, frameworks, and spirited discussions around #hashtags. But, rarely a straight forward discussion of fundamental principles.

To begin, when I speak of principles here I am not talking about the principles behind the Agile Manifesto. These are statements of values which help you know right and wrong and that influence your actions (e.g. a person of principle).  Instead, I am using the term to mean a law or fact of nature that explains how something works or why something happens (e.g. a principle of chemistry).

In the article "Agile and Waterfall: More Different Than You Think" Tim Ottinger lays out an argument for why mixing and repurposing practices between waterfall and agile development leads to unsatisfactory results.  In the process I believe he uncovered several fundamental principles of agile in the form of certain axioms. I've since refined these axioms into the following set (given with a comparison to a more traditional view).

Mindset Axioms

Agile	Traditional
We may be wrong in our assumptions, and even if we are currently right the world may change, therefore...	We are right in our assumptions, and the world is fundamentally static and unchanging, therefore...
Changes are inevitable and needed for success	Changes are an indication of error
More planning will give us a false sense of certainty and likely lead to errors in decision making	More planning will allow us to reduce uncertainty and correct errors in decision making
Inspection is to learn about the current state of the world and correct the plan	Inspection is to find deviance from the plan and control changes
Feedback is the primary signal for adjustment	Milestones are the primary signal for adjustment

The first is the fundamental agile principal. We assume the future is unknowable and therefore our assumptions are possibly wrong. From this we can derive the rest; the limited usefulness of planning, the need to continuously inspect and adapt to understand the current state of the world, the value of feedback.

As an example we can use these fundamental principals to derive the purpose of different Scrum ceremonies.

• Sprint planning provides an opportunity every iteration to adjust to a new state of the world.
• Stand-up/Scrum provides a daily inspect and adapt cycle where team members sync up and and can adjust to changes based on what they've learned in the last 24 hours and broadcast that new understanding to others.
• Sprint reviews allow an inspect and adapt step of the product every iteration. Stakeholders are able to experience working software in their hands which often leads to new lines of opportunity (see exaptation).
• Retrospectives allow an inspect and adapt step of the teams process. They are able to adjust how they work based on knowledge of the world as it is today. 

We also see the centrality of the inspect and adapt cycle in agile technical practices

• Continuous Deployment allows a faster feedback loop between customers and the team
• Continuous Integration allows a faster feedback loop between parts of the system
• Local automated tests allow a fast feedback loop before code is pushed to others
• Writing a failing test then making it pass the simplest way possible allows a fast feedback loop showing that your codes does what you expect and allows the design to be adjusted based on what's learned as you work
• Pair/mob programming provides a faster feedback loop from peers to help improve design, hold context, and correct errors

All of these practices are useful if we understand that we can't "do it right the first time" because the world changes. Better designs will emerge, new technologies will be created, we will find new opportunities to explore. We as individuals are constantly changing as we learn and find new and better ways to solve the problem at hand. We co-evolve with the projects and products we create.

There are other fundamental principles behind individual practices related to flow such as work-in-process limits and small batch sizes (principles of queuing theory) covered very well by Ken Rubin in Essential Scrum and  Donald Reinertsen in Principles of Product Development Flow. However, I think you'll find that they are more easily understood when approached from the perspective presented here.