I Blame the Superficialites

I do, I absolutely do, the people who:

• Can’t seem to progress past the buzzwords.
• Fail to grasp the meaningful practices and how they relate.
• Worst of all: are completely oblivious to the underlying principles on which it’s all based.

You know these people.  You would have encountered them as you strive to be productive, and you probably work with these people right now; so you’ll also know that these people are a danger to themselves and others.

 
A classic example, one near and dear to my heart: agile.

Agile has an architecture (at least in my opinion it does), and by consciously understanding this a little better (it’s really, really simple) I’m hoping that it’ll be easier to effectively deal with people who aren’t helping.  By that I’m referring to those standing in the way of agile adoption or impeding its evolution in your workplace.

The other key takeaway is that the principles behind this don’t just apply to agile – they apply to anything, so you can re-use this way of thinking elsewhere.

The Architecture of Agile

So here it is – my take on the “architecture of agile”

A brief explanation:

• Three conceptual layers, in order of importance: principles, practices, buzzwords.
• Principles are the foundation of the “domain”; for me personally these are the agile manifesto, embracing change and muda, mura, muri.  You might have your own take – that’s cool.
• Practises are the embodiment of the principles - how we act on them, where we actually do stuff.  I’ve also listed some “concepts” which aren’t strictly practices - but which certainly support them.
• Buzzwords are usually directly derived from the practices and the lingo around them, almost any word from any of the other layers can be “promoted” to buzzword status, but the ones I’ve listed here are arguably the most abused.

The thing about the buzzwords is that they are useful but easily misinterpreted, so you have to treat (i.e. use) them with care.

Top Down

[Warning, buzzword bingo alert!]  The key failing I see is people trying to adopt agile (and other things) in a “top down” approach; paying too much attention to the words and not enough to the principles.  People get hung-up on the language, it gets political, and people talk at cross-purposes without knowing it.

The buzzwords are easy, they’re accessible, they’re short and if we say them enough (or if we can string enough of them together) it gives the false impression we’re correctly adopting the practices (the ones we want, anyway) and world domination will soon follow.

Bottom Up

This is the approach to take if you want real results.  If you understand the principles, the lie of the land, and where the dangers are you already know enough to be successful.  If you have that and you’re even slightly smart then you should be able to re-invent the agile wheel yourself.  Sure, you don’t want to have to do that but if you can then there’s a really good chance that you can recognise dangers early and deal with them more effectively.

The problem with the principles is that they require a bit more thought; they provoke the hard questions, if you’re serious about removing waste and embracing change you have to be prepared to clean out some baggage. 

The Practices

The smart people that came before you (just the same as you, only older) already figured these out, they invented the agile wheel (and sub-wheels) we know and love today: SCRUM, XP and so on.  You don't have to use these practices but they'll probably save you time and led to a better result.  they are the things you'd invent if you had to and if you understood the underlying principles.

The practices of agile have evolved to a certain point, and (generally speaking) naturally fit together best in certain ways.  They are tools, and like all tools they can be used to great affect – or abused.

As you’ve probably figured out by now, adoption of the practices via the buzzwords is a recipe for epic failure; where as adoption via the principles is the path to success.

Ironically, blindly following practices is something implicitly marked as a "no-no" in the agile manifesto: "Responding to change over following a plan".

Does the CEO need to be a SCRUM Guru?

Business people don’t want to know the technical detail.  They don’t care which design patterns are implemented or why refactoring is a good idea – they just want working (fit for purpose) software.

By extension – do they need to know and understand the principles behind agile?  There’s a variety of answers depending on who you talk to, but my answer is: yes, kind of.

You don’t have to have a degree in aerodynamics just to ride in an airplane, although it’s a good idea if you’re the pilot.  As a passenger on a airplane there are a lot of things I could potentially do that would result in catastrophe – but that’s seldom a problem. 

For a start the modern-day commercial flight experience wraps us up in so many protective layers it’s pretty difficult to do anyone any real harm – even if you want to; in addition to this people who ride in planes tend to have a basic grasp of the principles involved that helps guide there actions – I don’t often hear people complaining that they want to open the window.

Having at least a rudimentary understanding of the principles is good for everybody – people are on the same wavelength, the necessary stuff “just happens” and the bad stuff generally doesn’t.

The problem with the CEO (or anyone else) not understanding the principles of agile is that they’re the one’s sitting in air traffic control.  My take is that they don’t have to be (for example) certified SCRUM coaches for your project to succeed - but it wouldn’t hurt.  The more they know the better; as long as they understand the “why” and what the goal (of the principles) are, surely everyone’s better off.

So, okay they don’t have to be certified SCRUM coaches – but imagine how successful the business would be if they (and everyone else) did understand the principles well enough to be SCRUM coaches.  That’s a really desirable place to be.