Clarke Ching - More Chilli Please

Tripe

Oh bugger.

Eating dinner in chinatown and I've just accidently ordered tripe.

Flight attendanta

I've just landed in London Heathrow. I was sat in the very front row and as we were waiting for the doors to open I said to one of the attendants "you two should start a business teaching the other airline staff how to be friendly"

She looked at me - surprised - and said "Thanks. I only ever fly BA. Don't the other airline staff enjoy their jobs?"

Simple equation; enjoy your job -> smile -> customers happy -> repeat business.

Applying the Inverted Pyramid to Agile Development

My latest Stickyminds article has just gone up on the interweb.  I'm very, very pleased with this one.

Applying the Inverted Pyramid to Agile Development
Clarke Ching

Modern day reporters tend to write their articles using what is
known as the "inverted pyramid" style. They start with the most
important information in the first sentence, followed by the next
most important, and so on. This format not only gives the reader
the biggest bang for his buck as he reads, but it also gives both
the reporters and their editors huge flexibility in their
uncertain and fast-changing environments. In this week's column,
Clarke Ching shows how modern software development techniques use
the same idea to give customers the best bang for their buck--in
equally uncertain environments.
http://www.stickyminds.com/r.asp?F=W13696

I'm inspired

Jens Egil Evensen has been using Tom and Kai Gilb's EVO approach with Scrum.  Jens has answered a few questions for me on the AgileThinkers.com blog. 

Jen's shows just how to make businesses LOADS more money with Agile.  Go read - I don't think you'll be disappointed.

New yahoo group: EverydayAgile - let's bring agile to the world.

If you'd like to do something about it - or at least, discuss the situation further - then I've setup a new yahoo group ...

http://finance.groups.yahoo.com/group/everydayAgile/

---------- Forwarded message ---------- From: Clarke Ching

Hi everyone,

One of the things that really bothers me about Agile - as a movement/revolution - is that a lot of good people are missing out on the benefits of working in an agile way because they're convinced that agile is for rocket scientists.

You and I know that isn't the case ... but that's the widely held perception.

And it keeps worse: as Agile keeps getting better and better, it also keeps getting bigger and bigger. This is great news if you're a practitioner, but if you're new to Agile, evaluating it, then Agile looks complicated, confusing and daunting. A lot of businesses miss out on Agile's huge financial benefits. What's worse is that a HUGE number of software development folk and their customers are missing out on all the "lifestyle" benefits of agile. To put that another way: millions of people's lives suck, but they don't need to.

I feel that we - the converted - need to put this right.

If you'd like to do something about it - or at least, discuss the situation further - then I've setup a new yahoo group ...

http://finance.groups.yahoo.com/group/everydayAgile/

What will you get out of joining in? Apart from some lively conversation and the chance to make the world a better place ... you'll help make the agile swimming pool bigger for all of us - that's gotta help you make your future mortgage payments.

The one thing you WILL NOT get out of this is the chance to blame "those idiots" for not "getting it".

And or Or?

A dozen years or so I managed a project where we were replacing a 3-year-old telephone banking system.  Why were we replacing it after only 3 years?  The customers loved the system and flocked to it, we were running out of capacity ... but the manufacturer - Unysis - had rather rudely stopped selling the hardware. 

Did I mention that the customers loved the telephone banking system?  The bank loved it too because it got customers self-serving themselves ... and they didn't have to employ so many branch staff. 

It was free.  But it paid for itself many, many times over. 

Our competitors, on the other hand, charged their customers a (relatively small) fee to use their telephone banking system ... so most of their customers continued to do their time-consuming but low-value transactions in the branches.  People are funny like that. 

Those other banks had "sub-optimised" their profitability by making the Telephone Banking system a profit centre. 

Now skip forward 12 years ...

Greg Fraley, Author of Jack's Notebook, writes about how Cineworld did refund the cost of a movie he couldn't see (due to a fire at the cinema) but wouldn't refund the transaction fee (which he had to pay because he booked online):

