Clarke Ching's Rocks and Snowballs Blog


How do you teaching the Chef to do front of house stuff?

I have a hypothetical question for y’all:  imagine you’ve got a chef who is great in the kitchen but you need to teach them “front of house skills” - i.e. how to interact with customers, how to handle complaints, how to keep people happy while hiding the hussle-and-bussle in the kitchen … how would you do that?

I, and a lot of my techie friends, are good technically but we sometimes have to do “front of house” stuff, and that doesn’t come naturally to most of us.  I wonder how we can get better ...



Bigger House or Bigger Garden?

My 9 year old Alice was chatting with her lovely little friend Lucy.

Alice:   What would you prefer, a bigger house with a smaller garden, or a bigger garden, with a smaller house?

Lucy:  A smaller house with a bigger garden.

Alice:  Me too.  That way we'd have room to play in the garden and, if we got more money later, we could add on to the house



Cut your Cloth ...

I  didn't hear the following saying until last year, so I don't know if it's common:

"Cut your coat according to your cloth"

It means to make the most of the limited money/resources you've got.


It kinda sums up the fixed budget/date and variable scope way of making Agile promises.

The sentiment also applies to how you adopt and adapt agile: don't moan about your situation being imperfect for agile (old ugly code? A disengaged customer? A dispersed team? Average staff?), do make the most of what you've got ... And then make it better. 



Genius Hours

Here's something I like about work: every month we have a Genius Hour.

That hour happens during a lunch break and between 20 and 30 people turn up (during their lunch break) for each session.  I organise the session but it only takes me an hour or so each month.  

What do we do during these hours?  This month one of my workmates is presenting a "beginners guide" to the Raspberry Pi, complete with real live stuff.  Last month one of our colleagues, a trained physicist, gave a talk on "Critical Thinking" - I missed it but people loved it.  Before that we had a bunch of lightning talks.  And before that we had a session on Introversion and the book Quiet.


This stuff is really easy to organise.  It's a little different.  And people like it.

Why not give it a go yourself?  



99Designs - so clever!

I'm crowd-sourcing my book's cover using 99Designs.  You should click the link to see how clever it is.  I pay them £300 then a bunch of designers take the brief for my book and go off and quickly come up with a draft design.  I then chose a few finalists in the "contest" and those folk polish their draft.  I chose a winner.  

It works for me because I get a whole lot of different ideas for a fixed price - and If I want to attract better, or more, submissions then I pay more - i.e. set a bigger prize - so that it's worth the better designers' time.

It works for the designers because, although they don't always win, their drafts don't take much time and if they're good enough they'll win some of them.

It reminds me of how Zara does product development: makes loads of stuff, try to sell it, if it sells then make more.



Rolling Rocks Downhill .... awesome news!

I decided today to practice what I preach and publish Rolling Rocks Downhill as a series.

I'll start the final edits for "RRD book 1" (the current beta) shortly, aiming to publish it early next year.  Book 1 ends with a cliff-hanger.  

I'll release “RRD book 2” in 2015 or 16.  It'll be slightly shorter book (a novella?) and ... it will end with a cliff hanger.  “RRD book 3” will follow and ... so on …


I discovered today (if you click the link, search for "cliffhanger") that this is how books were published in the  old days.  

In the 18th century ... the circulating libraries’ business model encouraged publishers to put out books in three volumes, so three people could be reading one book at once; novelists would write to the form, fleshing out their prose to fill the “triple-decker” format. The development of magazine and newspaper serialisation further encouraged some novelists towards length, as well as setting up a distinctive rhythm of cliffhangers at the end of each instalment.
— THE FUTURE OF THE BOOK - from The Economist


So, books used to be published in an Agile way.

Apparently Dickens worked this way: 

Dickens’ first novel, the brilliantly comic THE PICKWICK PAPERS, brought him enormous fame. Like all his subsequent novels, it was originally published serially, that is, in installments or parts over time.

He not only published serially but wrote serially too, planning each installment carefully. (His contemporary, Anthony Trollope, also published this way, but unlike Dickens, he never published the first word of a novel until after he had written the last.) Dickens had to consider structure carefully, thinking simultaneously of the needs of his serial readers and of those who would eventually read the books in volume form. He published his serial fiction as part of weekly or monthly magazines, which might contain material by other authors as well, or in stand-alone monthly installments.
— Dickens - Life and Career - Serial Publication -



TOC, Schwaber and Scaling Scrum (or Agile in General)

It's nice to see Ken Schwaber's comments on his blog about Scaling Scrum:

To get a good feel for what scaling Scrum feels like, I refer you to Eliyahu Goldratt’s “The Goal” (or any of his later books), or Gene Kim and Kevin Behr’s “The Phoenix Project.” You will see the difficulty of teasing through symptoms to root causes, the effort to find solutions, and the possibility that solutions have undesirable side affects.





My Dad to me: "What do you do in your job?"

I spent a lot of time with my Dad when I was back home in New Zealand this year.  He's a farmer (at heart) and I'm a computer scientist (at heart), and, honestly, we've never had anything in common work-wise, but we get along just fine.

At one stage, while sitting in his boat fishing, he asked me, "What is it you do in your job?"

I said, "Ahhh", because it's hard to enough to explain my job (or Agile) to people who work with computers, let alone a gnarly old farmer who's been semi-retired for the last 10 years and used a computer for the first time when he bought an instruction manual for rebuilding his bulldozer.  

My only option, really, was an analogy, but since my dad is a very concrete person it had to be a very concrete analogy.  I thought a moment ...

I said, 'You remember how, when I was little, you built your garage and we then lived in it while you helped the carpenter built our house?'


"You remember how we then moved into the house and, when I was about 10, you built on the conservatory?"


