BDD done differently

BDD is brilliant, but please don’t look at it too narrowly.  

* Using the given-when-then template is good.

* Automating some tests is good.

* Having chats, in order to understand what you are building, before your build it, is just brilliant

But, look, if you’re considering doing BDD, start with a start with the pre-building-stuff chats, hold off on the automating, and as well as asking “what tests?’ add these questions:

- how are we going to execute all this testing?  Can we do any of that in parallel, such as setting up environments or test data, while the development is being done?

- what’s going to make it hard to test this stuff? 

- who’s going to test? Can we share the test execution?

- is there any duplication of testing effort? Can we get rid of 80% of that duplication, without sacrificing quality?

- are there any tools / scripts /automation the developers use, that others could use? 

- is there anything that’s reallllly hard to test? Can we automate that? Can we safely avoid testing it?  how else can we make it easier to test?

- do we really need to test everything? Really? Really?

- are we testing enough? 

- do we really have to automate this?

- why the hell does a tester even need to look at this? Don’t the developers know how to test their own work? 




What are Bottlenecks? (Andy Grove)

 (I’m currently stitching together my new book, The Bottleneck Rules, and every so often I’ll share some of the content. I particularly like this little example (which was first published the year before The Goal)  - it gets the most important lesson from The Goal across quickly, using an everyday example most folk can relate to.  Please share with your friends.)

What are Bottlenecks?

Eli Goldratt’s The Goal is about bottlenecks, as well as a whole lot of other stuff.  I’ve found, over the years, that the other stuff is easier to understand when you already know what bottlenecks are. So here’s a simple example to get you warmed up.

Have you heard of Andy Grove?  He was the CEO of Intel Corporation. Time Magazine named him 1997 Man of the Year. When Steve Jobs was considering returning to Apple, he called Grove for advice, saying he was someone he 'idolised.'  In 1983 - the year before The Goal was published - Grove published a book, High Output Management, aimed at teaching middle managers some of the management principles Grove had learned during his time at Intel.  He started his book with a deceptively simple manufacturing example that illustrates the idea and importance of bottlenecks—or limiting-steps, as he calls them.

Grove was a brilliant teacher, and his example was based on work he did as a hotel waiter while studying chemistry.  He used the example of serving a breakfast made up of coffee, toast, and a three-minute boiled egg.

He starts by putting a simple schedule together so he can figure out two things: (a) the best sequence to prepare the meal and (b) how long it will take. 

Here are his inputs. See if you can come up with a good schedule: It takes 1 minute to make the toast, 20 seconds to pour the coffee (from the pre-made pot), and 3 minutes (unsurprisingly) to cook each 3-minute egg. Once they’re all cooked, it takes another minute to serve them.

Most people decide to put the egg on first, then cook the toast and then pour the coffee while the egg is cooking. That’s what Grove did. He started his scheduling by looking for what he called the limiting step. In this case, it’s the longest step: the egg boiling. He places that step at the center of his schedule, then staggers the other tasks around it, doing work in parallel where possible. It takes 4 minutes.

Now, that’s great if you’re cooking one egg.  But you’re not. You’re in a hotel, and you have to feed dozens of guests each morning. And most of them want eggs.

Andy Groves breakfast - Gantt.jpg

Grove asks a simple question: 'What would happen if you had to stand in a line of waiters waiting for your turn to use the toaster?' And then he answers it: 'If you didn’t adjust your production flow to account for the queue, your three minute egg could easily become a six-minute egg.'

In other words, in this scenario, the egg boiling is not the limiting step—it’s the toaster.

Let me make up some numbers here.  Let’s say the waiters can easily boil up to 200 eggs an hour and they can easily provide 400 cups of coffee, but they only have capacity to toast 90 slices of toast each hour.  That would be okay if the demand was, say 50 per hour, since that’s less than 90 slices, but clearly, given the queue of waiters, demand is higher than that.

So now we need a new diagram, one that shows the flow of Grove’s little breakfast factory.

Andy Groves breakfast -flow.jpg

That makes it clearer, doesn’t it? The toaster is the bottleneck.

So, back to Grove’s question, 'What would happen if you had to stand in a line of waiters waiting for your turn to use the toast?' 

I can’t speak for you, but I’d buy another toaster.

However, that’s easy for me to say, since it’s not my money I’m spending. And for all I know, hotel toasters are unusually expensive (which could, I suppose, justify their excruciatingly expensive WiFi). 

