Clarke Ching's Rocks and Snowballs

Did you ever have a tune running through your head ...?

Yesterday, my long time, virtual friend of mine, Rob Newbold, founder of ProChain Solutions, the Critical Chain software, wrote this on a list:

One of my favorite cartoons is of a hooded headsman with his axe, and a guy
with his head on the chopping block who says, "did you ever have a tune
running through your head that you just couldn't get rid of?" ...

... which I just love.  Wish I'd seen the original.

Elephants can dance ...

I used to work at Standard Life in Edinburgh.  They're got a reasonably large Agile/Lean initiative going on in their IT department.  Julian Elve took notes during a talk given by Bill Birnie, the guy behind the initative, during a conference.  I've very pleased that many years ago now, while doing my MBA dissertation I printed a draft of Mary and Tom Poppendieck's Lean Software Development book and gave it to Bill to read.  He later got them across to do some training.  It's nice to hear how things have changed so much since then.

I've cut and pasted Julian's notes below:

Case Study: Agile - Why Should Your Business Care ?

I’m blogging the conference Agile Approaches for Delivering Business Value

Agile - Why Should Your Business Care?

Bill Birnie, Senior Manager, IS Development Solutions, Standard Life Employee Services Limited, Ollie LaFontan, Exoftware

Summary

    * What does my business want from Agile ?
    * Creating an Agile culture and the importance of measures
    * Consolidating gains and driving more change.

Standard Life’s award-winning use of Agile techniques is helping it achieve remarkable levels of productivity from its application development spend, and is supporting the positioning of technology provision at the heart of its business proposition.

This session will cover the importance of linking your Agile enablement strategy to the needs of your business, and the challenges created by trying to change processes and beliefs that have been in place for many years.

Notes

The values which support Agile: Communication, Feedback, Simplicity, Courage, Respect.

Every instance of Agile looks different.

Agile is not about acronyms – it is about delivering business results – functionality, timeliness, value.

IT is second biggest cost centre in Standard Life – value for money is critical – IT apps development team measure how much of what they deliver is used as a measure of value.

High expectations of leanness from the internal customer (they are award-winners so have high standards)

Deadlines vital.

Predictable process required for auditors and risk managers.

Quality – need to demonstrate

The business internal customers are not interested in the jargon!

You can’t fix it all at once – eat the elephant one bite at a time…

Early experiments with Agile – consultants who had successfully applied Lean to the Standard Life customer service division admitted they couldn’t see how to apply it to software development – so one team “just started doing it”… Courage was required to give them scope…

After success, resisted temptation to force it on others. Key reason for success was motivation – instead talked about it a lot (especially the successes), and allowed people to adopt when they were ready.

Some basic internal measures:

    * How much of applications is used?
    * Gartner says Standard Life Application Development is approx. 2.5 times more productive than industry peers (top quartile). Key contributing factors to efficiency and productivity are their advanced use of Agile and SOA.
    * Predictability – how well do they hit time, cost and satisfaction
    * Quality – sample metric McCabe Code Complexity – reduced from ~5 for legacy apps to typically 2 now.

More to do… especially level of support for teams that want to adopt Agile methods. Looking again at measurement set to provide business case for further investment in capability and leadership. Encouraging and supporting experiments, involving the business more – agile business cases etc.

Something you need to know about Cash Flow in software Development projects

Here's something that may not be obvious to we managers and engineers. It wasn't to me for a long, long, long time.  I'm interested in your thoughts.

Let's take a traditional project - called P1 - that costs $500K a month to run, runs for 2 years, and starts making $1.5M each month once it goes live.  (I'm simplifying, of course).  From a business point of view, that means it is tying up $500K * 24 months = $12,000,000 - which is a lot of money in most currencies. 

