contact ME

Use the form on the right to contact me.

Or email me at clarke.ching@gmail.com

           

123 Street Avenue, City Town, 99999

(123) 555-6789

email@address.com

 

You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

photo_887_20120407.jpg

Clarke Ching's Rocks and Snowballs Blog

Published: New Beta of Rolling Rocks Downhill.

clarke ching

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: amazon.co.uk and amazon.com.

Small bets & Pilots

clarke ching

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

clarke ching

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

clarke ching

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 ...

clarke ching

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.