Advisory poster…

I’m probably blogging about this after everybody else, but I found this poster in my local baker’s shop window particularly eye-catching:


It certainly drums it home…the unattended rucksack issue. My baker’s shop is in Dalgety Bay, Fife, some 400 miles north of London. I think it’s important to recognise that what happened in London in July may not be limited to the boundaries of the M25 or the tube/underground network.

A good campaign, got the message across – it certainly caught my attention.

Blogging as a marketing device

WordPress blogger Jeff Jarvis wrote about his experiences with Dell in today’s MediaGuardian. I’m afraid that you’ll have to register (it’s probably free). He has followed it up here.

Given the sudden increase in my blog posts that refer to the Guardian of a Monday and Thursday, astute readers will know that I’m merely following the media and online sections of the paper because I’m interested in them (hey, I write articles and work with IT, sometimes, surely I’m allowed to?)

I can’t say that I’ve had a problem with Dell when ordering new, but I have endured a few headaches with their support service – not enough, however, to rant about it in this blog. I can sympathise with Jeff, even thought it looks like he has moved over to the other side and bought an Apple… There are times when you just wish computer manufacturers (and others) would do the right thing from the start…none of this faffing about with “returns” procedures, etc. If the customer wants a refund, it’s often the best publicity you can buy…well, I certainly think so.

What I was interested to read in Jeff’s article is the fact that you can search for any brand name (or product, or person) followed by the word “sucks” to find out how much bad karma is attached… Don’t worry about trying it yourself, just take a look at this and see what I mean.

I was more interested to read that it appears Dell aren’t following this bad karma, nor are they following what folks are saying about their products in blogs (may be they are, but there’s little evidence of it.)

Surely reading blogs makes good sense? And especially for large corporates with “product” out there. It’s free marketing. Need a product survey…check some blogs. Need to know what to put in the next version…check some blogs. [Product] Bloggers are the knowledgeable end-users that corporates should tap into for guidance, for direction and for the honest truth about how to improve and move forward. Similarly, the best way to learn about what’s wrong with your business (and how it can be fixed or improved) is to ask your employees – they know a lot more than than they are given credit for.

Once again, I believe that this is another case for “do not underestimate the power of the blog“, especially for marketing purposes.

WordPress – Comment Spam…solution deployed

Despite having nothing more than WordPress 1.5.2’s default comment spam protection enabled, I enjoyed many months where my posts received no comment spam.

Until yesterday. Until Barry wrote this. Coincidence? I think not, I’m sure Barry’s not a spammer!

Anyway, I’ve now installed and configured Dr.Dave’s [anti] comment spam tool, Spam Karma 2.

It looks very comprehensive and has received a lot of good feedback. I’ll let you know how I get on.

Agile in the Financial Times, Summer School, Day 18

I enjoyed my first business trip for August today – Edinburgh to Manchester and back again. And, contrary to some corporate travel policies, I returned home on a business class ticket – how did that happen? Business class afforded me the luxury of access to the BMI lounge at Manchester airport…where I picked up a copy of today’s Financial Times.

The Business Life Summer School series revolved around the subject of “Technology is the secret of an agile advantage”. Naturally, the word “agile” caught my eye.

The article itself was written by Mohan Sawhey, Tribune Professor of Technology and Director, Center for Research in Technology and Innovation, Kellogg School of Management.

It opened with:

“Today’s changeable markets require companies to value flexibility of efficiency and speed over scale”

This is rather reminiscent of the Agile Manifesto. Being responsive to change is the key driver here, if you are able to adapt your business direction, your product or your services such that they match market or customer needs, you will gain a competitive advantage. And how do you do that? Well, as Mohan says, “sense-and-respond” (responding to change over following a plan) organisational models that promote “modularity” can achieve this. In the software world, this is of course, iterative development.

Of course, Mohan’s mention of XML also caught my eye. With XML in the mainstream now, Mohan’s comments serve to firm home the huge benefits that XML gives us today. Yes, it is a really good mechanism for the development of agile IT systems. Mention of decoupling IT systems into layers (presentation and data are mentioned) proved to be a draw too. That said, the information Mohan presented, whilst correct, is a little over-used – sometimes people need to be told and told again before the good stuff sinks in I guess.

Modularity enables agility