I would have to call the corporate help line for that.  I didn't make a fuss, I took the partial refund ...  Later, while eating sushi, I realize that I now hate Cineworld for not giving me a full refund. 

Greg went on to suggest several ways that Cineworld could have turned the unfortunate incident into a positive experience for their customers.

I'm on Greg's side ... and I too hate Cineworld. 

They're my local cinema and if I go to a movie which might be popular I always have this little debate with myself - should I pay their miserable little "transaction fee" so that when I get to the cinema I can get my ticket quickly from the queue-free ticket issuing machine OR should I save myself a tiny bit of money, go to the cinema and wait in their long, long queues? 

Oh what a dilemma - and all because I resent having to pay a miserable little fee to book online.  I think the fee might be 25p.  The ticket issuing machine never, never, never has anyone else using it when I get there so Cineworld must regret ever setting up their online  system.

How many more people would buy online (cheap for Cineworld) if there was no transaction fee? 

How much money could Cineworld save if people bought on line and they didn't need to employ so many staff to sell tickets in their cinema? 

I wonder how much happier their customers would be. 

I wonder how much more money they would make.

It's not a profit centre if it makes you lose money as a whole.

Edinburgh: Everyday Agile - Using agile to make LOADS more money in everyday businesses

Later this month I will run a 2 day "Agile" workshop in Edinburgh for the owners and managers of everyday software-development organisations. Note: this is about the business side of agile – selling* and delivering custom-built software for profit - it is not a technical course.

If you know of anyone who might be interested in this workshop then can you please forward on details to them?

Thanks, Clarke

* I will be running a version of this course which has been designed specifically for IT departments later in the summer.

Everyday Agile: Using agile to make LOADS more money in everyday businesses

Course Summary: How everyday businesses, using everyday technology, employing everyday staff,  can deliver LOADS more software development projects and make LOADS more money by doing just-enough agile.

This course is for anyone who currently develops software successfully using the old ways ... but want to do it LOADS better.

I've designed this course for people who are missing out on the benefits of Agile because they think it is too hard or that it won't work in their organisation.  It really bothers me that as Agile keeps getting better and better, it also keeps getting bigger and bigger.  This is great news if you're a practitioner, but if you're new to Agile, evaluating it, then it looks complicated, confusing and daunting.  It looks like you need to employ rocket scientists but you don't.

A lot of businesses miss out because agile looks far harder than it needs to.

This course is an easy introduction to Agile where the goal of the course is to get you profiting from agile quickly.  You'll soon be delivering better quality software projects, in far less time and delighting your customers too.

Selling Agile Projects:

Most importantly: the course covers not only how to do "just enough" agile, but also how to sell it to your customers.  This is important because once you start doing agile you will deliver each project in between 50% and 80% of the time it used to take you, using the same number of staff.  If each project takes, say, 33% less time to deliver than before (which is likely), then you've effectively gained 50% more capacity without employing any new staff.  If you want to realise the full benefits of Agile then you'll need to figure out how to sell that extra capacity.

The problem is that you don't (or shouldn't) sell agile projects in the same way as you normally do.  Agile is better for your customers - they'll get the software they want (not what they asked for) it'll be better quality, and they'll get it far sooner - but you'll have to sell it to them differently.  Why?

First, you're producing software which is worth more to them than what you are currently delivering but … it costs you less for your to produce it (because it takes considerably less man-days per project).  If you currently sell on a daily rate basis and continue to do so then you'll make less money per project.  You may choose to lower your prices and risk a price war … or you may chose to sell your projects based on the improved value to your customer, not your cost.  You'll discover during the course that the Agile model comes pre-built with a very effective means of avoiding most price objections.  We will adapt your current offer further (using the SPIN Selling model) so you sells the benefits of your new approach at higher margins.

Second, in order for your customers to get the most value from you, you'll have to teach them to work with you COLLABORATIVELY, rather than contractually (or even adversarially).  You need to create the collaborative working relationship during the sales negotiations, not after.

