Clarke Ching's Rocks and Snowballs

Keeping our options open

I'd never specifically thought of the idea of "options" until I discovered the concept in lean and agile writings.  Now, I find the concept keeps popping up all over the place.  For instance,

• One of my best friends, a mature student and, like myself, another Kiwi living in Scotland, is nearing the end of his Open University training (2 software courses, 1 database course, all very very very high marks.  Now looking for a job in the real world - if you know anyone that might be interested, in the UK or New Zealand, then please email me) and he is now planning how to find a job. 
• He wants to stay in Scotland, preferably, or the UK quite happily, but we both think it will be harder for him to find a trainee/graduate job here (compared to a local) so he's also considering returning to New Zealand and looking for work there.  That's two options to start with.  He's exploring both at the same time.  But not making any decisions until he has to.
• Returning to NZ is risky because he has been supporting his study by working minimum wage jobs and the flight alone will wipe out his savings.  So, keeping his options open again, he's finding out if he can cross-credit his OU courses to a NZ degree that he can start soon after returning (and where, as a mature student, he'll get a reasonable government grant) AND he's also preparing to email his CV to recruitment agencies several months before he will return.  If, after a certain date, he doesn't get a UK job, then he'll enrol in the university course.  And, if if he gets a job in the UK or NZ before the course starts then he'll forfeit the enrolment fee (which is feck-all). 
• Then after another date, if he still doesn't have a UK job he'll book his flights.  If he's got any sense he'll pay slightly more for a flexible ticket so that he can keep his options open. 

I'm taking a similar approach with my own situation: (1) I've been approached about a potential dream job (I giggle when I think about it) in the US, but that's not yet certain, and since my wife probably can't work there it could mean a big income drop for us on top of being very remote from her family; (2) I'm planning to write an "agile" book (but don't tell anyone because I might not yet - it is only an option.  If I do it'll probably be a Goldratt-style novel, so if you want a bit-part give me a yell) which I can do as I progress the US dream job application; and if after a few weeks I realise that I'm not good at writing books then I'll either (3) hand over my story-line to an author friend and pay him to turn it into a novel or (4) find an ordinary contract job as an analyst, since the market is looking pretty good.  Probably, I'll end up cleaning peoples windscreens at traffic lights.

If you don't think about your decisions as a series of options then it's so so tempting to pick a solution and run with it just to avoid the ambiguity and scariness of the situation.  After all, action and decisiveness feels good.  But, the beauty of the "options" approach is that for a small price you literally "keep your options" open so that you can make the best decision as late as possible - and then you actually have less ambiguity, higher odds of making the best decision, and lot's of fall back positions just in case.

Thats why I hate so much forcing our customers to put a stake in the concrete early on in our software projects.  If, instead we worked in small increments, where the cost of changing stuff that hasn't already started is virtually free then we can keep our options open until the last minute, keep our customers thrilled, learn as we go, and - hopefully - make lots more money in the process.

Hey ewes!

You may not be able to teach old dogs new tricks.

Tigers may not change their stripes.

And these clever sheep are no one-trick-ponies.

FDD - the ugly duckling?

update: fixed archetypes, color, etc link.  Thanks to DeanG for pointing it out...

Last week David Anderson very kindly gave a fascinating presentation about FDD to our AgileScotlanders group.

I've always intuitively liked FDD - even though it's not sexy sounding XP - and now that I've seen David's talk, I want to find out more. 

But learning FDD seems tricky.  First, it's hard to find information about it and, second, it's ability to "embrace change" hinges on the proper use of Archetypes, Color, and the Domain-neutral Component UML modelling - skills I don't have.  Hmmmm.

If it can get over these hurdles then I think this ugly duckling may yet grow up.

 

Spare any change?

Over the last few months I've had an off-and-on sore back and more headaches than I'm used to.  My wife, a psychiatrist, blames stress.  I blame my wife.  And my daughter.

Let me explain ... I'm currently going through a few small changes - voluntary redundancy, the horrors of job hunting, potential relocation, etc - so a little stress is expected. But, previously, I've always coped well, if not thrived on, these sorts of ambiguities - e.g. I'm currently living in my 6th city and my 3rd country - so moving is more the norm, than the exception.

Things are different now and have been ever since my sphere of responsibility grew to include my wife and daughter.

My current job kinda sucks . Now, when I was 25, I would have packed my bags within months and found a better job - moving if I had to.  But now, my wife has her own career and our beautiful daughter needs to be feed and shod, so I've can't just pack up and leave any more. 

Don't get me wrong: this isn't a complaint.  It's just a fact.  I'm much much happier now than when I was 25.  In fact, this is a conflict that I've been conscious of for about 5 years now, and I've been working on it since.  Its a conflict between our family's need for security and comfort and my need to enjoy my work.  I have to have both of these things to keep me happy.  To satisfy the need for security and comfort I took a job that paid well, the downside was that it wasn't - on the face of it - particularly challenging. 

 There are many ways to consider how to break this conflict - the most obvious being to find a job that was fascinating, challenging, secure and paid well.  (I had one like that once but then the company got bought and the IT department was broken up - I ended up working as a marketing manager, of all things!).  But, although I looked I couldn't find any interesting alternative work.  In fact, being stuck in this conflict was being a bit like being stuck in quick sand because the longer I was in it the less secure I felt about myself and my job prospects, so the more I clung to the safe job I had.