Perhaps a more sensible first step would be to see if they could squeeze a bit more capacity out of the current toasters. 

Maybe, for instance, the toast would still be considered brown enough with 45 seconds of toasting instead of 60 seconds?  That would give them a whopping 33% extra capacity for free, lifting their 90 slices an hour up to 120.  Perhaps they could promote a waiter to be Chief Toaster, with the job of keeping the toaster working as productively as possible. If it were me, I’d leave copies of the Dr. Atkins low-carb diet book on the breakfast tables and instruct the waiting staff to greet the guests with a cheerful, 'Has Sir put some weight on since his last visit?' as they arrive. Perhaps that might reduce the demand for toast. 

The point Grove makes is this: timings are important, but so is capacity.  Rather than building their schedule around the egg boiling, they need to prioritise the toasting, do whatever they can to increase their toasting capacity, and stagger the egg boiling and coffee pouring around the toasters.

Now, on to the story!



Old Ice Cream Containers

This is my pup Georgie playing with her favourite toy: a beat up old ice cream container she found in the garden when we moved into our new house.



She's got loads of other toys.  Loads of 'em.  We bought them all from a local pet store.  There are pink ones, green ones, brown ones.  There are ropes. There are balls.  Some squeak.  Some really squeak. Some don't squeak.

But none of them compete with that ice cream container.

We found the same when we had kids.  We went out and bought one of everything.  Cost us a fortune.  Didn't need most of it.  Probably the most useful thing was an old blanket we hung up over the curtains to keep the lights out, so the babies slept better.  We should've bought proper black-out curtains but we couldn't afford them coz we'd spent so much on all the other crap.  

More and more, as I get older and older, I'm finding that it's the boring, basic tools that's always worked that work best for me.  White board markers.  Pen and paper.  Excel. Old, tried and trusted books.  And, of course, conversations.

It bothers me that so many Agile transformations seem to start by trying to do the newest, shiniest things and by installing complicated software.  My role-model for how Agile teams should work is the first team I worked on, way back in 1992.  It was managed from a big old book, which was essentially a prioritised to-do list.  We worked on mainframe COBOL.  We didn't have testers so we programmers tested the arse of everything before we shipped.  When we needed to ship we rang the operators (on a thing called a phone) and they released our well tested software.  We all talked to each other, asked each other for help, and we chatted to our customers, a lot.  We only automated what made sense.  And, we laughed. 

For me Agile starts with 4 things: (1) relentlessly prioritise then (2) deliver small chunks of well engineered, thoroughly tested software and (3) make space to improve.   If you need to deliver stuff on time, then (4) plan pessimistically and pull stuff forward when you get lucky.

That's pretty basic.  It's not sexy. 

It's not even as cool as on old ice cream container, but repeat that over and over and it works.  




Theory P and Q

Do you know about Douglas McGregor’s Theory X and theory?

How about Theory P and Theory Q?

Just in case they’re new to you, Theory X managers assume that “workers” are lazy and can’t be trusted, and treat them accordingly, whereas Theory Y managers assume workers are self-motivated, good people, and they treat them accordingly.  See below for more detailed descriptions*.

You can imagine that, in Agile (or anywhere actually) we’d like it if most managers had lovely Theory Y thoughts running through their heads.

Well, lately I’ve been developing two similar theories: theory P and theory Q.

Theyre not about managers. They’re about workers and the theories they have in their heads concerning managers.

  • Theory P workers think managers are stupid and out to get them, to exploit them, to bully them. They behave accordingly.
  • Theory Q workers think managers are clever, but have hard jobs, and try to do their best. They behave accordingly.  

You can can imagine that Agile is much easier to adopt with more Theory Q folk in the building.


Here’s the big question: How do you get more Theory Y and Q people working in the building?  



* From Wikipedia:  

  • Theory X is based on pessimistic assumptions regarding the typical worker. This management style supposes that the typical employee has little to no ambition, shies away from work or responsibilities, and is individual-goal oriented. Generally, Theory X style managers believe their employees are less intelligent than the managers are, lazier than the managers are, or work solely for a sustainable income. Due to these assumptions, Theory X concludes the typical workforce operates more efficiently under a "hands-on" approach to management.
  • In contrast, Theory Y managers act on the belief that people in the work force are internally motivated, enjoy their labor in the company, and work to better themselves without a direct "reward" in return. Theory Y employees are considered to be one of the most valuable assets to the company, and truly drive the internal workings of the corporation. Also, Theory Y states that these particular employees thrive on challenges that they may face, and relish on bettering their personal performance. Workers additionally tend to take full responsibility for their work and do not require the need of constant supervision in order to create a quality and higher standard product. 



