Our Highest Priority… tl;dr

It is a common mistake to think of agile as a set of practices for software development teams. But it’s not – at least not in the commonly interpreted manner – as indicated by the first principle:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

The majority of development teams practicing agile are – in fact – not agile teams. It’s a harsh statement, I know.

This is for the simple reason that, most so-called agile development teams are locally-optimized to create software. Some of them create working software.
And fewer than those are creating software that customers can actually use, in a true continuously delivered software.

The flaw is in what customers get, not in the fact that they get working software.

This post is the 3rd in a series on Agile Manifesto tl;dr. Click here to go to the first post including an index to the others.

Let’s break this principle to smaller pieces:

Our highest priority

The word ‘priorities’ is relatively new – it virtually didn’t exist until the turn of the 20th century, aka birth of the Science of Management. Before that, there was only Priority – singular, as in Information or Knowledge. A person or organization can hold information and knowledge, not informations or knowledges. In the same token, until c.1900 an organization could only have a Priority, not a set of priorities.

With the growth in size, organizations began to manage multiple priorities, leading, ultimately, to loss of focus.

So, our highest priority – The Priority – is to satisfy the customer though early and continuous delivery of valuable software.

Agile processes guide us to work on OITO, as Asad Safari notes:

…is to satisfy the customer

A customer, any customer, exists in both ends of the software development process: In requests coming in, and in valuable offering coming out.

This is borrowing directly from Open Systems Theory.

If our Priority – The Priority – is to Satisfy The Customer, we will be most effective and efficient when we will all be working on the same thing, regardless of our role, team, group, department, etc.

…through early and continuous delivery

Early – deliver something as soon as we can

Continuous – deliver also the next thing as soon as we can

So to be in our most efficient and effective form, we should work on the smallest chunks of work possible.

To do that we should be aligned on what we do regardless of role, team, group, etc.

Noting also the implication of the word – delivery.

When I shop online for groceries, the delivery is accomplished when the goods are received at my home, to my satisfaction. If the provider delivered the wrong or substandard goods – I expect it to be rectified ASAP.

The same goes for delivery of:

…of valuable software

Whatever the output is, it should be of value to the customer.

Let’s take a quick look at what we do in software organizations to determine what falls into the category this principle:

More of Less of
Understand (what generates value to customers) 

Learn (what makes value to customers)

Code (what makes value to customers)

Deliver (what makes value to customers)


Write specifications

Code (other or additional stuff)

Test (other or additional stuff)




Make generic/infrastructure/core solutions

Report progress

That is, there is more value on the left

’nuff said

What to do?

This whole principle leads to one major kind of action – simple to explain and extremely hard to master:

Reduce the WIP – Work In Progress.

That mandates to align on what people work on.

This can be working on the very same feature. But, more often, this means doing multiple things that all align to the same OITO. For example, running multiple experiments for a similar goal, or multiple product-teams working each on a different feature for a collaborative business goal, etc.

Other principles of the manifesto guide us how to do it.

But the Priority is – align our work on what the customers need and want, and work relentlessly to get it out as quickly and as frequently as you possibly can, while not disrupting the incremental value of the product or service.


Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email