Category Archives: General

PM#, Project Management

PM#5 – Whose schedule is it anyway?

6 Comments

There was an interesting discussion entitled “is it just me?” over here at Scottish Developers. My reply is here. Anyway, it preempted this posting in some respects, but I’m going to carry on with this post regardless!

Customers and management never seem to believe the estimates developers give them…time and time again, developers provide an estimate of how long a project (or task) might take, e.g. 12 weeks, only to be told (by the customer/management) that it will take 6 weeks. There are many reasons for this sudden shortening of the schedule…many of which revolve around the fact that the customer/management have promised their upstream customer/management something (a software solution) by a given date. An unrealistic date at that.

Who is more qualified to make schedule decisions that relate to software development? Is it the person whose job it is to actually “cut the code” (the most important part of any software project, no code, no project), is it the person who actually does the job or is it the person who has promised a piece of software to their upper management by a certain date?

Despite any potential previous bad experiences, customers and management should learn to trust developers more, they are the most experienced resource management tool a software project will ever see. They have excellent gut reactions, they know when something is “do-able” or not. They can reliably tell you whether something requires 4 hours or 4 weeks to complete. They know their business, inside out.

So why is there such disrespect for developers and the work they do? Why do I hear lots of sob stories revolving around late delivery, “he said it would take 4 days, it took 12 days, his estimates are rubbish”?

The simple answer is this: unless the part of the schedule that a developer is working toward actually belongs to him, realistically speaking, the developer knows he’ll not be able to meet the schedule but will carry on regardless. He has nothing vested in an arbitrary schedule that does not give him enough time to to his job properly. True, the developers will probably bust-a-gut trying to bring the project in on time, however as we know, invariably they’ll fail. But it’s not their fault. It’s the fault of the person who gave them the wildly inaccurate schedule in the first place.

Even if the schedule was remotely accurate and did have input from the developers, other folks exhibit a disturbing lack of respect for the developer and the schedule. A schedule can often be agreed provided that all or some tasks are distraction-free: this is easy to agree at the outset, but rarely happens during the project execution. Similarly, a fully-committed developer has no “resource gap” or free-time, there is no “contingency” in most projects. Therefore, you cannot duly expect to either e-mail or walk up to a developer and ask them to take on other tasks (for other projects) that aren’t part of the schedule…and since developers (and a lot of other good folks) find saying “no” difficult, they can often be [bullied] into saying “yes” to more work that will invariably knock the previously agreed schedule out. The trick here is not to offer developers other work – no matter how important it is to you (your top priority work isn’t going to be the developers top priority, he’s busy focusing on the project.)

Getting schedule buy-in from the developers is key – give developers the chance to form and shape their own schedule, let them break tasks up into smaller more manageable chunks that can be delivered over shorter periods of time, e.g. every 30 days or less. Don’t force them to buy-in to a [rolling] project plan that spans 6+ months – the speed at which the software business moves at, 6 months is far to far away: focus on what can be achieved now rather than later. Developers also need an endorphin hit every so often (cited as being every 2 weeks) – they get endorphin hits by starting and finishing a task, by seeing a piece of their code [go into production] in front of a user/customer or by visibly moving the project forward in some respect.

Analogy
When you last had you car serviced, you probably gave it to the garage for a whole day. I don’t hear about folks telling the folks who work in garages: “You need my car all day? No, you can have it for 3 hours. Can you get everything that needs doing done in 3 hours?” I’d like to see the state of your car once you get it back…may be not today, but in a few weeks time when you thought all that work had been done…

Example
I have a standalone application – a single .exe that runs on a per-machine basis. A client has requested that we “get it to work over the network”. For us, this is a big job, it requires changes to the backend database to allow the introduction of a user column (at least), transaction support, improved backup/restore, etc. To the client, networking an application is the simple matter of adding a login box at the start of the application. Since that’s all the client ultimately gets to see…”how can that possibly take N weeks to write?!” Perception and explanation are key. As developers we must learn to stand up for ourselves and learn to say “no” to unrealistic schedules: whoever is asking you to commit to such a schedule doesn’t understand how their car works, yet you won’t find them telling the garage to cut their schedule in half…unless they are themselves a mechanical engineer (versus a fitter), in which case they would need to be experienced software engineers in order to discuss schedules with you!