Let's take that project - call it P2 - and break it into 2 phases using little more than my powerful, author-esque imagination.  Let's say that the 1st project delivers after 9 months and delivers 750K revenues a month, then the second project delivers the rest of the original project 15 months later, and revenues now go up to the full $1.5M a month.  (I'm simplifying of course)

I've put all these numbers into this spreadsheet - include a line chart showing the projects "bank balances" (i.e. net cash flow; what the project owes or has returned to the company), which is the stuff I'm interested in.

Pop over and you'll see that P1 pays for itself / breaks-even  (i.e. if it had a bank account the balance would finally show 0) after 36 months but P2 pays for itself after only 24 (and a little bit) months.  That's great news - and if you're selling Agile, this is the sort of thing a CFO or CEO just loves.  You'll also notice that forever and ever, P1 makes a whole lot more money.  I'm pretty sure that you can see, from what you know of agile, that these numbers could be even better - better product, even earlier delivery of cash, shorter projects, increased capacity, learn from the market, first to market, etc, etc

Now, I have 3 questions coming up for you all, after a little preamble:

Remember way back when you were a student and your bank gave you a small overdraft; even if you wanted more the bank would be very frugal; it didn't matter that you said, "one day I'm going to earn a fortune as a programmer, err, developer", you still had a limited amount of cash available to you and you had to live within that cash flow.  Businesses are the same. 

Our imaginary business, can only get so much money into it's grubby little hands, so it can only do a limited number of projects.  Now take another look at the spreadsheet and look for what MAY BE the most important 2 number in Blue and Red background.  P1 is $12,000,000; P2 is $4,500,000. If each project had it's only little bank account then those are how much they are "overdrawn".  Given that these two imaginary projects are happening in the same imaginary organisation, that means that the organisation could do MORE projects if they worked like they did in P2, than if they did in P2 (assuming that they're limited by cash flow, which seems rather likely).

Now for my question(s):

Q1) Would your organisation like to do more projects?
Q2) Do you think your organisation limits the number of projects it does because of cash flow considerations?
Q3) If each project used less of your businesses cash and they decided to do more projects, what else would limit them?

It is Q3 that I'm most interested in, btw ...

Clarke Ching
www.clarkeching.com
+44(0)7920114893

Right Click button different to right click mouse?

Look down at your windows keyboard . 

Do you see the little "right click menu" button?

It does the same as "right click", right?

How come then, when I get a spelling mistake in firefox, and right click on it with the right-click-button I DON'T get spelling suggestions, but if I click on it with the right mouse button, I do?

Any suggestions?  It's driving me CRAZZZZZZZY.

(It worked okay in Firefox 2, but started not working in Firefox 3.)

Red Bee ...

I wouldn't normally point to someone else's advertising but go take a look at http://www.redbeemedia.com/ then click on the "The Big Picture" then "The Virgin Media Story", sit back and watch.  (It's flash so I can't link directly, or rather, I can't figure out how to link directly).

It's a very clever Hitchhiker's Guide pastiche ... and an advert ... and a beautifully charming and simple technical business pitch that includes the line "as it has been clinically proven that intense study of process maps makes the human brain explode".

It really is well done.  Trust me on this.

BBC Iplayer ...

Lately I've been using the BBC Iplayer to download a few BBC programs I've missed.  Very useful while travelling.  Very, very, very nice implmentation.

Now.  If I remember correctly the Iplayer was developed using Scrum (or some variation of Agile).  In fact, I'm quite sure I chaired a session at XPDay last year on the very subject.

I'd like to do a wee interview for AgileThinkers.com about the Iplayer Scrum project.  It's a great story.

if YOU can put me in touch with someone who I might be able to interview, I'd really appreciate an introduction ... clarke.ching@gmail.com.

Thanks

A Social Contract for Agile - Very important, from Israel Gat

I've just posted a short essay from Israel Gat on the AgileThinkers.com blog.

It's about what Israel describes as the "Social Contract" between software workers and their employees and how it can change in an agile environment.  It's short, it's sweet, and it is one of the most important pieces I've read in a while.

Perhaps the most difficult aspect of my leading Agile projects over the past five years has been dealing with the broken social contract. With globalization, off-shoring, outsourcing and reduction in the workforce being so pervasive, the social contract between employees and corporations in the software industry has for most practical purposes broken. The implied agreements by which employees form productive teams and maintain cohesive organizational order have at the very least been shaken, and very possibly voided altogether ...

[read the rest on AgileThinkers.com]

Software Development is like ...

ooops ... this is posted out of order because I "saved as draft" rather than "published".

My friend Rob pointed me to another little blog article about Software development being like / not like building bridges.  The comments are revealing because they reveal that most people don't seem to appreciate the true value of analogies.  They argue that the analogy is right or wrong, when the beauty of analogies is that they right AND wrong.

Analogies are powerful and useful because they make us think.  They make us think because they force us, when we think about them, to contrast two different things - like bridge building, say, and software development.  The contrast reveals where the analogy WORKS and where the analogy DOESN'T work.   Both of these are useful. 