We will cover both of these aspects - probably the hardest, and most overlooked, parts of any agile implementation - during the workshop.

Introducing EverydayAgile:

For the last 4 years I've been developing a simplified version of Agile which works anywhere. It's the Agile I write about - but don't name - in my book.  I call it EverydayAgile because it is specifically designed for everyday people who work in everyday organisations.  It is entirely technology agnostic - I've used it with COBOL and with JAVA, for instance, and the principles are identical.  I've taken the 20% of Agile practices which gives you 80% of the (financial and social) results, revved them up with Lean and Theory of Constraints practices and packaged them up to give a very fast, yet simple, version of Agile which works anywhere.

So, you get yourself running with EverydayAGile and then once things are running smoothly you'll be in a good position to start experimenting with some of the more technical agile practices.  You'll continue to get better and more profitable.

After attending the workshop you will be ready to:

•    -Explain both the business and the technical aspects of Agile
     software development to your colleagues, including why it is way more
     profitable for your business and for your customers and why it is more
     enjoyable for your development team.
• Sell your first EverydayAgile project to one of your customers using
     the compelling offer you prepared during the course;
• Deliver your first EverydayAgile project, using the approach taught
     in the course.

Making Agile stick: the money side

Earlier this year a colleague and I did a "therapy" session with a small software development company where the technical staff were slowly bankrupting their company in the name of technical "agile" perfection.  They were following all the rules they'd read about in some agile book but they couldn't produce code that was technically pure enough for them to ship.
The owner of the business was devastated because he couldn't invoice, his customers were leaving him and he didn't know how he was going to pay his staff their wages.  I imagine the author of the agile book would have been horrified.

If you go down the agile road then you've got to make it a blatant financial success in order for it to stick.

Here's the example (which I've tried to make as simple, fair and representative as possible but I don't know your numbers.  Why don't you try it with your own numbers?  What kind of productivity improvement would you need to achieve to double your profits?)

Imagine a small software development company which pays their development staff £300,000 a year, has £75,000 in other costs, and earns £500,000.
What's their profit?  £125,000.  Now imagine that this company found a way of preventing expensive rework – i.e. by using agile – which meant that they finish every project in two-thirds of the time they normally take.  If you've seen agile in action then you'll know that this is a reasonable saving and many projects will finish sooner.  How does this affect their profits?