Need to cut the schedule? Well, why not cut the feature set?
If you have a pressing need to cut the schedule, at least negotiate with the developers over the feature-set that your hoping they’ll implement in the shorter time-frame. We know that “80% of a product’s value comes from 20% of its features” (originally from here), surely you can afford to cut the number of features in order to cut the schedule? Of course, now we’re in the realms of controlling the four success variables (cost, time, scope, and quality).

four variables

In the first instance the customer is allowed to select values for any three of these variables. The development team will then choose the value for the remaining forth variable. Ultimately, between the customer and development team there will be a series of compromises and trade-offs resulting in an adjusted set of values, or even trading of variables!

There are interactions between the variables. For example, increasing the time can allow for an increase in quality and/or an increase in scope. Another example might be a reduction in scope: it is possible to deliver earlier (less time) or cheaper (less cost) or possibly with more quality.

It is worth noting that the relationship between the four variables is a complicated one – it is not possible to reduce the time variable simply by increasing the cost variable. Nor is it possible to increase the cost expecting an increase in quality.

Crazy Schedules
Schedule pressure often sees shortcuts (or what are perceived as shortcuts) being taken. Instead of well-structured, reliable object-oriented code, being cut produced, prototypes are built as proof of concept…a little cut’n’paste then follows, prototype code suddenly becomes production code but only after crazy amounts of testing and re-work. It’s a spiral that requires a step back and a re-write to get out of, and may be more than one re-write at that. Crazy schedules will cost you considerable amounts of time and money downstream, they’ll also cost you the respect of your developers too.

Scott Berkun wrote an excellent book, The Art of Project Management, reviewed here, where he cites an example: your client in on the operating theatre table, the brain surgeon tells him that the operation he requires will take 12 hours…you won’t find your client turning to the surgeon and saying “no, you have 6 hours”…This just wouldn’t happen, I rest my case: if programmers or developers tell you something will take 12 hours, give them 12 hours (or more if you’re generous), it’ll protect your reputation, they’ll respect you for it and it’ll give your project more chance of success.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#4 – Start it…finish it

8 Comments

As Dr.Neil Roodyn says, keep your task duration/time down to a 30 minute average (which means your tasks can be anything from 5 minutes to 120 minutes in length, it’s the average we’re interested in).

Just as important as the task duration, is the need to ensure that a task can be both started and finished. Long-running tasks do nothing for a person’s (read: developer) motivation and desire to focus on the project in hand. There’s little point asking a person to do any more if their in-basket/work-basket is already overloaded with tasks that have been started, but not finished.

I call this role Starter-Finisher, Dr. Meredith Belbin calls it Completer-Finisher. Either way, the job needs doing; starting can be easy, which is perhaps why Belbin believes the role should focus towards the end of the task, i.e. the finish or completion.

Completed/Finished tasks elicit feedback, feedback drives quality, quality drives customer satisfaction and customer satisfaction drives profit.

So, the simple statement that this post is trying to make: if you start something, finish it. Don’t let anybody distract you whilst you are completing (working on) the task, try and set aside a suitable chunk of time that is free from interruptions. Remember, the shorter the duration [of the task] the more accurate your estimate of time to complete it going to be. If you have to, break longer tasks, e.g. longer than 2 hours, into smaller more manageable tasks. Of course, you may need to remind folks that it is your schedule, not theirs, and that contrary to common belief you won’t drop everything to work on their problem.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

General

VirtualPC inside a VirtualPC?

2 Comments

Kimberly Tripp mentioned this little funny in her SQL Server 2005 pre-conference session at TechEd this year (blogged about here).

Kimberly mentioned a funny error message that would appear if you try to run a mobile application via Visual Studio that’s installed in a Virtual PC image. Given that the mobile device emulators are themselves essentially virtual PCs, this shouldn’t be too surprising…but the error message is, well, humourous to say the least.

Chris Hart saved me the effort of installation, etc. and provided this image:

unlucky for some

General

DHTML Lemmings