1 Comment

Not my friggin' circus, not my feckin' monkeys

A few years ago I learned an amazing expression from my amazing Polish friend called Patti.  

It's become a bit of a mantra for me.  I need to share it with you. 

It's one of the tools that helps me deliberately care less

Here's how I use it:  Whenever I feel the problems of the world weighing down on my shoulders, I go sit atop my guru mountain (where I'm wearing no more than a loin cloth and my spectacles, if it helps you visualise this) and I just sit there and repeat the expression over and over to myself.

  • It's not my circus, they're not my monkeys
  • It's not my circus, they're not my monkeys
  • It's not my circus, they're not my monkeys

Occassionally, I vary things a bit:

  • It's not my friggin' circus, they're not my f**kin' monkeys
  • I've got my own circus, I've got my own monkeys.
  • They're not my friggin' problem, and I can't fix 'em.

Now that I understand what the expression means and why it's important, usually, a simple repetition of the stock, standard expression, backed up with a shrug, is good enough:

  • It's not my circus, they're not my monkeys 
  • It's not my circus, they're not my monkeys
  • It's not my circus, they're not my monkeys

 And then, once the message has sunk in, I climb back down the mountain, put my clothes back on, and go back to work where (mostly) I focus on doing good for my own circus and my own monkeys, and not getting heat-up about other people's circuses and their monkeys.


1 Comment

1 Comment

Technology Ruins Lives????

An unfunny joke, with a point:

An Irish woman walks into a bar. The barman - an Australian - says, 'Sorry, but you can't stay here unless you speak English.'

She says, 'Even though I'm Irish, I grew up speaking English as my first language. Plus I learned Irish as my second language. Also, I have 2 degrees, both of them were taught in the English language.'

'None of that matters, mate', said the barman.  'You have to pass an English test to stay here.'

"Okay. What do you want me to do?  Shall I just keep talking? Would you like me to read something to you?'

'Nope. You have to pass an automated test. A computer test.'

'A computer test?'

He pulls out his iPhone, then says, 'In a moment, it'll ask you to count to 4.  Just do that, make sure you speak clearly into the phone's microphone, and provided you get over 80% correct, you will be allowed to stay here and have a drink with us.'

He pushes a button on the screen, hands her the phone and counts





And moments later, she gets 75%, and is kicked out of the bar.


Recently, in the real world, an Irish woman - a veterinarian who spoke English as her first language, and who had 2 degrees - was declined permanent residency in Australia because she failed an automated - i.e. Computerised - English language test.

I don't know more than that but, given the high odds of false-negatives, you'd've thought they'd've built in robust manual alternatives.

If you're gonna automate something ... make sure you don't ruin someone's life. 


1 Comment


Commitment - what does it mean?

There's a lot of discussion in Agile land about whether people should commit to stuff, or not.  Loads of opinions  I thought I'd share a few of my own, though none of them are prescriptive.

I once worked for a consulting company, 10 years ago,  where we helped companies "build trust" by teaching them how to make commitments that their customers loved, and which they could keep. It was based on the work of a guy called Fernando Flores - a huge thinker - and it was called Commitment Based Management. I base my thoughts on commitment from what I learned there.

A few points:

1. Making promises then not keeping them destroys trust.

2. Good Promises/commitments are the result of conversations - not always easy ones.

3. Forcing someone to "commit" isn't the same as someone committing.

4. Forcing someone to over-commit is often used as a motivation tool. That doesn't work very well, short or long term, and there are many other ways to motivate people.

See "The Progress Principle" by Teresa Amable

5. The bottom line in Agile is that we should "under-commit, then, when we get lucky, over-deliver". We do that blatantly and transparently and as part of a conversation with our customers.  No game playing needed  

6. Teams which constantly over commit are constantly failing, and always under productive.

7.  We humans seem hard-wired to over commit.



how to get your ducks in a row - a short, silly parable about a duck

I live in a sunny and beach-abundant part of New Zealand called Nelson, but I travel to work (mostly in Wellington) a few days each week. Most weeks, when I'm home, my wife and I go for a nice long beach walk while the kids are at school and most normal people are at work.

This week, we met a duck on the beach.


He was just standing there, all on his lonesome.

I said, 'Hello Duck'

He said nothing.

So I took his photo and we continued our walk, and I started thinking about ducks and how we get them in a row.