"You remember how, some time after I left home, you replaced the conservatory and extended the front room out and bought that huge telly?'

"Ah ha."

"And, you remember how, a few years ago, you extended my old room and put in your air-con and ensuite?  And how Mum now wants to replace the kitchen?"

"I do."

'Well, I help businesses improve themselves just like you built up your house.  They can't afford to build the whole thing perfectly up front, they don't usually know what perfect even looks like, and they want to start using their improvements this year, rather than waiting 5 years, or 20."

"And that's what you do?"


"But do you do that with computers, rather than hammers and nails?"

"We do."

Five minutes later and Dad said, "And when you do this, do you talk your 2nd son - the practical one - into becoming a builder so it's cheaper to keep extending your house?"

"We do".


I hope this helps.



Published: New Beta of Rolling Rocks Downhill.

I've just uploaded the 2nd Beta version of Rolling Rocks Downhill, my biztech novel.

So what's new?  Well, just like the latest iPad, it's 25% thinner (I reduced the word count, without sacrificing content, from 100k words to 75k).  The plot is firm and the previously thin characters are now 50% less-thin!  It's a whole lot easier to read, though it still needs to go through a proper copy-editting process before it gets published proper.  It is still riddled with spealling mistaeks, but that's coz it's a beta and (if you haven't noticed) I'm crap at spelling.  

Oh, and it still ends on a cliff-hanger, at the end of the 2nd act.  The 3rd act contains new knowledge for a most Agile (and other) folk, but the beta stands on its own, without the third act.   And that's what's got me all conflicted:  the third act could easily be either the last act of this book or the first act of "Rolling More Rocks Downhill".   I'm wondering if I should practice what I preach ...

Here it is: and



Small bets & Pilots

Tim Hartford, the "undercover economist", has written a nice article about the economic benefits of plotting and prototyping which, I think, will appeal to my Agile friends. It ties in nicely with how Zara works but it's talking about projects. 

"The option to conduct a cheap test run can be very valuable. It’s easy to lose sight of quite how valuable. Aza Raskin, who was lead designer for the Firefox browser, cites the late Paul MacCready as his inspiration on this point. MacCready was one of the great aeronautical engineers, and his most famous achievement was to build the Gossamer Condor and the Gossamer Albatross, human-powered planes that tore up the record books in the late 1970s. 

One of MacCready’s key ideas was to develop a plane that could swiftly be rebuilt after a crash. Each test flight revealed fresh information, MacCready figured, but human-powered planes are so feather-light that each test flight also damages the plane. The most important thing a designer could do was to build a plane that could be rebuilt within days or even hours after a crash – rather than weeks or months. Once the problem of fast, cheap experimentation was solved, everything else followed."

In my language, projects are a bet, and running pilots (or delivering incrementally with the intention of abandoning a bad big bet and celebrating) is loading the dice. One of the ways we load the dice is to dramatically lower the cost of failure, then fail!




Zara articles are like busses

My buddy Greg sent me this article about Zara from yesterday's Telegraph. 

My wife sent me this article about Zara from yesterday's times (paywall). 

What's up?  Nothing from Zara for years then two articles in one day. I wonder if they've realised they're this decade's Toyota and have decided to talk about it. I hope so.



Why Zara is my Agile role model - a 30 minute video

Here's my talk on why Zara, the clothing company, is my Agile role-model.   This video is from the LeanAgileScotland conference (thanks Chris!) and people seemed to like it.  I gave a repeat performance at the Agile Business Conference a couple of weeks ago and one bit of feedback I got, via the organisers, said, "More like this please!" (Though, to be fair, another said I spoke too quietly!)

It's 30 minutes long and, I think, there's a good chance you'll find it very useful!

Can you help me?  I changed my speak style a couple of years ago so that I now speak slowly, deliberately and quietly, hoping the logic and story I've spent hours crafting comes through ahead of my enthusiasm.  I'd really love to know what you think ...



But we're supposed to haggle ...

There's a scene in Monty Python's Life of Brian where someone (Brian, maybe?  I've never watched the actual movie) is running away from some Roman soldiers. He tries to buy a false beard to use as a disguise but when he hands over the full price (20 shekles) the vendor refuses to take it, insisting, that they must haggle before money and beard can change hands.  The haggling takes time and causes Brian (?) much consternation because he wants to buy the beard, put it on and run away wearing his new disguise.

You can watch it on YouTube.  I, begrudgingly, admit that it's kinda funny.

The same sought of thing happens in many Agile transformations:  our customers and our managers keep wanting to haggle even though it's unnecessary and counter-productive for all of us.  

It's understandable: for decades they've negotiated with us technology folk for a big scope and a short delivery time, wishfully thinking that negotiating a tight promise actually results in that promise being kept (!), but when we switch to Agile we focus most of our efforts on the technical changes, rather than the changes in mindset.

What can we do about this?

Well to start with, let's name things differently.   I work in a big financial organisation and one of the many things I like about working there is that our CIO is insistent (in a nice way) that we don't call our internal customers "customers".  He says they're "partners" which, when you think about it, they are.  I'd not heard this distinction before but I think it's very important.   Likewise, if you're working with external vendors or customers then make a distinction between the commercial negotiations (where you still use the "customer" word) and the delivery (where you do partner).

And, of course, when you're making a promise, make it a slam-dunk promise where you:

blatantly and transparently under-promise then, when we get lucky (and we usually do), over-deliver.



The biggest benefit of lesstimating

The second biggest benefit of lesstimating - quick, accuratish, sizing of effort, cost and maybe even benefit - is this: we can decide to NOT do some stuff because it's just not worth it. 

The biggest benefit is that we DO something else instead.