If each project takes only two-thirds of the previous effort then that amounts to a … 50% increase in capacity.  Does that surprise you?  It surprised me when I first figured it out a few years ago – I still double check the numbers.  This company can now do 18 months worth of projects in a year.  That's not bad.  Now let's say they keep their prices the same (their sales folk need a kick in the butt for not figuring out how to charge more – we'll cover this in the course) and they managed to sell half of the new found capacity.  That is another £125,000 cash flowing into their bank accounts and their new annual revenue figure is £625,000.

But what's happened to their profits?  Their costs haven't changed (let's assume they didn't need to hire another sales person to sell the extra capacity) so their annual profit has risen to £250,000  (£625,000 - £375, 000).  That's double their previous profit of £125,000.  (And they still have a lot of spare capacity left to do even better.)

They could also have doubled their profits if they finished their projects in 80% of the time and sold all of the extra 25% capacity that generated.
All but the most negligently run agile projects can achieve that.

Details

The course will be held in Edinburgh City Centre on the 27th and 28th of May and it will be limited to the first 8 people who sign-up.  It is specifically aimed at businesses which develop custom code for external customers*. The 2 day course costs £800+vat for the first person from each company (i.e. well less than 3 days worth of contract Java code) and £700+vat each for the second and third.  If, after the first morning, you decide that it's not going to work for you then feel free to head back to the office and I will happily refund your fees in full.

Email me at clarke.ching@spiceUpIT.com if you'd like to know more.

If you know of anyone who might be interested in this workshop but isn't already making more money from "agile" then can you please forward details on to them?

Clarke Ching 079 2011 4893

* I will be running a different course for IT departments later in the summer.

Global Cooling?

This article from today'sTelegraph has some interesting examples that suggest maybe the whole global warming thing has more to do with perception and headlines and (dare I say it) wishful thinking. 

... A little vignette of the media's one-sided view was given by recent events on Snowdon, the highest mountain in southern Britain. Each year between 2003 and 2007, the retreat of its winter snow cover inspired reports citing this as evidence of global warming.

In 2004 scientists from the University of Bangor made headlines with the prediction that Snowdon might lose its snowcap altogether by 2020. In 2007 a Welsh MP, Lembit Opik, was saying "it is shocking to think that in just 14 years snow on this mountain could be nothing but a distant memory".

Last November, viewing photographs of a snowless Snowdon at an exhibition in Cardiff, the Welsh environment minister, Jane Davidson, said "we must act now to reduce the greenhouse gases that cause climate change".

Yet virtually no coverage has been given to the abnormally deep spring snow which prevented the completion of a new building on Snowdon's summit for more than a month, and nearly made it miss the deadline for £4.2 million of EU funding. (Brussels eventually extended the deadline to next autumn.) ...

The one thing I know about the weather is that it changes.  I see so much "evidence" to suggest that global warming is happening and so much evidence to suggest that it's not happening that I've decided that it may be happening.  Global warming is a theory - it may be right it may be wrong.  It is not a fact.

scotty the engineer

I've just found out from wikipedia that "Scotty" - the engineer aboard Star Trek's enterprise space ship - was born in the Linlithgow, the little town where I live here in Scotland.

When I saw "was" born, I meant will be in the year 2222.

Assuming he was/will be real, of course.

Farmers

A friend sent me this joke from Ireland. I don't normally post other people jokes on this blog, but I thought this one was ingenious (almost as funny as my own). 

Here goes:

A big city Dublin lawyer went duck hunting in rural Donegal. He shot and dropped a bird, but it fell into a farmer's field on the other side of a fence. As the lawyer climbed over the fence, an elderly farmer drove up on his tractor and asked him what he was doing.  The lawyer responded, 'I shot a duck and it fell in this field, and now I'm going to retrieve it.' The old farmer replied, 'This is my property, and you are not coming over here.'
The indignant lawyer said, 'I am one of the best trial attorneys in Dublin and, if you don't let me get that duck, I'll sue you and take everything you own.'
 
The old farmer smiled and said, 'Apparently, you don't know how we settle disputes in Donegal. We settle small disagreements like this with the Donegal Three Kick Rule.' The lawyer asked, 'What is the Donegal Three Kick Rule?'

The farmer replied, 'Well, because the dispute occurs on my land, first I kick you three times and then you kick me three times and so on back and forth until someone gives up.' The attorney quickly thought about the proposed contest and decided that he could easily take the old codger. He agreed to abide by the local custom.

The old farmer slowly climbed down from the tractor and walked up to the attorney. His first kick planted the toe of his heav steel-toed work boot into the lawyer's groin and dropped him to his knees. His second kick to the midriff sent the lawyer's last meal gushing from his mouth. The barrister was on all fours when the farmer's third kick to his rear end sent him face-first into a fresh cow pat.

The lawyer summoned every bit of his will and managed to get to his feet. Wiping his face with the arm of his jacket, he said, 'Okay, you old coot. Now it's my turn.'
 
[I love this part.....]
 
The old farmer smiled and said, 'Naw, I give up. You can have the duck.'

Do you ever stop to wonder ...

... how successful Scooby doo would have been if it had been called Scooby don't?

Me neither - apart from just this once.

Dodo marketing

[apologies if you are reading this twice ... I didn't proof it properly the first time around]

Think back a hundred or so years to when the first Dodo was "discovered" and named.

If they'd called the species something other than "Dodo" would they still be around today?  Dodo kinda screams out "extinction" doesn't it ...

Now ... what if the poor Dodo had tasted sooooooo good that someone figured that, commercially speaking, it was worthwhile figuring out how to breed them so that they could sell them?  Would they still be here today?  Would be eating roast Dodo at Christmas and Thanksgiving?  All of our domesticated food sources survived because they presented a good business proposition.

Now think of an idea you've that's very clever BUT sitting on the shelf - it's on the idea "endangered list", bordering on extinct.

The "is it worth saving" filter: is the idea really that good? do you really want it to survive? 

If it's not why waste your time and other people's time?

Otherwise ...you should ask yourself "how can I make this idea taste soooooooooo good to other people that they think it's worth figuring out how to breed it and sell it commercially?"  In otherwords, how can you and they make more money from it?

Pay rates ...

I worked at a place which paid above the market average and had very, very low staff turnover. 

Sounds good for the employees .. good for the staff, right?

It was horrible.  Everyone who worked there agreed.

No one left even when they hated their jobs.  No one new, with new ideas, came in for a long, long time because they had no vacancies (because no one left).  When new people did come in they hated it because the place had no appetite for new ideas and a bunch of really grumpy, but well paid people.  Oh, and their wage bill was high too - especially when you consider the quality of output from all the grumpy people (each of which would probably have done more work, if they'd been working in a happier place, even if they'd been paid less).

Free stuf ... Can you help a doctorial student out? [Scotland only]

I had lunch yesterday with Lisa Lui, a bright and enthusiastic doctorial student at a Glasgow university.  She is about to kick off the research phase of her doctorate and that means she needs to talk to Agile managers. 

Specifically, Lisa would love to get some hands on time - days, weeks, perhaps even months - working with a Scottish based Agile team. She says she'll do it for free ... but I reckon it'd be cool if there were some way that she could earn a little money - you remember what it's like to be a student.  She's versatile, but, admits that she has little industrial expereince.  She does teach other students how to code and how to design databases.

If you are a Scotland based Agile Manager, can you help Lisa?  Do you know someone who might be able to help?

Hmmm ...

In fact ... now that I think about it, one of my big peeves is that I think that modern day software developers DON'T know enough about database design. Lisa does and she teaches it professionally.

Let's see if we can turn this into something where YOU BENEFIT lots.

Do your developers know enough about database design?  Do you think they could do with a little refresher course?  If so then Lisa would probably be willing to do free training - which would cost you hundreds, if not thousands, of pounds normally - in exchange for letting her help you out on your project.

Email me: Clarke.Ching@gmail.com if you think you can help.  Thanks!

my laptap is hot to the touch

My 14 month old laptop has recently started getting very hot to the touch.  It never used to be.  Any hints on how I can cool it down?

I read online that it might be something to do with dusty vents ... but I don't have a clue if that's true or how to de-dust my vents...   

Making More Money - example 1

My book's most blatant theme is that many, many businesses can use Agile+TOC to transform their software development teams from financial black holes into a gold mines. 

In my equally blatant on-going effort to promote my book and my own consulting services I am going to post some examples of how Agile+TOC can make these businesses much more money.

Let me give you a mock, but realistic, example.

Imagine one of CCXCO's many software development teams is made up of 10 staff each earning (for the sake of argument) £250* per day.  A little math reveals that CCXCO spends £2,500 each day to keep this team producing software. Assuming that there are 20 working days in a month then CCXCO pays out £50,000 each month on building software for this team alone.

Now, imagine that the team has just spent 6 months delivering a project using traditional methods.

The project cost £300,000.

Now, ask yourself: how much could CCXCO have saved if the project delivered a better product in 4 months, rather than 6 months?

That’s right: £100,000.

That is a lot of money even for a big company like CCXCO ... especially when you add it up for every software development team in the company.

That's the sort of saving that well most well run Agile+TOC projects can expect to achieve. 

CCXCO wasted £100,000 in that half of the year, for that team, because they didn't use Agile+TOC.

Most Agile+TOC projects can reasonably expect to finish in between half and two-thirds of the time a traditionally run project would. 

Why?  The first reason is that Agile+TOC projects they do far, far less rework.  The second reason is they build far fewer unwanted features.  The third reason, is that they force technical catastrophes (which only happen on some projects but often cause those projects to be cancelled) to happen earlier in the project when they are easier, quicker and cheaper to solve. 

Agile+TOC projects finish earlier.

Fortunately, that's only a tiny part of the good news.  More to come.

The unfortunate thing is that most businesses have no idea they are missing out on these savings.  That's one of the reasons why I've written my book.

* to convert each pound figure into American dollars using the current exchang rate, just change the symbol to $ and add another zero to the right of the orginal number.

IQ ... or lack of ... I'm losing it...

Okay, okay.  I was kidding when I said that 75% of people have below average IQ.  It was obviously a typo and I meant to say that 75% of the people who read newspapers like "The Times" on the internet. 

Oh shit.  Times readers are supposed to be "intelligent" aren't they.

Let's put it this way ... anyone who has a different opinion to me is stupid.  That's probably everyone ...

I have an MBA don't you know.

My wife's a doctor ... does that count for anything?  I claim equivalent intelligence to her by virtue of marriage.

But then again ... she disagrees with me all the time ... so she must be stupid.  Which makes me stupid doesn't it?

Have you stopped reading and unsubscribed from this blog yet?

I went to school with a kid called "Wayne Rogers" (honestly, I did) who had buck teeth.  Guess what his nickname was ...

There was a girl in the same class with the surname Cassidy.  She (honestly, I'm not making this up) had one leg a little shorter than the other.  If you don't know her nickname then you must be < 38 years old.

At school they used to call me "one eyed Ching" because there is only one "i" in Ching.

I'm losing it ... but do you notice that my spelling has improved?

We have a fancy fridge/freezer from Miele.  It beeps when we leave the door open for more than a minute.  Drives us crazy.  We called it "the fridge nazi" until we discovered that Miele is a German brand and calling it a nazi no longer seemed funny - especially since the fridge was very, very tall and white. 

Serious question: is that daft on my part? 

People and their opinions

I've tried to write this particular blog post about a dozen times during the last 5 years ... but I always get stuck and give up.  I am determined to keep it brief this time and then click save.

Here's the idea: the internet has made it too easy for stupid people to share their opinions.

Take a look at this article, written by a fully qualified doctor, and then look at the comments.

It's a sad fact - though many will dispute it - that over 75% of the population have below average IQ.  And, yet they still let them use the internet.

I'm going to click save before I delete the previous paragraph.

AgileScotland - “Extremely Profitable Programming with COBOL" - by Clarke Ching, Edinburgh, 12th of May, 2008.

AgileScotland - “Extremely Profitable Programming with COBOL" - by Clarke Ching, Edinburgh, 12th of May, 2008.    

                    

Hi everyone,

Last year I managed a very successful Agile project, despite far from ideal circumstances.

I want to share this story with you at the next Agile Scotland meeting because it shows how Agile can be used in everyday organisations, by everyday people, working on everyday technology to do better business.

 

On the first day of the project, I met with our project's key customer - a senior manager with one of the UK's largest companies - he said to me, "I don't know you Clarke, but we simply don't trust your client. We've had too many bad expereinces". Fortunately, my client had warned me to expect this and, in fact, my "promise" to them was specifically to "rebuild trust with their customer". Three months later, mid-way through the project, they flew some of their experts down to visit us, to find out how we'd achieved such a turnaround. A few days later we discovered – and fixed - our first defect. By the end of the project we had rebuilt trust considerably, we'd profitably delivered the project as promised, and in doing so the customer made tens-of-millions of pounds in extra profit.  However, we very nearly screwed up the whole thing right near the end – I'll tell you all about that on the night.

 

The project was a success despite doing many things which some niave but enthusiastic agilists say cannot or should not be done in "agile" projects. For instance:

 

• My team were working on an old legacy system made up of COBOL, ancient Oracle and rubber-bands;
• Our customer consisted of around 50 people spread across five sites, based in three countries. 
• We promised (and then delivered) to an aggressive, fixed-scope, fixed-price, fixed-date contract.

I'll repeat it: I want to share this story with you all because it shows how Agile can be done in everyday organisations by everyday people working on everyday technology. This project finished in 6 months - it would have taken between 10 and 14 months, if done the "old" way.  That delay would have cost my client the contract and it would have cost their customer tens-of-millions of pounds in profit.  Agile, Theory of Constraints and good-old-fashioned project-management did that. 

 

In this session I'll share a few of the "secrets" (things you don't read about in the currently published agile books) which saved the project, such as:

 

• How to use fear, intimidation and genuine concern to force your customer to collaborate so that they can be successful (I am serious about this: this project would have failed if I hadn't spoken one very calculated, very sincere, sentence just at the right time);
• How to build trust with your team by being lazy and getting them to do your job;
• How to do TDD with COBOL;
• And (as a special bonus!) I'll share with you the one rule we used to deliver more work in each iteration than anyone had ever thought possible. Seriously.

At the risk of sounding like an infomerical …

... But wait, there's more! Since I'm feeling rather pleased with myself about my "publishing deal" I would like to buy pizza and a few beers for everyone who comes along on the evening. 

 

If you would like to learn some new stuff from this story then I only have 15 spots so please send me an email: Clarke.Ching@SpiceUpIT.com.  We will meet in Edinburgh, starting at, 7:15 on the 12th of May, 2008.

 

Clarke Ching

07920114893
www.clarkeching.com

Linda Rising

I - along with 20 others - have just spent a wonderful day with Linda Rising, co-author of Fearless Change. She did a days training for us here in Scotland covering retrospectives and "fearless" change.  I am impressed. If you ever have a chance to hear Linda speak then take it.

Although Linda and I cover a lot of similar ground with respect to change and influence, I'm absolutely wowed at how well the patterns work as a frame work and I'm going to start using them in my own work. I'm not going to do the pattern thing justice by saying this, but simply naming something can make a big difference. Go check out Fearless Change book.

The most useful thing I learned from Linda was probably the simplest: she framed the patterns using  a (deliberately) simple scripted play which was read by "volunteers" from the audience. The play started with The Evangelist telling The Innovator about his desire to try out this agile thing he has been reading about; Linda then explained how these two roles (Evangelist and Innovator) were also patterns and elaborated on each of them; they then discussed the idea of having a brown bag lunch, which is another pattern; Linda described it and a few other related patterns in more detail; and so on. The play worked remarkable well as a training device. I am so impressed that I am going to steal the idea (the thieving bastard pattern) immediately and claim it as my own (the never leave a written confession to a crime unless you want to get caught pattern.

(From my Blackberry - and then completely rewritten on my desktop)

Text editors ...

Help!  I need to do some text editing for my book ... but I've not used a text editor for writing for years and years and years.  Essentially, I want something simple that works a bit like ms word.  I'm going to use it for editing / writing my novel ... not code ... so that might limit my options.

I use windows ... do you have any suggestions, my friends?

[Note to Rob Lally: I'm not buying a fecking Mac]

Hello world ...

Google is going to win ...

Roll your mind forward two years. 

Google provide your email, your blog reader and calendar via your browser and your mobile. 

Google provides your wordprocessing, your spreadsheeting, and your presentation software.  They look as if they are desktop based applications but that's just smoke and mirrors - the code and the data live in "the cloud" but they look like they're local because of prism and google gears. 

Google provide your movie listings (you'll buy your tickets from them by then too), your news, and (you thought I'd forgotten) your search.  Oh, and they're taking a small but respectable percentage of say 30% of all online transactions via Google Checkout.  And, a respectable feed for say 70% of all adverts ...

Google and Apple, with their board-level ties, are also streaming movies and TV into your house.

Perhaps you've already figured all of the above out ... but it was only when I saw the prism software (which makes browser based applications look like are local) and then discovered that google documents is actually easier to use (both online and offline now) than MS Office that I decided to roll my mind forward 2 years and wonder ...

I'm glad they say that they won't do evil ...

Can you recommend me?

As you know ... I’ve spent the last few months immersed in my book (and living off my savings).  Now that the book is under control ... I am, once again, available for short term consulting work.

If you are based in - or near - Scotland and you would feel comfortable recommending me then … can you help me out?

If you have friends or colleagues who perhaps need a little help to GET LOTS BETTER at delivering software projects then can you recommend me to them?

I'd really appreciate your introduction and I promise not to embarrass you:

• In the last year I've helped one extremely large company make tens of millions of pounds worth of extra profit;
• I've helped one very large company recover a disastrous relationship and in doing so make loads more money by delivering a strategic project on-time and in about half the expected time;
• I've helped two small-to-medium product development companies and one medium sized government department to figure out how to use TOC and Agile techniques to deliver software projects sensibly and profitably. 
• I've helped out a few "rocket scientists" too and I helped one hospital consultant to use TOC to reduce her department's waiting list from 23 weeks down to 12 weeks.
• Oh, and I'm on track to publish a book which business and managerial folk might describe as "The Goal ... but for software development" and I'm publishing it through one of the most respected publishing companies ever.

How do I work?   

I do Agile, but I do constraints-based agile, where my goal is to help businesses make loads more money and to help the people working in software development become much, much happier. 

I focus on helping everyday organizations and everyday people - not rocket scientists - to identify the few small changes they need to make that will give them very big improvements.

There's nothing particularly extreme or overly technical about what I do - in fact, most changes are to do with the marketing and management aspects of running projects rather than the technical.

Here are some areas where I can help:

• I can help organizations (big and small) that are considering agile for the first time but don’t know if or where to start. 
  

• I can help organisations that are trying agile but are finding that it hasn’t yet lived up to its promises.  (Sadly, this is very common).

• I can help organizations which have a big backlog of software development work to finish them much, much faster and make loads more money.
  

I'll be writing a bit more about my book and my approach shortly, but If you can help then please email me at clarke.ching@spiceupIT.com.

Vitamin pills can ...

... kill:

Researchers at Copenhagen University carried out a review of 67 studies on 230,000 healthy people and found "no convincing evidence" that any of the antioxidants helped to prolong life expectancy. But some "increased mortality".

...

Goran Bjelakovic, who led the review, said: "We could find no evidence to support taking antioxidant supplements to reduce the risk of dying earlier in healthy people or patients with various diseases.

"If anything, people in trial groups given the antioxidants beta-carotene, vitamin A, and vitamin E showed increased rates of mortality."

[from the Telegraph]

I don't find Steve Martin all that Funny ...

I don't find Steve Martin all that funny ... but I have friends who do.  Go figure: I have friends.

Steve Martin shares the story of his long and fraught rise to fame in the Smithsonian Magazine. It's a long story, not funny, but touching.  I'm glad I took the time to read it.

I loved his movie "LA Story" though.

Rolling Rocks Downhill - has a (very good) publisher!

Although I've not physically signed the contract yet, I've verbally agreed to publish "Rolling Rocks Downhill" with The Pragmatic Programmers. 

I had decided to self publish .. but only because I'd heard a lot of negative talk about publishing companies (from a number of authors I respected).  But then Jared Richardson, co-author of Ship It!, started telling me all sorts of wonderful things about working with the pragmatic programmers.  I asked around and others - authors and readers - said the same.  They've decided to take a chance on me and I've decided to take a chance on them.

The bottom line is this: I'm very, very, very pleased to find myself in such good company.