If you've only got 1 duck, it's easy to get it in a row, coz it's only 1 duck.

If you've got two it's just as easy. Rows are good like that.

Introduce a 3rd, however, and it's a whole lot harder, unless the ducks are hanging from a hook in a Chinese restaurant, or made of plastic.


But, maybe, rather than killing the ducks, or using fake ducks, maybe its better to think more laterally (whatever that word actually means), change your goal, and line them up in a triangle.

In fact, rather than saying you've changed your mind, you can just say you're a lean startup and your experiments indicate you need to "pivot" and, so, there's no egg on face.

Introduce a 4th duck and your triangle is bit screwed (or, if you contract, "forth duck", you could say it's f'ucked).

Yes, of course, you could arrange them as a square, or a rectangle, but, honestly, there comes a point where, if you just keep pivoting all the time it starts to look like you're making things up as you go.

So, perhaps, rather than pivoting, you should try a little Taylorism.

You could glue your ducks' feet to the floor.

Or not.

Perhaps you could pop them in cages. Or cubicles.

So long as they get out of their cages for an hour each day you could claim they're free range and charge 30% more for their time  


Scaling ducks is tricky.

Why don't we try lining seagulls up in a row, instead?

Seagulls, you exclaim!  Surely seagulls are less controllable than ducks!  

Good luck with that.   



Yes, that's what I thought.

But ... well, look at this. 


It took me two hours to get these guys lined up. I had a bit of trouble with the 3 at the back, but, still, I'm rather proud of this.

But, back to ducks.

Clearly, the ducks aren't going to line themselves up as we scale, so, obviously, we're gonna need to employ folk to coordinate the ducks. And we'll need more meetings of course and over time we will undoubtedly need a Duck Resources (DR) department.

Maybe - if the ducks can do programming - we will invented a Scaled Agile Duck framework (SAD) and businesses can send some of their ducks on courses to learn how to get the other ducks lined up in a row. And other, more senior, ducks can go on courses to learn how to teach the first lot of ducks how to run the first lot of courses.  [And, someone could make a lot of money, if only they could figure out how to franchise that ...]

So I thought all these things then I turned and looked back at the duck.

And he seemed to look back at me.

I said to my wife. 'Can we go back and talk to the duck?'

'Why not?', she said. 

We went back to the duck, and he stood there patiently as I explained my thoughts on scaling ducks.

And then he spoke to me.

'What the fuck are you talking about, monkey boy?'

I said, 'Look, in my work, we talk about 'getting our ducks in a row', a lot, and when I saw you standing there I realised that was easy to do with just 1 or 2 ducks, but really tricky as you increase the number of ducks. That's all.'

'You want to know how to get lots of ducks in a row?'


'You reallllly want to know how to get your ducks in a row?'


He said, 'Will you pay me a lot of money if I tell you?'

I said, 'Sure!', because, like, wow, what ever he charged me, I was sure I wasn't the only person in the world who realllly wanted to know how to get their ducks in a row.  Maybe I could get rich.

He said, 'Nah. I won't charge you. I don't think you'd like the size of my bill.'  

And then he fell to the sand and started laughing and laughing and launching.  It took me a while, but by the time he'd gotten his breath back, I realised he'd just made a "duck bill" joke.

Then he stood up and said, 'Okay, follow me.'

So we did.

We walked up the beach, onto the road, then along the road, towards the airport.

He stopped when we reached a pond.

There was a bright orange traffic sign just in front of us, but it was facing awayso we couldn't see what was written on the other side.

He said, 'If you reallllly, realllllly, wanna get your ducks in a row, it's simple.  The secret is on the other side of this sign. Go on, take a look.'

So we walked past the sign then turned back to see what was written on it.

There were no words. Only a picture.


Mr Duck said, 'If you want to get a bunch of ducks lined up in a row, it's simple: give us someone to follow, then take us on an interesting journey.'

And then he flew away.  



Wolves and Leadership - Bullshit.



A little food for thought.

A group of project managers.  They march forward, one by one, through the settled snow, each looking forward, none looking back. They march on relentlessly, heroically, their chests puffed out with confidence, each knowing full well that PMs that don't look both heroic and confident don't remain PMs for long.

The three at the front?  Their projects are red.  They've been sent to the front so everyone else can keep an eye on them. They'd been amber and asking for help for months, but it wasn't until they turned their projects red that they got the help. One of them got asked to make a commitment she knew she couldn't keep.  One crossed his fingers and got unlucky through no fault of his own.  One is a contractor and has been hired to take the blame, though he doesn't know that, yet.