Ironically, since I've moaned about it a bit, the thing that kept me going was my MBA.  Although my job was bringing me down, getting good marks with the MBA helped me keep my head above water.  In fact, my job provided excellent fodder for my assignments and especially for my dissertation.  Hopefully, the MBA, and all the hard work I've done for my dissertation will finally help me break this conflict help and find a job that is both secure and exciting.  Fingers crossed.

... Otherwise in a two weeks time I'll be "embracing change", if you can spare any, outside Edinburgh's Waverly Station.

Help!

**** UK and Ireland only  - preferably Scotland ****

From August 9th I'm going to have some spare time while I'm finding a new job.  I'd like to put this time to good use.

Could you spare me an hour or so for a chat, preferably during your working hours, about

• How you "do" agile
• How you sold/influenced/persuaded your organisation/customers/team to adopt it

Obviously ... It would be helpful if you're actually a practising agilist (not just a wannabe like me!) and it would be even better if you're located within the central belt of Scotland so I can visit you on-site, otherwise I'll phone you and maybe visit (if I can afford it).

I'll write up a brief case study about each site and hopefully turn it into an article or two, that I'll share via this blog.  I can keep things anonymous if you prefer.

Please contact me by leaving a comment, or emailing clarke dot ching at gmail dot com (or click on the spam protected email link on the left).

 

Hmmmm ... If you take

Hmmmm ... If you take a look at Barry Boehm's classic Software Engineering Economics (which cost me an horrendous £35 second hand) on page 40 he shows the "Cost of Change curve".

Now, I've often wondered what a "change" actually is.  This is one of the reasons that I bought the book.

On page 39 he says that the cost of change shows the

"... the relative cost of correcting software errors (or making other software changes) as a function of the phase in which the corrections or changes were made".

So now you know.

An experiement.

In my last post I did some maths, based on various published averages, that suggests that an average, medium-sized project that allows change will take roughly 13.5 times longer to complete than if it didn't.  So, for project X, if we built what was asked for it would take (say) 1 month, but if we allow changes, then it will take (about) 1 year.

Hmmm: 1 month vs 1 year.  That doesn't sound right.  I think I'm missing something.

Proposal:

But ... when I think about it backwards, that means that if we took a completed project that took 1 year and rebuilt it, as is, we should be able to rebuild - from fresh - in just 1 month.  Still doesn't sound right.

If only we could conduct an experiment or two to test this ...

• Has anyone just completed a 6-month project? 
  Do you have 2 weeks to spare? 
  Could you rebuild what you've just built
• How about a 3 month project, with 1 week spare to rebuild it?
• Or even a 12 month project, with 1 month spare to rebuild it?

Does anyone think this is possible? 

Have I gone wrong somewhere?

Quantify the cost of reworking bugs?

Yikes ... while I was looking at Barry Boehm's classic Software Engineering Economics just then, I looked a little closer at the cost of change curve and I realise where I went wrong when I calculated the factor of 13.5.

Choosing 50 as the average cost of change is too high.  That assumed that most of the project's requirements changes occurred in Acceptance testing, which is daft.

A quick summary of the data points from the curve:

Phase	Approx Relative Cost (midpoint)
Requirements	1.5
Design	4
Code	10
Development Test	20
Acceptance Test	50
Operation	100

When I rework my calculation using 20 as the average cost of change, it gives us:

a medium-sized project with 25% change takes 5X as long to complete [i.e. X + (.25 * 20) X = X + 4X = 5X]

So, working backwards, a year long project could be completed in about 2.5 months if rebuilt retrospectively.  That feels a little better. 

But.  It's still only taking into account the requirements changes and we know that the cost of change also applies to bug fixes.  If we could prevent all bugs, or at least find them much sooner, then that 2.5 Months would be much smaller still.  Does anyone have any figures they could share that quantify the cost of reworking bugs?

Waterfall logic - cost of change again.

If

• (a medium-sized project with absolutely no change takes X days to complete) and
• (about 25% of requirements change on the average medium project - according to Boehm and others) and
• (lets say the average change, using Boehm's cost of change curve, takes 50 times the effort to change - it might be more, it might be less, depends when it happens)

then

• a medium-sized project with 25% change takes 13.5X days to complete [i.e. X + (.25 * 50) X = X + 12.5X]

Therefore, if we want the shortest project possible then we must prevent change up-front.  Even if it takes a bit longer to get it right.  If only that were possible.

 

Oh bugger ...

I've not mentioned previously mentioned this topic here, but since many of my friends read this blog and they know my secret, I thought I'd mention it here.

I didn't get the job in London.