Jonathan’s post about Asynchronous JavaScript with XmlHttpRequest (AJAX) caught my eye. As noted in Jonathan’s post, using the XmlHttpRequest object isn’t new…it has been available in Internet Explorer for a long time, certainly since late 1999/2000. Indeed, it is only now that other browsers are appearing on the scene and more of us find ourselves with always-on Internet connections that AJAX comes of age. Like Jonathan, I’m looking forward to getting my hands dirty with it, very soon. There’s more about AJAX-based applications over here.

I also found a link to DHTML Lemmings in Jonathan’s post…uh oh, I can see hours of my time going out the door…I overplayed Lemmings when I had it for my Archimedes during the late 80s and early 90s. Ok, ok, Jonathan’s post title did mention it too, but I didn’t think the game would be this realistic.

Move over Patience and Solitaire, your days are numbered.

unlucky for some

PM#, Project Management

PM#3 – Use e-mail properly

4 Comments

E-mail can be a hinderance for three reasons:

  1. Unless you are very strict, most folks find themselves checking e-mail more than three times per day. This is especially true if your e-mail application has a notification facility whereby you see and/or hear new e-mail arriving. It’s very difficult to resist the urge to go and read new e-mail. Worse, in open plan environments, it’s possible to hear other peoples’ new e-mail arriving.
  2. E-mail, as an application, has history, it has etiquette, it has a modus operandi. Very few people, in my humble opinion know how to make good use of e-mail. This is especially true for “newcomers”, i.e. those folks who have joined the e-mail bandwagon late and don’t realise that there are written and unwritten rules that should be understood (notice I don’t say ahered to, rules can be broken if the timing is right, but that’s another posting!)
  3. E-mail has no real means of helping us manage our to-do list, it doesn’t help us manage those e-mails that require us to respond to, nor does it help us manage those e-mail for which we are awaiting a response. As project managers, we find ourselves dealing with collections of issues, requests for information, decisions, etc. How do we solicit such data? We use e-mail. How do we track who has responded and who hasn’t? Suddenly it becomes very difficult.

One of the e-mail rules that I like to adhere to however, is one that is all too often broken by others. If you find yourself in the CC section of an e-mail, i.e. not in the TO section, this typically means that the e-mail, for you, becomes a FYI…for your information. Your response, unless solicited directly in the e-mail, is not required. Should you choose to offer a response, you should apologise for interjecting from a CC.

Managing by e-mail is also rather difficult. I know some folks work on a “zero in-box” policy whereby e-mails are converted to tasks (we’re talking about Outlook here) and thus you have a prioritised list of things to do. This works, however I think the problem of information management, and e-mail falls into this category, is a much more difficult arena, and one that is not served by a killer application. Of course, managing all this properly brings with it the need to classify, attribute, associate, infer, etc. links between items, prioritise items, and so on. Whilst work is being performed in this area, all we can do today is learn to use e-mail properly.

Don’t let e-mail rule your life – you don’t need to check your e-mail more than three times per day (if somebody tells you that they have just sent you an e-mail that requires your attention, you may of course check your e-mail in between times!)

Do try to keep your immediate in-box cleared down to a reasonable size, I prefer to have less than 20 items “in my face” when my e-mail client(s) start up. Use folders and colour-coding (if available) to help you sort’n’prioritise – not to the point that it overcomes point 3 above. Generally speaking, I’ve noticed that I have very few e-mails whose lifespan is more than 7-10 days – as such, I have a folder “older than 10 days” which can be used as a manual dumping ground, or automated via a rule. Your threshold may vary, but try it, you may be surprised.

You don’t need to keep all trivial e-mails, move them to a “trivial” folder, or better still, delete them.

I will often include myself in the CC list of an e-mail. This allows me to clear out my sent items folder fairly frequently. If your e-mail client offers you “sent item”-specific features, such as delivery/open tracking, this might not be an option for you (but only if such tracking is required).

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Developer Events, General

eXtreme .NET and Web Services – TechEd speakers hit Scotland!

1 Comment

July 21st – TechEd speakers come to Scotland!

I caught up with Christian Weyer at TechEd 2005 last week, he’s a great guy…and he’s coming to Scotland next week to deliver his “‘Add Web Reference’ Reconsidered: Implementing Web Services the Other Way” session.