Mohan explained that the key to “agile” is modularity [of products and IT systems] and decoupling of business processes and value chains, the latter might be seen to relate to the Agile Manifesto’s “individuals and interactions over processes and tools“. In other words, business processes should be placed far away from the associated value, i.e. don’t throttle the front-end service that adds most of the value by embedding a process overhead into the equation.

Increased modularity allows business processes to be swapped out, or “plug’n’play” as Mohan notes – this is similar to “Working software over comprehensive documentation“. Of course, we’re all used to modularisation when it comes to software development, it makes sense. And object-oriented design takes us further down the modular “plug’n’play” route. Leading on from this, modularisation helps us focus on the front-end value-add products and services, thus we are able to spend more time enjoying customer collaboration over contract negotiation (where contract negotiation includes all of the internal red-tape too).

However, the key take-away for me was found the last paragraph of the article:

Creating an agile enterprise is a transformation that needs to being at the top, with the leadership of the company. And it needs to begin with a questioning of the fundamental beliefs that drive the company.

The agile enterprise is risky to manage – you need to give control and ownership to partners…

Finally, Mohan’s box-out drummed it home:

Companies that have learnt to exploit technology can respond more flexibly to new trends and threats than their competitors (re-worded slightly)

Bloggers can be sued…

As part of the Guardian’s Blog Watch column, Bobbie Johnson picked up on the fact that:

“in general, bloggers do not believe people could sue them for what they have written on their blogs”

With the sudden profusion (or “viral nature” as the author of this study notes) of blogs, it stands to reason that somebody, somewhere will write something that offends somebody to the point that a lawyers are mobilised. 67% of the respondents reported that they lived in the United States, a location where more legal novels have been written about than I’ve had hot dinners…and from what I can gather here in the United Kingdom, we’re starting to go the same way. It’s easy to write controversial blog posts, a lot of us have a rants category for that purpose, but rarely do they get so heated that the next knock on the door costs £50 per 15 minutes and brings with it a barrage of paperwork.

So I guess the moral of this post is simple: be careful what you write for it may come back and haunt you. But it doesn’t stop at what you write…if your blog allows “comments”, you must be sure that the comments are tasteful too. It’s also worth ensuring that your blogging software is affording you a level of protection such that it is you and only you who can post to your blog – if others can switch on your PC or laptop and gain direct access to your blog for posting purposes, you could be in trouble.

Incidentally, the same can be said for web-based e-mail accounts like HotMail and GMail – “keep me signed in on this computer” is an easy tick box, but one that opens your e-mail account up to all sorts of trouble. What if your boss gained access to your “private” GMail account? What if an evil co-worker sent an e-mail from your private account? What if your laptop (or PC) was stolen? Do you “lock” your laptop or workstation when you leave the office for lunch, or to use the WC perhaps? These are ideal opportunities for the odd “quick” e-mail to be sent without your knowledge…secure your computer when it’s out of your sight.

The full story can be found here.

Exhaust my CD collection…I’m not alone…

Jenny Colgan reported that she didn’t think it was possible to get sick of all 4,000 tracks that she’d spent weeks ripping to iTunes…but that she appeared to have managed it.

Phew. I thought it was just me.

I too spent a long time ripping most of my CDs to MP3 format (yes I know I could be using WMA, but there’s a good reason, trust me!) , and I’m still not done.

I now have over 15GB of tunes. And I’m fed up with them. All of them. Even the tunes I didn’t know I had – this surprised me, entire CDs worth of tunes that I hadn’t heard or even knew I owned just turned up. But I’m fed up with all of them…I’ve sickened myself, too much availability has ruined it. Hopefully it’s a passing fad…either that or I’ll need to get some more music to listen to.

Luckily, I use an iRiver H320 which has a built in FM radio, so I’m not stuck for content.

Uncanny horoscope…

I don’t normally read these things, but I had time to kill, yada yada yada, I know you don’t believe me, etc. but it’s true!

Daily Mail, Gemini, 23rd August 2005:

There seems to be not end of things to organise and ‘cope’ with. Make a list! Then prioritise it! Next, discard the inessential items. There are two ways to go now: into chaos or towards order. If you want to be able to enjoy the good things that are undoubtedly in you life, you need to make sure you don’t waste valuable time on things that don’t directly contribute to you happiness and well-being. Concentrate on really important people and tasks. You’ll be amazed at what you accomplish.

