Odd Socks Consulting - Lean - Agile - TOC

That's not a cake.

Saturday's times revealed (subscription required) that trendy wealthy folk now have two kitchens in their big houses. One kitchen is manned by a professional chef (or chefs) and provides professional quality meals for the owners and their guests. The other is for the the owners to do their own cooking - like normal people do. I expect that both kitchens look and operate very differently, even if the cooking follows the same fundamental principles.  Thing is, though, you'd recognise them both as kitchens if you saw them. 

In unrelated news, the telegraph revealed that bite-sized snoballs (a Scottish delicacy, apparently) are in fact a CAKE not a delicacy, and therefore not liable to value-added-tax. TWO judges applied a number of quite practical tests (including eating them and other cakes) before making their ruling.  The inland revenue folk had preciously decided snoballs weren't a cake but the makers claimed they were and it was worth £2m in tax. You'd think it'd be quite clear what a cake is, and what a cake is not, but, well, it's not.  

"A Snowball looks like a cake. It is not out of place on a plate full of cakes. A Snowball has the mouth feel of a cake", [ond judge] added. 

image.jpg

oOo

So: many kitchens, many cakes.  

Likewise, IMHO, there are many types of Agile. Some big; some small. Some programmer centric; some pm centric; some business centric.  Some good, some bad. Some using new technology, many not. 

Likewise two people may look at the same "agile" development team and one will see an agile team while the other won't.  If you got judges in to compare the two teams the judges would see many similarities and many differences but how would they know whether one is Agile or not?  They'd be wrong, IMHO, to try to apply a cake-test because agile isn't binary.   

Why am I sharing this?  Because I've chosen to do Agile in businesses that look a whole lot less Agile than the case studies you see at conference and in text books.  As I reveal more about how I "do agile" you're bound to react, occasionally, "but that's not agile" and you'll be right and wrong at the same time.  

I'm just giving you a heads-up, is all.  

oOo

Earlier this year, for instance, a very large consulting company reviewed one of the large "agile" projects I have worked with and they said it wasn't very agile.   They were right - if you campare it with a small XP start-up - and they were wrong - when you compare it with what the project looked like a year (or even 3 months) earlier. Part of my job, which I'd kicked off a year earlier is to reframe agile as a "getting better" process where better means we are shipping important, valuable, high-quality software often, so my colleagues agreed with the consultants assessment, albeit with context. 

A big part of what I do is frame Agile as a process of getting better, rather than a bunch of technical practices. Loads of agile folk so that but I just want to point out that, for me, it is enormously important. Otherwise people get dispirited, they lose interest, abandon Agile - saying it doesn't work. 

If Agile doesn't stick the it isn't very Agile ... 

clarke chingComment