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:
RIP OKR, Say hello to OITOhttps://t.co/dmDRqKytqn— Asad Safari (@AsadSafariEN) July 22, 2019
…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)
Code (other or additional stuff)
Test (other or additional stuff)
Make generic/infrastructure/core solutions
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.