Agile is a mindset. It is more important how you think than what you do, because your thinking drives your actions and behaviors. Repeating motions without understanding is not very useful, and tends to lead to disappointment.

That said, there are also certain behaviors that support the beliefs we have, so ultimately there should be an alignment between the way we think and the way we behave.

There are different ways in which the mindset (and some of the behaviors) have been captured, in the hopes of making the ideas more easy to understand and express. We do, of course, have the Agile manifesto. We also have Lean Software Development with its principles. Two more recent takes are the Modern Agile and Heart of Agile, both of which try to recapture the essence in four main ideas.

All of the above are worth taking a look at, but I will still try my hand to distill the most essential stuff in my own words :). This text is a bit raw, but I’ll post it anyways, in the hopes of receiving some comments to help me onwards.

People

People over Process. That’s our Agilist credo. So no definition of Agile cannot be without attempting to cover the people aspect of our beliefs. And besides, what else is being a human than being with other people?

Delivering organisation

It is important to allow everyone in the organisation take ownership of their own work. This drives motivation and doing the right things the right way. We also need to create an environment where it is safe to be a whole person. We need to build most of the organisation around high-performing teams.

This applies not only to development team members, but also to product owners, managers and internal functions in the organisation. They all need to feel empowered and in control of their jobs.

Customers

Customers are all the people we deliver the value for. Without them, our work has no value. “Customer” covers all recipients of the value we deliver; not just the ones who pay for it. We need to engage them appropriately to give them voice, but they don’t necessarily drive the development decisions.

Process

There are two most essential elements of the process from which all else follows. As far as I know, all proposed Agile frameworks contain these two elements. If we want to cook our own process, we should establish these two and derive the rest of the process on what we learn or need.

Working Software Frequently

Every Agile framework emphasizes the need to have a concrete, working version of the system at frequent intervals. The really working software drives risk exposure and management, proves progress, provides feedback, and delivers value. Without such critical transparency, risks can hide unexposed in the unproven code, progress becomes fuzzy to evaluate, we learn slower and less, and the system cannot be used for anything.

In Scrum terms, we talk about Potentially Shippable Product Increment, but that’s just an example. All Agile processes have their equivalent, regardless of whether the team actually delivers software or something else.

Continuous Learning

To an Agilist, the world is never ready. There are always things to improve. We can learn all the time, all kinds of things. The faster we learn, the faster we become better and faster.

In Scrum terms, Retrospectives are the main component here, but we should not limit our minds to think just them. Any and all learning matters, wherever it happens.

These four key elements interact with each other

Delivering organisation & Working Software Frequently

In this combination, we talk about the value we get, as the delivering organisation, from the frequent working versions of the software. We know where we are, we can control risk effectively, we become fast. Agile here means the ability to inflict change on our product, quickly and effectively.

Look at: CI/CD, Clean Code, Refactoring, Definition of Done

Delivering organisation & Continuous Learning

In this combination, we talk about the growth of people, both in terms of personal growth and skill, and in terms of teamwork. How do we grow as an organisation? What structures do we need to allow our people to be even better? How do we leverage everyones’ best abilities? How do we learn new skills as individuals and organisation?

Look at: Retrospectives, pair working, mob programming, Dojos, Agile HR, Management 3.0

Customers & Working Software Frequently

In this combination, we talk about deployment and the customers’ ability to take the valuable features to use. We talk about speed of delivery, too. We immediately see where we have problems and we can fix them quick. Customers see fast solutions to their pressing concerns.

Look at: DevOps

Customers & Continuous Learning

In this combination, the focus is on getting continuous (and fast and frequent) feedback from our customers and users regarding what problems they want us to solve, how they want us to solve them, and what are the (changing) priorities of their various needs. Our deliveries allow them to refine their desires, and invent new ones. Through all this, we can refine our backlog to more valuable features and, ultimately, hope to see the results also in financial outcomes.

Look at: Lean Startup, Design Thinking

All of the above are “true”, regardless of whether the team/organisation uses Scrum, Kanban, or some other framework as their management model. None of the frameworks work without conscious attention all essential aspects. All frameworks have “blanks” that the utilizing organisation must answer for themselves.