I use analogies a lot.  Possibly too much.  I particularly like this one from an old sticky minds which contrasts the way a medical team, made up of complete strangers, formed when a guy had a heart attack on a ski slope with how software teams work.  I recall that when I was writing it I spent a lot of time thinking about what the two situations had in common and then, near the end of the article, I thought "but it doesn't work entirely as an analogy, does it" because as soon as the helicopter left the scene, the team disbanded and none of them ever saw the patient again.  I remember thinking that that's not true in most software development teams I've worked; most of them built the software, nursed it into life, then looked after it afterwards.  I doubt the medics on the scene at the heart attack emergency would have behaved any differently had they then had to look after the patient in hospital, but it does make a big difference on software teams.  My good friend Rob, a very senior technical manager for a very very big financial company, told me about stats he has which shows that the "cost of ownership" for the outsourced code is considerably higher than the cost of owning code that has been built in house, even though the outsourced code is cheaper to initially build.  It's a lot like the difference between owning and renting a car ... another analogy.

What I've found is that almost anything can be used as an analogy. I'm looking around the room here, as I type, looking for something to use as an example.  First off, I see my laptop's keyboard.  Software development is a lot like typing.  Is it?  Well, there's a lot of typing in software development, and most typing is done with the purpose of producing something useful that is more than a collection of randomly typed characters.  So there's thinking involved as well.  Software dev and typing a blog post both involve thinking and typing.  Now I look at the editor I'm using.  It's the online version that comes with typepad, my blog host.  It's a bit crappy and there are better alternatives.  So software development involves typing, tools and thinking.  But obviously, software development is more complicated than ordinary old typing; there are more connections; there are design considerations.  But then I've just spent the last 4 years typing a book ... that's a damned site more complicated than writing a computer program.  So, software development is a lot like writign a book!  But, there is a difference - I wrote the book by myself, most software is developed (I think) by teams.  But then again, teams can sometimes write a book.  The pragmatic programming book was written by two people.  So was Lean Software Development.  The Goal had two authors and Goldratt's subsequent books had ghost writers or collaborative writers.  And my book is now getting much better with the help of an editor (who acts a bit like a product owner and an inspector).  So maybe they are quite similiar. 

Time for a new paragraph.  Now some books, with multiple authors, are easier than others.  You break a book into chapters or esays which are independent of each other (loosely coupled) but share a common theme , throw in an editor, and you can produce a pretty good book - like Joel Spolskys recent anthologies.  So design is important.  My book - a business novel - is highly coupled and spaghetti like, in some respects, although it fits pretty much to the outline I wrote 4 years ago.  Some things are easy to change - for instance renaming Paul to be Brutus, will be easy, but renaming Anne to be Brutus would be much harder.  Wow!  Some things in software are hard to change too.  What do we do in software when things are hard to change?  We either avoid those sorts of things or we make them easier.  So in my book, if I thought I was going to change the sexes of my character's frequently then I'd design my book to make that easy!  But I'm not ... and I'm getting bored with this analogy.

If you haven't notice, let me point out that almost everything you are reading here is off the top of my head.  Analogies and Metaphores are hugely powerful for making you think ... that's all.

Oh and here's an edited version of the comment, that in real time, came before this, but was meant to come after.  If that make sense ...

You've probably noticed loads of typos and spelling mistakes above.  My apologies - no matter how much (or little, sometimes) I read these things I always make loads and loads of little mistakes.  It probably bothers some people.

Not to my point: one of the ways that software development is differnt to writing is that YOU CAN TEST IF SOFTWARE WORKS against specifications, you can't do that with writing nearly as easily. Interesting that you can INSPECT both by reading and how having TWO different people INSPECT the same code/writing will probably spot more problems.  But you can't execute your writing and say "Yes it works exactly as expected".  That subtle distinction should make a huge difference to how we write software ... And it's one of the reasons why DEVELOPING software is a lot like DEVELOPING a new car - you need to road test each of the individual components and road-test the vehicle, before you start manufacturing it.

Software Development is like ... part ii

If you've read my previous post, about analogies, you've probably noticed loads of typos and spelling mistakes.  My apologies - no matter how much (or little, sometimes) I read these things I always make loads and loads of little mistakes.  It probably bothers some people.

Not to my point: one of the ways that software development is differnt to writing is that YOU CAN TEST IF SOFTWARE WORKS against specifications, you can't do that with writing nearly as easily.  Interesting that you can INSPECT both by reading and how having TWO different people INSPECT the same code/writing will probably spot more problems.  But you can't execute your writing and say "Yes it works exactly as expected".  That subtle distinction should make a huge difference to how we write software ...

Fatherhood

One of my most shocking discoveries during my 6 years of fatherhood is that Snow White was not blonde, just very pale. Who knew? .oOo. Sent from my BlackBerry www.ClarkeChing.com +44(0)7920114893