contact ME

Use the form on the right to contact me.

Or email me at


123 Street Avenue, City Town, 99999

(123) 555-6789


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


Clarke Ching's Rocks and Snowballs Blog

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.

The biggest benefit of lesstimating

clarke ching

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.  

Blatantly and transparently under-promise then over-deliver

clarke ching

Why do we software folk (technical and managers) so often over-promise, then under-deliver?  

Do we think looking busy and like we are under pressure means we also look heroic and efficient, rather than unreliable and incompetent?  Or do we just enjoy stressful, hectic lives?  

What at ever it is, I wish we'd all start doing this instead: Blatantly and transparently under-promise then, when we get lucky (and we usually do), over-deliver.

I call this a "slam-dunk promise" (borrowed from my former GE colleague Paul P) and although it's the sensible and professional thing to do, it feels completely unnatural to many.