News

It doesn’t seem all that long ago that the word “Agile” in an organisational context only elicited puzzled looks, but Agile methodologies have skyrocketed in the last few years, with Forrester’s 2010 Global Developer Technographics Survey showing an increase in the adoption of agile methodologies of more than 3% compared to the previous year (in comparison, the adoption of waterfall methodologies has only increased by 1% and the adoption of  “Iterative approaches” such as Spiral, Iterative Development and RUP has decreased by more than 1% over the same period of time) [1]. And while increased knowledge about, and adoption of, Agile methodologies is a benefit to individuals, organisations and the Agile community alike, it has also come with an increase in negative experiences – a recent Voke report stated that 64% of respondents found their Agile transformation “confusing, hard or slow”, with 40% of adopters not identifying any benefits with Agile and only 28% reporting success [2]. In the same report, the writers mention that they had received some “unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement”.

While the reports’ findings and conclusions may be flawed and are definitely heavily debated, unfortunately in my work as an agile trainer, coach and consultant I have become increasingly aware of people who have been “burned” by their Agile implementation. Having been in similar shoes myself (I think it’s fair to say that the start of my own Agile journey left me somewhat “underwhelmed”, to say the least) these are some of my observations over the past 3 years or so I believe contribute to the issue:

1. Little knowledge & “Expert guidance”

With the popularisation of Agile methodologies, methodology-specific certifications have become the “be all and end all” for many organisations – in his 2010 Scrum Certification Survey, Scott Ambler observes that 45% of respondents indicated that their organisation required job candidates to have appropriate certifications, with 14% stating that their organisations require candidates for Agile teams to be CSMs [3]. And despite the fact that 78% of 102 respondents to the question “What do you think about the concept of becoming a “certified master ” after taking a two-day course” have answered that the certification is obviously meaningless, a quick search for “Certified Scrum Master” on a job site of your choice will highlight the importance placed on the certifications by those interviewing for jobs.

While I’m not inherently against certification, I believe there is a significant difference between the knowledge transferred in the classroom and hands-on experience. Theoretical knowledge and the understanding of Agile concepts is highly valuable (or even essential) if you want to participate in the game – but it does not qualify you to become the referee!

 2. The one true path or “If it’s not in the book”

One of the questions I get frequently asked is “how do you do X in Agile?” and (possibly obnoxiously) the most common answer I give is “what do you think would make sense?”. Maybe it’s due to the tyranny imposed by little knowledge masked as “expert guidance” or maybe it’s simply a case of being trapped in a more traditional, rule-based mindset but unfortunately the “That’s not Agile” mentality is spreading in the Agile Community and is in some instances accompanied by a conviction bordering on righteousness which can only be described as “zeal”. While I agree with the opponents of the aforementioned Voke report insofar that the sample size may not be wide enough nor representative (the sample consisted of only 200 respondents, which were self-selected), reading some of the online comments made by members of the Agile community I was strongly reminded of the age-old adage “if you’re not with us, you’re against us”. Have we really evolved into a community which outcasts those who do not agree with our opinion? And has our desire to educate the professional world to the benefits of Agile methodologies degenerated into a battle about community belonging or even, dare I say it, a bigger market share?

3. Best Practice & Standards of Excellence

So now that we’re doing this Agile, wouldn’t it be good to be doing it really well? Absolutely! And how do we ensure that something is done really well all the time? By relying on the fact that the people we have spent a lot of money hiring and training to do the right thing at the right time? Hell, no! We will achieve this by using the elite members of our organisation to write up a document and publish it for everyone to read and adhere to – just like we’ve successfully done for the past 20 years! Hang on – if it’s been successful for the last two decades, why are we changing it now? D’oh – because it’s Agile, stupid!

Having started my career working with NPOs and NGOs I have become aware of organisations’ obsession with  “best practices” very early and for years have been thinking “well, if you’re not doing best practice, you’re not doing it as well as you should!”

