Clarke Ching's Rocks and Snowballs Blog


How to make video if you're not very good at visual stuff.

My brain is almost fried.  I spent most of today creating a "draft" video/movie to share around work. It's a simple story about some really impressive improvement work done by one of our teams over the last year.  It features, as most of my stories do, a bottleneck.  

The hard bit is telling the story in just 2 or 3 minutes.  It'd be far easier if I had an hour ... but then no one would watch it.


Although, as many have commented, I was clearly born with thought-leading fashion sense, I'm actually not a very visual person.  To compensate, I've been using the techniques from Dan Roam's Napkin Academy.  I spent a bit of my Xmas break working through his (paid) online training and I love his approach.  It's visual, but you don't have to be good at visual stuff!

The mechanics are simple enough: 

  • I'm using the Screenflow software on my mac to record me scribbling pictures on keynote on my iPad;
  • I'm recording some amateur- (but not too amateur) looking video using my iPhone.
  • I'm editing them together using Screenflow.

The hard bit is writing the script so it's QUICK, but still interesting.



Bank often

Do you remember the TV game show The Weakest Link?

From Wikipedia:

    The original format features a team of contestants who take turns answering and elaborate general knowledge questions. The object of each round is to create a chain of consecutive correct answers to earn an increasing amount of money for a communal pot within a specific time limit. The number of "links" in a chain are equal to the number of the contestants at the start of the show. An incorrect answer breaks the chain and loses all the money accumulated up to that point; however, a contestant can say "bank" prior to their question being asked, the accumulated money is stored, and the chain resets to zero.

I'm not sure who started it but lately I've heard a handful of my colleagues talk about "banking" the value generated by our Agile projects by releasing several times during each project's execution.  Often, but not always, that's a great way of making more money - it has the opposite effect of banking in the game show. 

So, maybe the next time you're encouraging your business folk to ship often, consider reframing it as "banking" the value you've already built up. 

I wish I'd thought of that ... I work with some clever people.  



1 Comment

What's your product?

Perhaps a silly question* but, assuming you work in software development, is your product (a) the software you create, or is it (b) the team which produces that software? 

Me? My product is the people who answer (b).  




*I dont actually think this this is a silly question

1 Comment


Johanna Rothman's Foreword for RRD

Johanna Rothman is one of my Agile heroes. Her books are superb. Her blogs are always eyeopening and informative. Plus, she's a downright lovely person. Can imagine my delight when she agreed to write the foreword for Rolling Rocks Downhill?  

You’ve seen this movie before. You’re on a project. You’ve been told to work faster, better, and cheaper. No more “pick two out of three.” No. You need to deliver all three out of three. Especially the faster part.

Maybe one of your teammates or someone in management has the bright idea that maybe transitioning to agile or lean will help. Maybe it does in some small way. But, it’s not enough. You’re on a death march, iteration by iteration. Or, with your board, you can see that you are making progress, but you’re not working “fast enough.”

Or, you’re not delivering what your customers need. You’re still trying to “do it all.” Why? Because it takes you forever to release anything.

You know there’s another piece to this. You just don’t know what.

You need to read Clarke Ching’s Rolling Rocks Downhill.

Clarke delivers the goods with this business novel. You can see how Steve, our hero, learns about small batches, reducing work in progress, and bottlenecks. You can see how management’s typical “motivations,” such as management by objectives, doesn’t work in a team-based complex adaptive system, such as a software project.

Learn how Steve, a middle manager, who is part of the dysfunctional system, learns about small batch sizes, work in progress, and bottlenecks. He slowly learns what they do wrong. He makes changes slowly—just as you would in real life. The teams learn how to change slowly, just as they would in real life.

His management doesn’t understand what’s going on. They alternately threaten and reinforce his efforts. I see this occur all the time. The teams are so tired of working the old way, they are ready to try anything, because they can’t stand the idea of another death march project and being blamed for failure.

And, because you see all of this, you will root for the team’s success, as I did. You’ll understand the mutiny, when the project manager pushes the team one too many times. And, if you have not seen the magic of how agile, lean and Theory of Constraints can actually work in organizations, you might be surprised when the team pulls off the “impossible.”

