Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
This is Agile principle number one and it sounds so simple that many teams just
kind of skip over it because it seems so obvious. “Of course satisfying the
customer is our highest priority. We can check that box, let's move on to something else. “
But there is a lot of depth and nuance in this principle that often gets glossed over.
If your team is truly trying to follow this principle
it will drive most of your decisions. In fact, a good percentage of the struggles
I see in software teams come back to not understanding how to apply this principle.
Have you ever played one of those team survival simulations where you have to
rank a number of items based on how they will help you survive in some specific situation?
Maybe you are stuck in a cabin during a raging wildfire in Australia
or you’ve just crashed a helicopter in the NY Catskill mountains. It is up to
you to decide whether the 20 foot piece of rope is more important than a frying pan.
Whether the newspaper is more or less of a priority to keep than the bottle of aspirin.
The thing that makes these fun is that everyone agrees that the priority is to survive. You might
think the rifle is more important for survival in the winter snow storm because it will help
you signal for help. Your teammate might be thinking about how to keep from freezing
and assign greater priority to the butane lighter. Since you share the same priority of survival,
you can work together to make decisions that are usually better than what any individual would come
up with on their own. The discussions involve constructive conflict toward a shared goal.
I’ve conducted these types of simulations for the past two decades with all kinds of teams.
From young professionals in the backroom of a pizza shop to the software engineers
working for a central bank of a large economy, everyone is working toward the
same goal and brings their expertise to the table to make the best decision possible.
Well, almost, but not quite everyone. I was doing the simulation for a team that was part of a
government agency. We divided them up into groups of 4 or 5, walked through the disaster scenario of
a crash during the middle of a blizzard, explained the list of items and let them get to work.
As I walked around from table to table, most of the teams seemed to be doing very well. They
were weighing the advantages and disadvantages of each of the items they were trying to rank.
There were lots of constructive conversations going on. People were discovering all kinds of
uses for various items that they have never thought of and also finding out that some of
the things they thought would be most useful were less so when stuck in the middle of a snowstorm.
One group wasn't doing so well. While most of them were busily trying to weigh the
pros and cons of each item and trying to understand how it could help them survive,
one lady was focused on a very different priority. Her only focus was on trying to get the bottle of
Xanax at the top of the list. No matter how much the rest of the team tried to convince her that
the drugs would be worthless if they all froze to death, the matches just didn't make it to her
priority list. Neither did the blankets, emergency radio, or anything else that might be useful.
The core issue was that her sense of priority was different from everyone else.
Her priority was to make sure that in the simulation, the drugs didn’t get
pushed to the bottom of the list. I have no idea why, but it was fascinating to watch
because it so vividly illustrated the importance of the first Agile principle.
Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
When a team isn’t fully bought into this principle, individuals are going to have
random other things as their highest priority. I’ve seen situations where
the highest priority was to employ lots of developers because that is how managers obtained
prestige at the organization. In one case the managers of the project wanted to hire
50 developers for a project that we ended up doing with less than 10.
I’ve seen other teams where some individuals' top priority was to
use a particular architecture they had always wanted to try.
Early and continuous delivery were relegated to distant secondary priorities because the
particular architecture occupied the top spot. Others were focused on implementing
some framework they had created and that framework occupied the top spot of any decision.
These are the types of common problems that are solved by this Agile principle.
Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
If our highest priority is to satisfy the customer, we now have a rubric for defining
success. If we are going to satisfy them with early and continuous delivery of valuable software
we have a game plan and timeline of when we should start delivering something. This doesn’t mean that
no one will have any different ideas about how to follow this principle, but getting everyone
aligned on the top priority means the team will be trying to find the best way of achieving the
same goal instead of spinning their wheels trying to figure out what goal they should head toward.