Every time that I coach different organisations or different groups of people within the same organisation I ask the group to answer two questions about Agile.

​

• What three words would you use to describe an organisation that has Business Agility?

• What three words describe people’s behaviour when they act in ways that enable Business Agility?

 

These questions were first put to me when I was part of an audience for a presentation by Michael Sahota.  Michael is a global thought leader for Organisational Agility and Leadership.

​

Whether there are seasoned practitioners in the audience or beginners, we level set together around what we think Agile is, and I'm always delighted by how aligned the audiences are.

​

We use a word cloud to visually display our answers.  Word clouds capture the wisdom of the room and it’s a great technique to use with teams to ensure equal voice. 

 

Everybody gets an opportunity to contribute and to develop a set of words that answers the two questions above.  At this stage, if we were in the training room, I’d ask you to enter your 3 words.

​

For the purpose of the exercise, think of your answers to the questions and see how they compare to the word clouds below.  The bigger the word, the more people agree.  And, yes, closer inspection will reveal the odd spelling error – not everyone in the crowd could spell!

​

What three words would you use to describe an organisation that has Business Agility?

 

What three words describe people’s behaviour when they act in ways that enable Business Agility?

 

What I like the most about this exercise is what you don’t see.  A thorough check of both word clouds and you will not see the words, ‘framework, templates, methodology or process’.  For this word cloud example, over 100 people answered the questions and not one of them said those words.  That to me is really reassuring because it shows that people are closer to understanding that Agile is a set of values and principles – just as the Agile Manifesto intended.

What do I think Agile is?

For me, Agile is a set of beliefs that helps us make decisions about creating great outcomes.  If we hold true to the Agile Values, it shapes the way we think.

 

Agile Manifesto

The Agile Manifesto was written in 2001 by seventeen independent-minded software practitioners.  My understanding is the group gathered for a 3-day retreat at Snowbird in Utah.  I’m uncertain as to how much skiing was done but have it on good authority that lots of schnapps was consumed over the 3 days.  The other thing they did was discuss software development and while not everyone always agreed on that, they did find consensus around the 4 Agile Values and 12 Agile Principles.

Over time, the Agile Values have been embraced much more broadly than just software development – in other parts of the business, within support services (including PMOs) and in a variety of different industries - so I have replaced the word software with solutions below.  It seems to help people who are not software developers see that it could apply to their world.

 

 

The manifesto, a specific philosophy, is shown below.

​

We are uncovering better ways of developing solutions by doing it and helping others to do it.  Through this work, we have come to value:

 

That is, while there is value in the items on the right, we value the items on the left more.

 

Hmm… so is this what they mean when we hear ‘Agile is a mindset’?  Absolutely it is.  If you take nothing else away from this book, then just remember the 4 core values… try putting them into practice and your ways of working will likely change – I dare you.

​

NB: The 12 Agile Principles have been included in the appendix for your reference.

Upon reading the manifesto, lots of people make the mistake of thinking ‘over’ means ‘never’.  For example, they read ‘Working Solutions over comprehensive documentation’ and conclude that Agile requires no documentation (or processes and tools, contracts, or any plan).  Agile is a set of beliefs to guide actions and decision making, not an excuse to abandon years of common-sense practices that underpin quality.  The focus is on delivering value to the customer and adapting to change – it is assumed we do that without breaking the business.  That means testing, release management, training and operational handovers are still required – how else do you release a quality product?!

​

So, what happens to documentation, processes and tools, contracts, and planning?