You might think this is impossible, or because it’s a business novel, this is fiction. It’s not. I’ve seen and coached normal people, on normal teams, working normal hours, as they transition to working in this way, complete projects again and again. Clarke shows you the secret sauce.

Do you want a way out of your insanity? Is it time for you to learn how to take control of your projects, and learn how you can release a product your customers want, when you want to release it, a product that works?

You can. Read Clarke’s Rolling Rocks Downhill. You will have many “aha” moments. You will say, “Now I get it!” This book will change how you look at projects and what you think you can do about the predicament you are in.

Use the ideas here. Don’t start another death march project. If you find yourself in another impossible project, where your management wants it “faster, better, cheaper,” use this book. You will limit your work in progress, make your chunks of work small, and find your bottlenecks (to name just three of the tools) to make your project possible, instead of impossible. You don’t need to be extraordinary. You need to be diligent.

Have fun reading. I did.

Johanna Rothman, author of Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management

Arlington, Massachusetts



How much soup?

We tend to over complicate our lives, in project land, by trying to estimate "accurately". It's better to accept two things: first, we can't estimate perfectly but, second, we can work in ways where estimating imperfectly doesn't matter and where we can get better at estimating. 

Today I made myself a rather nice Italian Sausage and Tomato Soup for lunch using my rather nice Soup Making Machine. I ate about half for lunch but then when I went to put the rest in the fridge, I couldn't decide what size plastic container I should use. To out that another way, I couldn't estimate how much soup there was and what sized container it would need.  If I'd done this before then I probably could have guessed more easily. 

So what did I do?  I erred on the side of caution and picked a container, from the many, which I hoped would be a bit big. I hoped to avoid the cost of having to unnecessarily dirty a container that was too small. 

You can tell from the picture below that I got lucky. My "slam dunk" container is, actually, quite full. In Agile terms this is a bit like "under promising then over delivering, blatantly and transparently" and getting unlucky, but not too unlucky.  If you worked in 3 week long sprints then maybe you finished a couple of days early and had room in your container to pull forward some work - to start your next spring early.  


I'm happy I didn't spend a whole lot more time trying to pick the perfect container up front. I might still be there now doing that. 

I like to think, too, that the next time I need to store soup I'll have a little history up my sleeve, having calibrated my "soup estimating brain" a  little and next time I'll make an even better estimate.  We will see. 



The development engine

Don't over-think this little picture, okay, but when I'm working with teams which are new to agile, or new to me, then I like to draw them some version of this picture. 


It's a picture of the development machine and, depending on your own setup you can add different roles to the diagram as suits. 

The three rules are: 

1.  Don't put poor quality fuel in the fuel tank - it'll just cause rework and it'll lose you productivity. 

2. Try really hard to not run out of fuel

3. If you do run out of fuel, improve your system, but don't just keep people inside the engine room busy by feeding them low-value fuel. 

You might draw your machine differently and you might have different rules. My intention is to show people how to think with a TOC mindset without needing to know TOC. 




American or British English?

I asked my editor to use US, rather than UK, spelling. I'm sure I'll get hassled about it but I had to choose one and one of wee books on publishing said I should use US spelling. 

So there will be more zeds in the book than expected.  

But - or should I say butt? - since the book is set in the UK (in a fictional Scottish city called Watt's Bridge) I needed to stick with UK dialogue. So we've stuck with ARSE rather than ASS.  I tried to write around it - ie choose a different word - but, really, if you gonna call someone an ARSEHOLE (or even an ASSHOLE) or say that something is HALF-ARSED then there just aren't any appropriate synonyms. 



Packing Peanuts

There's this bit in one of the episodes of The West Wing where Jed explains to his wife Abbey that, when choosing prisoners to pardon, they pick a lot of low profile cases to hide, or protect, or insulate, other prisoners who they'd prefer no one else notices. The president calls these low profile cases "Packing Peanuts". 

Customers of traditional software development projects do something similar: they include a lot of low value requirements so that, come descoping time, they can descope them, look unhappy about it, say they've descoped some requirements, but protect their more valuable requirements. 

I never had a name for those requirements until a couple of weeks ago.  Packing peanuts! 




How do you teach 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 -