Now, either the writer is short of material, or he has just returned from a Scrum course. Either way, it’s uncannily close to the truth…and it works if you’re not a Gemini!

A problem shared…

Way back in 1995, Kevin Cauble wrote a great article, Two Principles of Conversation. It was republished over at developer.*.

I particularly like:

Principle 1 – There is much to be gained by sharing your experiences, ideas, and problems with your peers.

I like it for a number of reasons:

Firstly, who are the best folks to estimate how long a piece of software will take to write? Answer: the folks who’ll be writing the software in the first place. Sharing your experiences, ideas and problems with your peers will ultimately improve your estimating ability and that has to be a good thing. There’s more about this topic in this blog post: #5 – Whose schedule is it anyway?

Secondly, a problem shared in a problem halved. Share your problems and other folks might/will come up with answers. It’s a good idea to make sure that you air your problems in a suitably qualified peer-group, otherwise you might get some poor answers. But nonetheless, problem sharing is a good thing, there is much to be gained from it.

Thirdly, it helps focus the mind such that you solve the right problem. All too often, and this is especially true if you find yourself isolated or working alone for period of time, your mind will play tricks on you and make you believe that you’re solving the right problem…when in fact you’re not…you’re off solving the wrong problem. Simply talking about a problem can be a real eye-opener and can result in a “seeing the light” moment whereupon you recognise that you were about to spend time working on something that wasn’t part of the solution.

If you don’t fancy reading the original article and are just a tiny bit curious about what the second principle was, here’s the spoiler:

Principle 2 – Managers HATE to see software practitioners conversing with one another.

I might write more about principle 2 later, however in the meantime, I would recommend that you read the article: Two Principles of Conversation.

PM#8 – Multi-tasking is evil

“Nobody can do two things at the same time and do them well.”

Don Marquis

Clarke has often lamented about how multi-tasking is evil, something that was emphasised in #7 – High workload means lower productivity…

Humans aren’t multithreaded, therefore we can only do one thing at a time (this applies to men and women, please don’t be shocked or surprised).

Overlapping activities vs a three-course meal
Invariably, the more work that you pile on an individual or the more work that he or she accepts, you’ll find that individual attempting to multi-task under the premise that they believe they can do two or more things and do them well. Most of us struggle to cook a healthy meal, getting the timing right such that the meat, the vegetables and the potatoes are all ready at the same time eludes us. So why should we expect the same individual in the workplace to be able to manage three work basket items at the same time and with the same delivery date? Unless the three work basket items are trivial, we should endeavour to work with the individual and ensure that the three work basket items are scheduled such that there is little or no overlap.

Why do we find ourselves multi-tasking?
Multi-tasking, it seems, is forced upon us because there is a fear that employees will either take too long on a task or will complete it early and have nothing to do until the next task is issued. If you’ve got staff like that you should fire them and hire some staff who like challenges and who like endorphin rushes when they start something and finish it…at which point they’ll go off in search of the next challenge. Keeping an employee or developer busy seems to be fairly normal – we all moan about how much work we have to do…instead of moaning (or blogging as some might say), go and start a piece of work, progress it in small bite-sized chunks. Not all tasks need 2 hours, 2 days or 2 weeks to complete – those that do can be broken down into smaller more manageable tasks that are easier to swallow (read: easier to start). When you do break a larger task down, do be sure to follow each of the sub-tasks through to completion…and don’t lose sight of the parent task (i.e. don’t be distracted and lose focus!)

Respect the schedule
We find ourselves multi-tasking because other people don’t realise that we might have a schedule (a sequence of events/tasks that we’re trying to follow). Other folks will happily e-mail you, telephone you, walk up to you and [in the words of Scott Adam’s Dilbert] “expect you to drop whatever you’re doing and work on their problem”. Quite how you tell these folks that they are upsetting your carefully crafted schedule (even if it is written on the back of an envelope, whatever works for you…) is likely to be a personal thing and something that varies from organisation to organisation. Whatever you do, other folks have to understand that you are not sitting idly by your telephone or inbox waiting for them to contact you…you have work to do, you have a schedule, you have deliverables. Multi-tasking or task-switching will make you less productive which has a spiralling effect on the health of the project and your own health.

However, being seen to have a schedule and offering to fit their request in to your schedule is likely to win you some points too. Find out when these other folks need you to do their work by, then negotiate to fit it in: it’s very probable that with the thought that they’ve offloaded work onto you, the other folks will be happy with a negotiated date that suits you more than them…after all, you are saving them doing the work in the first place.