Introduce reason #1 for implementing “best practices” – it ain’t called “best” for no reason, and clearly we wouldn’t want to do anything other than the best. Unfortunately, “best” implies that there is no way a practice could be improved upon, that we have already reached the highest heights of organisational excellence if we manage to adhere to said practices – I believe the technical term for this is “stagnation”.

In my opinion, the second reason for implementing “best practices” is often lack of trust in those executing said practices. Introducing best practices are a way of stopping people from thinking for themselves – assuming you’re paying the people you employ in real money in exchange for services requiring knowledge and expertise, and you’re not making them use the one asset that would be useful to you as an organisation, doesn’t that sound like a bit of a waste?

Now we’ve established some of the potential roadblocks on your way to Agile success, I’m sure you can’t wait to hear my thoughts on strategies to overcome them – so here’s my top three:

Forget Agile

My first and foremost strategy to overcome the hurdles above is to stop calling it “Agile” altogether. Much as I like the thought of agility and the adaptive nature the name implies, I fear it is becoming a brand name more than a philosophy and we’re becoming more concerned with “doing Agile” than “doing the best thing for our business”.

So why don’t we stop trying to think “is this the Agile way to do it?” and start thinking about

1. Does it add value?
2. Is it achievable?
3. Is it ethically responsible and sustainable?
4. Is this the simplest solution that will provide the desired benefits?
5. Does it make sense?

I don’t “teach Agile” – I talk to people about how to best elevate and exploit their existing resources and constraints in order to improve the Status Quo.

Beware of false prophets

There are some rather obvious parallels between the developments in the Agile community and organised religion – it all started out with a few people believing they had found an improved way of being and trying to spread the word to others. Over time, more and more of these believers congregated and started to form an organisation. As the community grew, so did disagreement between the members – splinter groups formed and the rest is the history of pointless wars trying to find out whose prophet was “righter”.

Organisations wanting to go agile often resemble those seeking faith – they know that their current way isn’t working and are easy prey to those offering a straightforward solution. By wanting to believe in “the one true path” advocated by those making a living from it, they are liable to become a significant contributor to their own downfall.

For me, Agile is not a career choice – it’s about being a better person all the time and “doing the right thing” rather than “doing the thing right”. In order to do so, I have to consider thoughts, ideas and approaches regardless of their origin and source (this way of thinking about agility is thankfully on the rise and has been captured in the “Oath of Non-Allegiance” [4]).

“Good & Better” vs “Right & Wrong”  

I have mentioned some of the issues with “best practices” earlier and I firmly believe that best practices are the natural enemy of agility. Agile is about adaptation and adaptation requires organic evolution – and if you learned about Darwin’s Theory of Evolution in High School (or any other educational facility) then you also understand that evolution requires feedback. “Best practices” aim to find a solution which cannot be improved upon and works repeatedly regardless of context. Feedback, on the other hand, requires context to turn mere information into useable (and useful) knowledge, making “best practices” the natural enemy of the continuous adaptation required to successfully survive in an ever-changing (and ever-faster-changing!) world.

A fool with a tool is still a fool

We need to remind ourselves that Agile is a tool – Agile is information and like any other information it requires context and cognitive modelling to turn it into knowledge.  It takes cognitive ability to turn information into knowledge, and experience to turn knowledge into wisdom. Wisdom, therefore, is the ability to use applied knowledge to create insight – and once we have insight, we can generate the foresight that will allow us to continuously evolve and adapt on a personal, team and organisational level.

Some final parting thoughts

Agile is the path, not the destination, and your Agile transformation should be a journey, not a commute. When commuting, we’re trying to go from A to B in the fastest / most direct / easiest way possible – when on a journey, we focus on the experience and accept that there may be uncertainty and possibly danger along the way. A journey involves being exposed to, and hopefully submerging ourselves in, a new culture. First and foremost, a journey is about adventure – so go on, start your own journey and find your own adventure!