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

The first of the 12 principles behind Agile Manifesto states: “Our highest priority is to satisfy the customer through an early and continuous delivery of valuable software”. In my opinion, the sentence is so powerful, dense and hard to implement, that once you try to remove any of its parts from your approach, you simply loose the spirit, the heart of agile software delivery. In general, I prefer to write about specific real-life examples of what I tried, done or seen. This time I would like to leave you with some questions instead.

Our highest priority

I am constantly faced with multiple issues, stories, targets, focuses, etc. that are all equally important. It’s extremely hard to have one priority. You need to be focused not only on an individual, personal level but also on a team’s level, sometimes even on a company level. Constant focus drives constant learning of new things, skills and approaches. This drives constant change. Constant change drives constant going out of individual’s and team’s comfort zones. How many times have you met an individual team member, a product owner, a product manager having one priority? How many times have you met a team which has one? Have you ever worked in a company having one?

Satisfying the Customer

I intentionally wrote Customer using a capital letter. The Customer is one and only one reason for which any product team exists at all. How many times have you met a team for which satisfying the Customer was really the highest priority? Rarity level of such teams is comparable to Yeti. During my almost 20 years career, I met around 5 such teams. Not because people weren’t skillful, engaged, open and eager to achieve something special for their Customers, but rather because an environment to which they have been „thrown”, wasn’t helpful and supportive.

Through early and continuous delivery

How early you know your code failed? How early you see red alert yelling your build shall not past? How early a teammate reviews and tests your code or accepts your feature before deployment? How early your delivery takes place? How early you gather valuable feedback from your end-users so you can learn faster?

Valuable software

And finally, Her Majesty, The Value. There are countless articles out there describing what value is and how an agile team brings this value. Simultaneously, how many times have you met or worked with a team of which every single member was ready to openly and sincerely state she or he delivers really valuable software that has a positive impact on users and business metrics? How many times have you worked in a team which each iteration have been treated as the last one: either we deliver value or we die?

From Velocity to Time To Feedback

I don’t know answers to all these questions. However, if you put the title of this article into a Google search, you will get over 7,000 strict results. It’s a lot. I believe there are many people out there who know the answers to some of the questions stated.

My first simple recommendation towards answering is to look at your data and simply measure it. Of course, you can measure velocity and other agile stuff. But what if you measured these ones instead?

• How many seconds before you know your commit failed?
• How many minutes till the red alert yelling your build shall not past?
• How many hours before a teammate reviews and tests your code or accepts your feature before deployment?
• How many days before delivery takes place?
• How many iterations, sprints or cadence meetings before you gather valuable feedback from your end-users so you can learn faster?
• Do you measure cycle time and shorten it?
• Have you tried to measure the systemic time to market and optimize it?
• Have you ever tried to measure time to feedback and tried to constantly shorten this time on a unit test, code review, acceptance tests, product owner’s or end user’s approval levels?