And Dr. Neil Roodyn will be presenting his “eXtreme .NET – An Introduction to Better Software Development” session.

Extreme Programming (XP) and web services on the same agenda – it doesn’t get any more up to date than that!

Interested? There’s more information here: http://www.scottishdevelopers.com/modules/news/article.php?storyid=86

I hear that a free copy of Visual Studio 2005 beta 2 DVD pack will be given away to every attendee! (in addition to a free CodeZone gift!)

There’s also talk of a hillwalk on the 22nd of July…

PM#, Project Management

PM#2 – Focus on the project

3 Comments

In Vienna, April 2004, Ken Schwaber, co-founder of Scrum said to his class:

“Don’t procrastinate, do something, no matter how small…something that moves the project forward”

I’ve kept that quote close to hand ever since. In fact, I even use it in my Scrum presentations (more here – registration required)

The crux behind “Focus on the project” is this:

We all suffer from an uncanny ability to be sidetracked or to be distracted. This is not good for the project.

Distractions, as Clarke might say, are evil. I certainly agree, distractions are the work of the Devil.

I find myself distracted by a number of things (apologies if these sound like rants…they are sort of!):

  1. Passers by. I’ve been travelling a lot over the last 18 months, so when I get back to my desk I’m invariably greeting with the response “oh, you’re back…”. And being an IT guy, the next question, after the usual exhchange of pleasantries is “…I have an Excel problem…have you got a minute?” (Of course, sometimes it’s Word!) As noted earlier, “a minute” usual means five. Getting back to what I was doing after a five minute gap can be a chore.
  2. The telephone. The telephone’s great for getting quick decisions and I favour it over a series of e-mails (this is the subject of a future posting). However, just because I have chosen to answer the telephone, typically out of politeness, it doesn’t mean that I’m at your disposal. Please ask me: “is now a good time to talk?” or “do you have time to talk?” Better still, if you’re call isn’t that important, send me a single e-mail asking me to call you when I’m ready. Telephone interruptions tend to be continous, once a caller realises that you are already on the the ‘phone, they’ll tend to keep trying until they get through. Apart from the obvious waste of time and resource, it means you suddenly end up with two (or more) ‘phone calls back-to-back. This is really frustrating as it feels like you’re destined not to get on with the task in hand, i.e. focus on the project.
  3. Folks who don’t realise the importance of what’s being done. I’m sat here in my study typing this post, to all extents and purposes in the eyes other folks, it’s something that can be done later…because all I’m doing is staring at the monitor. Creativity doesn’t work 9-5, it doesn’t always manifest itself in swish graphics on the screen or reams of fancy looking text. Similarly, it’s the weekend…my deadlines have been published for long enough now, but still I’m just perceived as sitting in the study twiddling my thumbs…my to-do list isn’t at all important!
  4. Doing something for doing something’s sake. It’s nice to get ticks in boxes, little jobs complete, but ask yourself: “how important was that tick in the box activity?” It might have been important to somebody else who needed the tick in the box, but did it really help the project? There comes a time in a project when a particular avenue is closed off and another route has to be examined. Some folks will expect the original avenue’s work to be completed such that proper closure can be achieved. Invariably, you’ll find yourself creating documentation or doing work that will not be used and merely gets the requestor a tick in the box – this kind of distraction does not help the project and serves to slow to you down.
  5. Poor use of e-mail. A future posting will cover appropriate use of e-mail…as a distraction, “e-mail ping pong” is a real pain. E-mail is a great tool, but some folks treat it as “work postponement device”. This scenario typically occurs when you pass work on to somebody, you may spend some time crafting a very succinct e-mail making sure that you pass the request/work over neatly. Imagine your surprise when the reply comes back very quickly with a question that essentially passes the work content back to you? I’ve seen this trick referred to in other postings as “sloping shoulders” – the uncanny knack of not accepting a work package! I’ve also seen this scenario referred to as “answering questions with questions.” The distraction element occurs as you have to read the question and then re-plan the distribution of that particular work package.
  6. Too much work. Yes, I agree, this is a strange one. I find myself, and see others, being distracted because they’ve got too much work to do. In this distraction scenario we find ourselves flitting between tasks/activities, not really focusing on any task for too long. We essentially fall into the “multi-tasking is evil” camp, but that’s another blog post (#7, in draft format, coming soon).
  7. Too much travel.

    8. Travel takes its toll; downtime in airport departure lounges can be harnessed, however invariably, I find myself fidgetting and wanting to get on with some work, i.e. move the project forward. However, I usually end up reading a technical book, or a novel (this is sometimes better as it frees the mind, allowing the subconcious to “do what it has to do”) I’m a great believer in conference calls and LiveMeetings for bringing folks together “face to face”.

In summary…
Do what you have to in order to reduce the number of distractions that are plaguing you. Make large chunks of uninteruppted time available to you and your project – it’s the only way you can make significant and productive progress.

Even if you publish your deadlines and to-do list, sometimes you will find that you need to reinforce the importance of it to others.

Alway ask youself, “is what I’m currently doing helping the project?” If it’s not, then it’s periphery and you should re-prioritise your work basket.

It’s not just about “you” focusing on the project, it’s also about getting the project team to buy-in to a similar focus otherwise you’ll find yourself threading water (if you’re lucky). I know it’s difficult, but if you have folks on your project who have interests other than the project in hand, it’s important to have them drop that interest such that they can focus on the current project.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Project Management, Rants

Agile:Rant: If you do some of the work…

1 Comment

Here’s a snap of the peaches we bought from our local big-name supermarket:

unlucky for some

“Ripen at home”. What’s that all about? I have to do some of the work here…and I’m still paying the same price. I don’t see any payback when I get to the checkout, what’s going on here? Does this mean I’ve bought a product that isn’t ready to use when I get it home?

Surely they should be cheaper? After all, they’re getting picked earlier, thus freeing up space on the peach tree for the next lot, thus…oh, I see, early release means earlier return on investment (and in this case earlier repeat growth). May be we software folks could learn something from this…

Incidentally, I’ve just realised what I’ve done here – I’ve provided some meaningful hints about this posting in the title (agile:rant) and in the categories (project management, rants)…this is exactly the conversation Korby and I had during TechEd 2005. Thoughts on classification, attribution, taxonomy, intelligent searching…coming soon.

Developer Events, General

TechEd 2005 – E-mail or blog?

1 Comment

A couple of years ago we were all happy exchanging e-mail addresses…this year, it seems that all I did was exchange blog addresses.

Why the sudden interest in blogs? My first few thoughts on this are: Blogs open us up to our readership, they provide a means of working out how somebody ticks. Couple this with the fact I can publish information about “a topic” and push it out to the world…no longer do I have to rely on somebody sending me an e-mail to which I then have to reply (actually, it’s easy to rely on somebody sending me an e-mail, the bits that’s hard is for the sender: I might take an age to reply.) Blogs alleviate this “waiting game” – if the information is published via a blog, it’s there and waiting for others to read. I find this rather interesting, so I’ll blog some more about this topic as soon as I have some content.

Here are the blogs of a few of the folks I met:

Korby Parnell. Korby’s got a lot of good stuff to say, especially about GotDotNet – thanks for the t-shirt and badge, I’ll wear ’em at the next .net event! Korby, Adrian Bateman, Maarten Visser (more here) and I had a late lunch followed by a very lengthy chat on Friday – we were discussing taxonomies, specialisation, association, adding meaning to searches, etc. The chat went on through the afternoon until we reached a point that we all had to split and head our separate ways. Watch this space…there’s a huge work in progress here, if only we can find it and specify it.

Oh, and if you take a look at Korby’s blogroll, you should find that it follows my “separation theory”, as noted here.

Betsy Aoki. I missed Betsy at a recent UK Community Leaders LiveMeeting, it was good to catch her in a couple of sessions and to chat in between times. I’ll be blogging about Besty’s TechEd 2005 sessions later this week – I have written notes and drafts in place already. There was, just to give you a taster, much talk of Robert Scoble (good talk I hasten to add, just in case Robert is reading this! Hey, let me dream about something!)

Speaking of the Scobleizer…look what he just posted. Lordy!

Eileen Brown. Eileen has a really cool picture of herself on her blog: I was lucky enough to learn about the history behind the photograph. My primary reason for pinging Eileen was to chat about blogcasts…Eileen and John ran a great session for MVPs last month.

Benjamin Mitchell. I sat in on Benjamin’s WSE 3.0 session, which, despite the video recorder not functioning at the start, went very well. Obviously the faulty VCR wasn’t Benjamin’s fault and he did a good job of padding until a new one arrived! Benjamin was at my end of the table for dinner on Monday night so we chatted about “how we get things done”. Benjamin and I seem to share a common thread when it comes to “how much work do we take on” and “how much free work do we take on”. There aren’t enough hours in the day… Anyway, Benjamin, Peter McMahon, Durgaprasad Gorti Adrian and I manned the “Ask The Experts” stand for many hours on and off. From what I saw, Benjamin has the “Scott Hanselman desktop“!

Mat Stephen. Amazingly, when I got back to my desk and tried to add Mat’s blog to my aggregator it told me it was already there. True enough, it was mentioned during the aforementioned blogcast session…I even had it written down in my notes! Mat’s some guy, I met him in the flesh on the Thursday of TechEd, then on the Friday we shared the same coach to the airport. Whilst at the airport we knocked back 2 * 1.5L pitchers of lager! We were also joined by three guys from Ireland…the time at the airport just flew by!

Anyway, that’s TechEd 2005 over, I’ve still got seven or eight posts about it to finish…tomorrow (Monday) I go back to my day job, so it might be later next week before they see the light of day.

In the words of Betsy Aoki, when asked about Microsoft’s policy on blogging (there isn’t one, in case you were wondering – isn’t it amazing how some of the best work is done without a “policy” in place?): “code smart, blog smart”

General

Yet another easyJet flight

Isn’t it amazing how fate throws people together and from that into conversation?

Today, I found myself standing in front of the flight departure monitors at Gatwick airport (I had actually managed to drop my bottle of fizzy drink and was waiting on the cleaning bloke to mop it up…which he did and then left a yellow sign with a slippery surface logo on it…)

Anyway, I digress: a gentleman walked up to me and asked “Do you know where gate 18 is?” Part of me just wanted to say “yes”, but that would have been rude, albeit somewhat French/Parisien in its humour content (Sorry Alex!). But, before I could tell him that it was “over there, follow the big yellow signs”, he walked off…leaving me in eye contact with another gentleman who saw and heard the whole thing happen! Some humour about the situation followed…and we exchanged the usual pleasantries that one does with fellow airline passengers.

As it happens we ended up walking down to gate, briefly chatting on the way. Gate 10 wasn’t far away, it’s marked as a 10-15 minute walk I think, but it really only takes 5-6 minutes. We arrived at gate 10, along with a few others, only to be told that the Edinburgh flight wasn’t departing from gate 10, the Shannon flight was. Of course, the lady on the security desk was positive (and nice about it too) and made a telephone call on our behalf. Long story, cut short, we were departing from gate 12 instead. Now, being a frequent flyer, and one who listens to the safety briefing at the start of each flight (!), I figured that there was a delay. The time it would take us to get from gate 10 to gate 12 was roughly 10 minutes, more if you were a member of the original 10-15 minute fraternity…this would buy the airline some time! Now, easyJet have been very good, flights have been on time, etc. so neither of us were particularly worried about the faffing about.

Anyway, it turns out that this gentleman with whom I exchanged plesantaries owns and publishes a number of magazines: Spain Magazine and a couple of others (I know the names, but can’t find a web-site just yet). And he’s an actor: remember the parrot in the Scotch (now 3M) TV commercial? He did the yawn…and yes, apparently parrots don’t yawn, but that’s showbiz!

We landed on time at 2025…20 minutes into the flight the first officer announced that they’d made a couple of “left turns” and shaved 10 minutes off the delay…amazing 🙂

Oh, and Rt Hon the Lord Steel of Aikwood KT KBE DL was only a couple of rows behind us…sadly the first things that came to my mind and that of my travelling companion was the Spitting Image sketch where the two Davids (Owen and Steel) discussed the merger of their two parties (Social Democratic Party and the Liberal Party), to form the Lib Dems. The name change change wasn’t much for David Owen, but for David Steel’s party, it was! Anyway, it was funny at the time 🙂