The Forgotten Agile Principles

I recently watched a great TED talk from Simon Sinek titled “How great leaders inspire action”

The main point that Simon makes in the talk is:

“People don’t buy what you do, they buy why you do it”

He was coming from a marketing perspective, but the talk resonated for me because of its application to “Agile”.

The majority of this post focuses on Simons model “The Golden Circle”. The second part of the talk moves on to the “Law of diffusion of innovation” which I don’t cover here. For a testing focus on on law of diffusion of innovation, I’ll refer you to Johanna Rothman’s Lets Test 2013 keynoteHow to be a Kick Ass Manager“.

In the talk Simon describes his model of “The Golden Circle”:


The model consists of 3 concentric circles:

Outer circle = What

Everyone knows what they do

Middle circle = How

Some people know how they do it. E.g. USP

Inner circle = Why

Few people know why they do what they do E.g. purpose, cause, belief

Golden Circle Applied

In the marketing context, most marketeers work from the outside-in (red arrow), from the clearest thing to the fuzziest thing. But inspired leaders & organisations think from the inside-out (green arrow).


From the inspired leaders & organisation examples Simon gives in the talk (e.g. Martin Luther King, Wright Brothers, Apple) the inspired have more belief in their product than the “uninspired”.

This belief gives the inspired greater passion & deeper understanding of their product which is evident when they are “selling” that product

Which brings Simon back to the quote:

“People don’t buy what you do, they buy why you do it”

This related to Agile, how exactly?

The way I see it, the signatories of Manifesto were focused on the “Why” of Agile – they knew why they were together & what they had to achieve

They created the 12 principles & the Manifesto itself is a digest of those principles.

For me, the principles form the “Why” inner circle & Scrum & Lean are examples of the “What” outer circle.


The signatories – the inspirational? – were working from the inside out when they created the manifesto.

So what’s the problem?

It appears to me that too many people have brought into the “Agile” product without fully understanding the reasoning behind buying the “product”.

They understand what the product offers & to a certain extent how to adopt the processes of the product, but they miss why they opted for the product in the first place.

They are working from the outside in & missing the principles behind the processes & the product.

This impacts the way they adopt the product & its associated processes. The  product drives the process, not the principles behind the processes.

This is also applicable for some of those less scrupulous  selling Agile consultancy – the sellers don’t need to know why, the customer already thinks they know why.

Have you heard the joke about the medical students who find studying to be a doctor too hard, so they rip out the page which talks about teeth & study to be a dentist instead? This joke makes me think of all the people who rip out page 1 of the manifesto & disregard page 2 (principles)

What about me?

My experience of Agile is very, very limited but I have been fortunate enough to be around people less ignorant than me about the topic. One tip I received in my very early days on my 1st Agile gig was (para-phrased)

“…its about the principles. Once you understand those, the rest makes much more sense.”

That has stuck with me ever since & I use it as my heuristic when talking about anything remotely related to creating a more agile & adaptable process.

I love the agile principles & some of the processes – they have reinvigorated my interest in testing. This includes manual testing for all you XP fanatics out there. I’ve written more about my approach to testing in this post. That was in 2011 – its slightly different now as I am in a different organisation, but the approach still serves as a heuristic I use to help me test.

For me, words like “Scrum”, “Lean” & “Kanban” are less important than the way we work.

Call our process what you want, so long as we all understand what the process is & why we are following it.

In my opinion, the “Agile” buzzwords by themselves won’t help improve software development, it is the meaning behind those buzzwords which are important.