The five behind them?  Their projects are amber. They're worried, for all sorts of reasons, but mostly because - if you look closely - it seems the 3rd red PM has crouched down to relieve himself in the snow, and they're about to bump into him and the mess his project has left behind. They bide their time, cross their fingers, wonder if and when they will join the red pack.

The pack in the middle? They're working on stuff that's gotta be done, but no one really cares all that much about it.  They march along, staring at the butt of the wolf in front of them, taking care not to walk too fast and inadvertantly end up with their snouts inserts up the wolf-in-front's butt.  They make sure to not make eye contact with anyone else. They are not all wolves, actually - some are sheep wearing wolves' clothing, hoping none of the real wolves notices their true identity and eats 'em up. Yes, sheep suffer from imposters syndrome too  

The 5 green wolves?  Their projects are on track, they're looking good, life is sweet.  Two of them have only just started their projects, so they haven't had time for things to go wrong.  One is new to the job and doesn't know that things will probably go wrong; the other one does and is enjoying the peace, while it last.  Two of them are thinking they should be in the amber pack.  And, the last one?  She knows for sure she should be in the red group, but has been putting on a good face, choosing her font colours carefully ... delaying the inevitable.

The guy at the back?  Some think he is a leader, watching over his pack, protecting them.

 In reality, he is modest and stopped for a discrete poop while no one was looking, and is now rushing to catch up with the others before anyone notices. 

That may not be leadership, but at least it was polite.

