99% Dirty Agile

I recently attended the launch of the BCS's latest offering, Agile Foundations: Principles, practises and frameworks in London. As this is the official companion book to the BCS Agile Foundation Certificate in Agile, you might think that it's only worth reading if you are studying for that qualification, but you would be incorrect.  Having read it, I can heartily recommend it for anyone with an interest in agile methodologies; there will be very, very few people who have a broad enough range of experience that they won't learn something new, interesting and useful from it.  However, a full review and/or evangelical recommendation is not the point of this post, and neither is a forensic examination of how it treats the topic of agile documentation (which will come at a later date.  Try not to get too excited, it's bad for your heart.).  The point of this post is to relate the important realisation I had on the way back from the launch.

After the book overview, case study and Q&A (all very interesting) there were a few drinks and some chatting amongst ourselves. During this, I had a conversation with Mike Short from radtac where I asked him about the problem of Water-Scrum-Fall and how you turn the specialists that you find in mature companies into the generalists that you really need to make agile effective.  Mike is someone who (amongst other things) specialises in changing cultures and mindsets into ones where agile can flourish, so asking him about the minutiae of linear development models is a bit like asking Alex Ferguson for a detailed discussion about methods for improving sprinting speed - it's relevant to what he does, but he operates at a different conceptual level.  That alone was an interesting realisation, but not the important one.

No, the important thing to come out of that conversation, in fact out of the whole evening, was that what I know about, what I write about on this blog, is not what could be called "pure agile".  I'm specifically not saying "theoretical agile", because radtac clearly have a theoretical model, or, more precisely, multiple agile models that overlap, and they take the most appropriate parts of these models to help a company achieve their agile paradigm shift in the most effective way for that individual company.  And it works, and radtac are rightly respected for it.  Saying "theoretical agile" is almost like a sneering riposte, as if I'm suggesting that the wimpy boys study theory, while REAL MEN DO AGILE IN THE REAL WORLD!!!  YEAH!!! *muscle flex*  And to be clear, I'm not saying that (but *muscle flex* anyway, because hell yeah). I'm also not knocking the theory of agile, or those people who adhere to an implementation that is very close to the theoretical model, because that's what you're supposed to do.  What I AM saying is that what I know about is agile in a world where companies either can't or won't invest in making the paradigm shift to a fully agile company culture. Time and time again I read questions and laments from people on forums facing the same problems I've faced, and friends in other companies have faced, and these problems are almost always ones that Ken Schwaber would solve by saying "Scrum, Scrum and more Scrum!"  But what do you do when you aren't in a position to influence the decision to fully commit to agile as a company, when "Scrum, Scrum and more Scrum!" isn't an option?  How do you solve the problems that come with being an agile team without an agile company around you?

The answer is: Dirty Agile.  You might not be able to implement the wide-scale changes that agile requires to be truly effective, but you can damn well be as agile as possible in your specific circumstances.  So you struggle with people who don't "get" agile, you try to persuade and evangelise, to put in place processes that will help you and your agile team be more agile, and all the while the non-agile people are still pushing you and pulling you in the same non-agile way they've always done, whilst claiming that they don't really understand agile, but somehow still managing to find any way they can to push the blame for their problems onto your agile set-up and thereby both undermine your efforts to be more agile AND give you more work to do.

Purists might say that this isn't agile at all, that it's just a pale imitation, and there's some truth in that.  But everyone who's worked in dirty agile will recognise it, and know how painful it is to struggle valiantly against the ignorant, and the lazy, and the wasters, and the blame-dumpers, until the motivation is gone, the velocity is gloomy, and the original nay-sayers are laughing in their sleeves at your crazy notions of time-boxed iterations and prioritisation before specification.  They told you it wouldn't work, don't you remember?

*sigh*

We still believe in agile, but it seems so.....hard.  And far away.  We're the ones with our noses pressed up against the window and drooling, like Dickensian urchins outside a cake shop, or developers wistfully staring at Google's careers page.  We are the 99% of agile adopters who gaze longingly at the cool glass towers of the1% who've achieved agile nirvana, and imagine how good it must feel to be really, truly, madly, deeply agile.

I feel your pain, my friends.  This blog is for you.