As soon as other folks realise that you’re working to a schedule and that they are part of that schedule, your multi-tasking or task-switching instances should reduce. Over time, those other folks will learn to approach you in less disruptive ways, e.g. via e-mail, knowing that you’ll “schedule it in and get back to them”…well, that’s the plan at least. I’ve enjoyed some success with this approach, it does depend upon the make-up of your team.

This might sound like I’m contradicting the purpose of this post, but it’s not, trust me. Despite heavy workloads, most of us are guilty of some degree of procrastination. We’ll delay or put off starting a task because…because it’s too big, because we don’t understand part of it, because it’ll take a long time to start and finish. Fine, either break it down into the previously mentioned smaller tasks or just start it. I’m using this approach to ensure blog posts are published: I simply start a blog post and save it drafts. Every so often I’ll spend a few minutes updating the blog post until it’s ready to be published. It’s easier to find a few minutes here and there than it is to find a few hours. Obviously this approach is only useful where tasks can be tackled in this fashion.

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#7 – High workload means lower productivity…

My friends and colleagues over on the SellingAgile group were discussing productivity recently. Tony and Clarke were at the heart of the discussion, it went a little like this:

Tony made an excellent post, too long to quote here, but I particularly liked this:

In the age of interaction-centric systems, it’s all about speed. Forgo the false god of utilization. Concentrate on speed and concentrate capacity, so that those valuable software products and the mountain of moola that each of them can bring might arrive today rather than tomorrow.

To which Clarke asked:

Are you saying that if everyone is busy all the time then they will actually be a slower at doing things?

To which Tony responded:

Yes, Clarke, if we ensure that we have active projects enough to guarantee that every developer has project work available, then we _CAUSE_ the whole system of resources to work at approximately half its sustainable speed. Management teams worldwide are wasting approximately half of the capacity of their development teams and, consequently, half of their development payrolls.

It became clear that some folks believed productivity is low because we’re overloaded with work.

Basically, this boils down to the fact that software developers (amongst others) rely on creativity in order to do their jobs well. Without suitable periods of “down-time”, work simply moves from one task to the next with little regard for “can this be done any better?”

Tony then went on to make this remarkable statement:

Think of multiple marathon relay races. We have one team and many marathon relay races for the team to run. If we schedule the races so that one race must end before the next race can start, then our team doesn’t get to finish very many races per day or per week or per year. So we surely want the races to overlap. But for each of our runners we absolutely do not want his/her segments across races to overlap. That would force the runner to jump from track to track and race to race without handing any baton to a downstream teammate. So, we overlap the races, but we don’t overlap any one runner’s segments across races.

Today, due to our unfortunate and grossly inadequate understanding of interaction-centric systems, we schedule the STARTS of our races far too closely to each other. This guarantees that every one of our runners is always on some one track or another, running at least one race and usually several races simultaneously. Then we require our runners to make progress simultaneously on all their active races, by failing to prioritize the races. This forces each runner to hop from track to track and from race to race repeatedly, before the baton of any one race is transferred to the next teammate. This is multitasking in all its ugliness.

Clearly multitasking is absurd in the context of relay races. But it is no less absurd in the context of product development. Yet this absurd behavior is precisely what we cause when we strive to maximize utilization. The resulting lack of performance is a tragedy of our own making.

Whilst folks think that having a steady stream of work is good, it seems that we worry about a number of things:

  • that we won’t have time to complete the current task (and do it well)
  • that we won’t have time to complete the next task
  • this appears to be a recursive worry

So, my take on this discussion resulted in this:

  1. Start something.
  2. Focus on it using decent chunks of time.
  3. Do it well.
  4. Finish it.
  5. Don’t allow yourself to be distracted by “what’s coming next”. Don’t flutter from one task to the next and back again.

Leaving an activity in an unfinished state will cause further distraction as your mind will play tricks with you, you’ll be worried about the unfinished tasks whilst you are working on current tasks. Break your tasks down into manageable chunks (task time average = 30 minutes), proceed to start each task and finish it, allow yourself some downtime (if you refer to it as slack, it’ll be consumed by the project, avoid using the word slack). Doing less work should will actually make you more productive.

Related to this:
How much pressure is required to make somebody more productive?

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