[I hope this comes across as tongue-in-cheek. If it comes across as offensive, leave a comment and I'll delete it. I'm just sick of seeing this image come up - again and again - with its nonsense, happy-clappy, bullshit, leadership analogy.  See snopes if you don't know what I mean.]


      One of the things I've learned over the last half-dozen years is to deliberately care-less.  That's NOT the same as being careless.  It's NOT the same as caring less.  ---  What it is:  It is choosing to NOT care about MOST things.  That choice frees space for me to only care - much more - about a few important things.  ---  I'm 47 now.  I only learned this skill during my 40s.  I learned it by caring too much, for too long, about things that probably didn't matter and, even if they did, no matter how much I cared, I couldn't do anything to change them.  I learned it by suffering.  It's nice, now, to smile and shrug as I don't   - try to boil the ocean, and I do   - try to achieve good-enough, rather than perfection, and when I   - spend time figuring out what's important, so I can chase it, rather than the urgent.  None of this is new.  ---  Caring too much causes pain and frustration.  And whinging.  Stop it.

1 Comment

One of the things I've learned over the last half-dozen years is to deliberately care-less.

That's NOT the same as being careless.

It's NOT the same as caring less.


What it is:

It is choosing to NOT care about MOST things.

That choice frees space for me to only care - much more - about a few important things.


I'm 47 now.  I only learned this skill during my 40s.

I learned it by caring too much, for too long, about things that probably didn't matter and, even if they did, no matter how much I cared, I couldn't do anything to change them.

I learned it by suffering.

It's nice, now, to smile and shrug as I don't

- try to boil the ocean, and I do

- try to achieve good-enough, rather than perfection, and when I

- spend time figuring out what's important, so I can chase it, rather than the urgent.

None of this is new.


Caring too much causes pain and frustration.

And whinging.

Stop it.


1 Comment

1 Comment

A lesson in Quality.

I feel so sorry for this company.

They've produced a fantastic looking product but it's buggy.

And, it's hardware, so it can't be fixed remotely with a software update.

It's earning them loads of "Fantastic but ... it doesn't work" reviews.

Their website looks beautiful.  Their product feels beautiful.  But, a tiny bug, is tarnishing what should be an amazing reputation.  

And then their low trust support processses are turning fans, like me, into enemies, and examples.


1.  Waiting ... it's okay when it's understandable.

I ordered my fancy Brydge IPad Pro keyboard, then sat back and waited and waited. That's okay.  Lots of people are ordering them. There was a backlog. I now live in New Zealand so there's international shipping.

I was delighted when, many weeks later, they sent an email saying it had (finally) shipped.  I couldn't wait!  But I had to ...

It arrived a week later ... while I was away for work.  I couldn't wait to get back home...  I reallly wanted this new keyboard.

I got home.  I opened up the box.  I plugged it in.

It doesn't work.

It doesn't work.

It doesn't work.

2.  I contact support.

They make some suggestions.

They don't work.

I contact them again.  They tell me I have to post my broken keyboard back to them and then they'll test it to see if it's broken and send me a replacement. What?

My first thought? Why didn't they test it before they sent it to me?  Why did I have to test it for them?

My second thought? Why do I have to wait some more, for them to test it to see if it's broken?  If I'd bought it from amazon I could have returned it and they'd have sent a replacement straight away.  In parallel.

I reply, asking them to send a replacement, in parallel, instead.  I post my broken keyboard; they post theirs.  We're both happy! Yay.

3.  Their response?

'Unfortunately, we can't do that'.

My first thought?  "Can't" is the wrong word.  They incorrectly wrote "won't".  

Why wont they? 

Presumably they don't trust me.

Perhaps they think I'm running an elaborate scam to try and get two keyboards!  Honestly, I only want one - the one I paid for weeks ago and can't use. 

4. I go look at reviews on blogs and amazon.

According to the reviews, this product is riddled with bugs.

One prominent blogger - a guy who, now,  loves his keyboard - had to order THREE before he could use the product, since the first 2 didn't work. 

I don't want to have to do that. If I get unlucky a 2nd time then the new iPad Pro will be out before I get a working keyboard.  Once bitten ...

5. I asked for my money back.

I'd love a working keyboard.  I've wanted one for 6 months.  But now, I just don't want the hassle and the stress and - you know what - I've grown to dislike the company and I don't want their effing keyboard any more.  

6. That's an emotional response.

I'm not happier to cut my nose off, to spite my face ... and it's all not because they shipped me a broken keyboard, it's because they wouldn't replace it with urgency because they need to test it because they don't trust me.

7. What should they have done instead?   

When they discovered their product was buggy, they should have stopped the bugs reaching customers by testing them.  

And then, when a shitty product reaches a customer, they should apologise enormously, expedite a replacement (which they test before they pop it in the envelope), and perhaps offer to compensate the customer for their lost time.  

8. Contrast this with Apple.

In January Apple replaced my iPad Pro, and it's case, and it's Smart Keyboard since they werent working properly.  The ipad had a bright spot on it's screen.  The keyboard and case were looking far more tatty than they should have been given their age. The iPad was a week out of warranty.

And then, a couple of weeks later, my iPhone had a weird problem and, since I was leaving the country, for good, the next day, they replaced it on the spot.

I've not been moaning about their shitty products.  I've been telling people how amazing they are.

Lesson: If you're gonna have apple-like products, then make sure you have apple-like support.

1 Comment


The odd socks principle.


I wear odd socks most days, but no one knows because they're hidden inside my shoes.

It saves me time and it makes me happy, but no one else needs to know.

Sometimes, in work and life, when you're doing something odd - like Agile or TOC, say, or a fondness for Neil Diamond - there are ways to be odd, to share the benefits of being odd, without making a big fuss about the oddness.





Quiz: Are costs going up or down?

Yes, it's true to say that TOC is about bottlenecks.  

But it's more than that: TOC is about how your understanding of the world changes when you recognise that bottlenecks (and other types of constraints) exist. 

If you go back and read The Goal you'll discover that the first half is a bottleneck free world and Alex Rogo manages and measures his world as if bottlenecks do not exist. Then, early in in the second half of the book Alex discovers that bottlenecks do exist, and he spends the rest of the book figuring out the changes he needs to make to his factory's  processes and measurements, given the existence of these bottlenecks.

The before and after versions of the measurements conflict with each other.  And that conflict is where the most resistance comes from from his bosses and colleagues. They (oblivious to bottlenecks) say that Alex's changes will make the factory less efficient (because the machines and people won't be 100% busy all the time) and it will push product costs up (product cost is an average and, in his factory, total costs stay the same but they're producing less product) but Alex says those changes will result in the factory making more money (and he is). 

I understood those ideas, intellectually, when I first read them but I didn't work in factories and (silly me) I figured they only applied in factories. But then, over time, I noticed that the same problems happen all over the place - in hospitals, in software development, for instance. And now, in prisons. 

Read this article, from the Irish Times, note that fixed costs are 75% of total costs, then ask yourself "did the costs go up, or down?" Then ask yourself, if you were running that prison what would be the easiest way to lower costs?

Would you, maybe, lobby for longer prison sentences and tougher probation rules, so your prison had more prisoners inside and they could each share more of those fixed costs? 





1 Comment

I just saved £900 while off sick from work

I managed to catch a bug of our filthiest child so I've been off work for a couple of days.

That saved me about £900 coz I used the downtime to do some comparison shopping.

- I checked the latest price for car rental for our upcoming summer holiday. From the same company, it was £300 cheaper yesterday, than when I booked it in june, so I cancelled it, rebooked and pocketed the difference.

-BIG SURPRISE.  I discovered you can buy reputable car rental  "excess" insurance for £40 a year, which covers both of us, and saved me between £150-200, just counting our summer holiday.  Avis charges about £15 a day otherwise. I never knew you could buy that insurance

- i got pissed off at Vodafone for making me hold for 40 minutes, when i had to call them because their website was broken, that I decided to cancel 1 of our SIM cards, rather than renew, and when I got put through to the cancellations person, and told him I was going to cancel, he slashed all 3 of our phone bills, which saved us about £400 all up. And I doubled my data alowance to 20gb and we've got free data on our holiday.

Funny the things you discover when you are figuratively chained to the loo.

Hope this maybe helps you.  I stumbled across those 3 savings and now I can buy a new MacBook. 

1 Comment


Names - Paretoed

As I wandered towards the train station today I noticed a sign in front of one of those pop-up shops you sometimes see in shopping malls. It asked, "Is your surname here?" .  Without thinking, I looked for CHING but my surname wasn't there amongst the 200 or so names.  I then looked outside the list and saw they were selling preprinted posters detailing the history of the customer's surname.  I checked and the surname Pareto wasn't on the list, though it was written all over the sign, and no doubt summed up their business model.

I am sure, given you're reading this blog, that you know of Pareto and his law, also known as the 80/20 rule, but I like this particular example. There are a huge amount of surnames - including mine - not on their list, but they've surely covered over 90% of the population. 



New RSS feed for this blog

Sorry me but due to a technical hiccough*, I've had to move the RSS Feb for this blog.

Resubscribe using the link at the top of this page.


* or technical incompetence on my part.  



Announcement: New book - Chucking Rocks at the Universe

Hello my friends.  You can read my new book, as I write it in an agile (incremental and iterative) way, by going here.  That's the google Docs version and it currently has the first 2 installments - about 2,000 words worth - and it will keep growing 'til January the 20th, when it will be published. 

At least, that's what I intend. This is an Agile project and I'll be structuring the book, and planning its construction, in way where, unless something really shitty happens, I will hit the date. 

What's it about?  Sorry, but you'll have to subscribe to the blog (via email or rss) to see. I'm sharing my thinking as I go along (that is actually part of the content) and so far I have a fixed date, a working title, a cover and a whole lot of work ahead of me. 

If that answer doesn't grab your attention:  it's about Agile, but with the boring bits taken out. 



1 Comment

X-raying the Cash-Cow - a Lesson in using Bottlenecks to Make More Money

I've been travelling from Manchester airport to Edinburgh, weekly for a couple of months now.

Something odd happened today: it took well less than 5 minutes to get through security, down from the normal 15 - 30 minutes, and that had an interesting knock on effect, - the waiting area is extra full and there are big queues in all of the shops - and it provides my imagination of a fascinating example of how bottlenecks can cost/make businesses a lot of money.

I'm not sure what happened to speed up the security process, although it might just be that they put more staff on the machines. Whatever it was, it looks like their check-in bottleneck has, perhaps temporarily, moved from the security scanners to the shopping/waiting area.

Let's say the security scanning process is 15 minutes faster today. Let's say most passengers previously spent 45 minutes waiting in the shopping/waiting zone before they got called to their gate. They're now spending 60 minutes there. There are now roughly 1/3rd more passengers in the waiting zone, and the seats are all taken. There are roughly 1/3rd more customers in the shops, and, the way queues work, small changes in demand can cause them to grow disproportionately, and (to me) it looks like the queues are 3 or 4 times bigger than normal. Those queues sound good but shops want customers paying, not queuing to pay, and not walking away because the queues are unbearable.

If the check-in bottleneck has moved permanently, then maybe the shops should start looking at their checkout processes and speed them up a smidgen so they don't lose sales from people like me who won't queue unless desperate?  They should milk that cash-cow.

Likewise, maybe the airport will, after a while, once everyone agrees the cash cow is hanging around, threaten to slow the security down,again, unless the shops agree to pay higher rentals?

I'm guessing it cost the airport 3 extra security staff to speed up their security. Maybe it was 6. Who know?  I'm guessing. But let's say it cost them £250k a year. I bet the increased spending in the shops (provided the shops increase their payment capacity so they can milk the cash cow) is worth at least £250k a month, probably more.

It's funny, I've been spending my time in security, over these recent months looking around contemplating how they might speed up the security process.  When you learn TOC you tend to do that; it's frustrating but it fills in time. I'd always looked at it from the point of view of a customer, someone who was stuck inside the system. It wasn't until I saw the queues in the shops that I put my business eyes on and saw a cash cow there waiting to be milked.

1 Comment


Agile and Sales

A few years ago, I found myself in the unusual position.  I got layed-off when the other companies in the big group I worked for got into financial difficulties and, then, while I was waiting for my notice period to burn down, I accidentally helped our sales guys win a multi-million-pound sale. 

In the 2.5 years I'd worked there, I'd never been asked to speak to any customers.  But then, during the bidding process for a big deal the representatives of one potential customer asked to hear something about our development processes during their site visit. The sales guys - nervously, I imagine - asked me to do an hour long presentation on Agile (yawn), where they hoped I'd emphasise the maturity of our development practices.  

I agreed and they slotted me in from 11-12am, on the last day of the 3 day visit. 

Eleven came and ... no customers.  

Twelve came, still no customers.  

Eventually, I got an email: could I squeeze the potential customers in for 10-15 minutes, at the end of the day, while the customers waited for their airport taxis to arrive?  

'Sure', I said, and then I chucked my presentation away, and asked myself, what's the most useful thing I could tell them in 5 minutes?  

The answer, it turns out, was the old sales/marketing rule: sell benefits, not features.

The potential customers arrived 5 minutes late, of course, and they were clearly exhausted, worn out from 3 days' of boring demo's and negotiations, and sleeping in hotels, and speaking in English, their 2nd or 3rd language.  We were the last of a handful of competitors and I bet they were dying to get home to their own beds.

There were five of them.

I said, 'Do any of you own Macs?'

Two nodded. 

'You know Apple released their annual OS X upgrade today?'

More nods. 

'It's nice getting all those bug fixes and shiny new features every year.  It's one of the reasons I like Apple, compared to Windows, since they only deliver significant upgrades every 3 or 4 or 5 years.' 

Five nods but only two smiles (from the Mac guys).  

'Well, we've made a lot of changes here over the last two years and nowadays we ship production quality releases of our latest software quarterly.  Every 3 months - four times a year - you'll get new features and bug fixes. Our software isn't as sexy as apple's but by that measure I reckon we are 4 times better than apple.'

More nods.   

Their taxi arrived. We shook hands.  They left. I went home.   

Late the following week I got an unexpectedly nice email from our head sales guy thanking me.  Apparently our product's features and our price were similiar to our competitors but our quarterly releases were a huge competitive advantage, and that's what clinched the deal. 

I helped straighten out our development processes so that we could deliver quarterly, but it was our development manager who pushed (and pushed and pushed and pushed) the quarterly releases.  Hardly anyone thought it was a good idea ... except our customers.


A few thoughts:

-   These days I hardly talk about the "features" of Agile because, honestly, Agile has been around for ages and, if you wanna do a better stand up, well, google it, or buy a book.  Mostly, I help folk Identify the benefits they want to chase (and, just as important, what they shouldn't chase, yet) and then help them figure out how to go after that.  Benefits, not Features.

- There used to be a book floating around called "Sacred Cows Make the Best Burgers", but I think it's wrong because, "Cash Cows Make the Best Burgers" and, if you want it to be, Agile is very good at transforming ordinary cows into tasty Cash Cows.  

- I moved from that job to something much, much better, but I can't help but feel a little miffed since the margins from that one deal would have paid my salary for somewhere between 50 and 200 years.   Maybe I didn't do such a good job of selling my own benefits :)



FREE Audiobook version of Rolling RocksDownhill - OUT NOW!

Have you been too busy to read Rolling Rocks Downhill?

Why not listen* to the audiobook free instead. 


Rolling Rocks Downhill has been out for a year now and getting fantastic reviews, like this, the most recent:

““What an amazing book! Like Goldratt’s The Goal, Ching uses the novel format to get across important organization concepts. I have already implemented some of his lessons in prioritization and working in batches in my organization. The book is also very insightful in describing how real organizations work.””
— - not my Mother

And this (the next most recent):

““A genuinely enjoyable read. There are obviously lessons within the story, and good ones at that, however this is so well written you forget you are reading anything other than a gripping story.””
— - - not my Mother, either


*Podcast and web, Audible (paid) coming