Getting Back to Basics

I wrote this article below over 10 years ago and even then you may pick up on my frustration back then with "Agile". I am about to make an announcement in the coming days and this article will help to set the groundwork in helping people understand some of the comments I will be making as well as some of the perspectives that I hold. To many of you who are kind enough to send me private comments in praise of my previous articles, none of these perspectives or maybe even my announcement will not come as any surprise. In the meantime enjoy this short article and I will update you in the next few days once the draft of current thinking is ready for public consumption.

What is Agile?

I start all my Agile pieces of training, especially for novices, with the above question as I like to get an understanding of people's perceptions about Agile at the outset of the training. I receive many answers and here are just a few ...

• It's a way of writing software
• It's a process
• It's a methodology

Now, of course, the question does presuppose that Agile is a thing, something that you could lift up and put in a wheelbarrow. So I probe further by asking a different question: "What is your definition of the word Agile?" Now I get a different set of answers ...

• Speedy
• Quick
• Flexibility
• Responsiveness
• Nimble
• Alert
• Bendy
• Athletic
• changeable

So Mark, which is the right definition of Agile?

So here we have a variety of different definitions and understandings of Agile, but which is the right one? Anybody that knows me and has attended any of my training or coaching will know that this is a trick question. My response is that there is no right or wrong answer to this question. In fact, you might liken my answer to that of Humpty Humpty:

"When I use a word,"

Humpty Dumpty said in rather a scornful tone,

"it means just what I choose it to mean -- neither more nor less."

"The question is," said Alice,

"whether you can make words mean so many different things."

"The question is,"

said Humpty Dumpty,

"which is to be master, that's all."

So in that regard, we can take Agile to mean whatever we want it to mean, but the problem with that is that each person in our organisation, whom we are trying to educate in the practices and principles of Agile, will take the translation that suits them best. And like in the nursery rhyme you can expect a big fall when so many differences of opinions that are not aligned are not allowed to be discussed, especially when the HIPPO's is fundamentally flawed. (HIPPO being the HIghest Paid Person's Opinion, just in case you were wondering ...)

It's not about what but more importantly about "WHY?"

In my honest opinion, I think this is the wrong question to ask of senior stakeholders who are charged with delivering what is now known as an Agile transformation, mainly because it can be taken to mean so many different things by so many different people. To my thinking, a good Agile Consultant or Coach is best served helping the organisation's leaders answer this altogether more important question: "What business problem does Agile help you to solve?" Once this question has been answered we can then go about exploring the many different flavours of Agile and finding the one that best suits our organisation, because one size most definitely doesn't fill all.