Category Archives: General

Project Management

A problem shared…

1 Comment

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#, Project Management

PM#8 – Multi-tasking is evil

2 Comments

“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.

Pseduo-multi-tasking?
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#, Project Management

PM#7 – High workload means lower productivity…

1 Comment

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

PM#, Project Management

PM#6 – You were right and I was wrong

2 Comments

If you make a mistake, I’d like to think you would be man enough to admit it.

The trouble is, and I’ve seen this in so many places, there are a lot of folks out there who seem to be unable to admit that they made a mistake. I’m sure that we’re all guilty of covering up a the odd faux pas here and there, but there are folks out there who take the cover up to new [stellar] levels. These stellar levels include such things as poor decisions or incorrect decisions (more here) and choices that have led to projects going off on a tangent for months on end all because of parochial approaches that prevent acceptance of the bigger picture (i.e. focusing on one small part of the project without understanding the project as a whole).

Saving face is not all that important, doing the right thing is. In a project-based environment, saving face for long periods is detrimental [to the project]. When driving, if you accidentally take a left instead of a right, you will endeavour to correct the mistake as soon as possible…you shrug your shoulders and get on with the course correction. Please take this analogy to your current and future projects: if you make a mistake, your cheeks go red, you blush, whatever, please raise your hand and announce your mistake. Team members will thank you for it, the project will run smoother and will stand “one more” chance of coming in on time and/or on budget.

Whatever you do, don’t try to ignore the mistake, cover it up or keep running with the mistake as if it were normality. And accept that team members might point out the mistake and ask you to do something about it: don’t fob them off with pithy excuses whilst you insist that you are right and they are wrong. Project rarely have “get out of jail free” cards, if you think you’ve got one please be aware that the card expires very very quickly after use: expect to be found out. Long running cover ups or long running changes in direction are catastrophic for the project and the team member morale. Do not think of yourself, think of the project and the team members (learn from what Derek Laud had to say about a lack of selfishness) – it’s not your project, it belongs to the team and the end users.

Don’t ever be afraid to say: “you were right and I was wrong”, it’s the best thing for you, the project and the team members. And say it as early as possible (mistakes and oversights are typically cheaper to fix earlier in a 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, TDD

David Anderson interviewed by Robert Scoble

Channel 9 do a good job of getting life inside Microsoft presented to the outside world…here’s another fine example.

David Anderson, who has previously spoken at Agile Scotland meetings, was quizzed by Robert Scoble about “Agile Management and what we are doing with MSF for CMMI Process Improvement”.

Download and watch the video here.

The interview was littered with good advice, but I homed in on a couple:

developers don’t like two things

  1. interfering management, i.e. micro-management
  2. management not doing something when something abnormal happens

“Incremental development (Ed.with regard to TDD) only works when refactoring is part of the equation”, Ron Jefferies

It’s well worth the download, do take the time to watch it. Clarke sums David’s style up rather well: “David has a nice way of simplifying complex things”

Rants

Shopping for an MP3 player…

I’ve been introducing the in-laws to “Internet shopping”.

I struggled to explain this one to them:

mp3 players

“£29.99, you say, nice price, fully featured, state-of-the-art, tell me more.”

Clicking on the first link took us here:

mp3 player

And the second link took us here:

mp3 player

Two totally different prices, nothing like “Our price: £29.99” at all.

Granted, these prices are a little more realistic…

General, Project Management

Derek leaves the Big Brother house…

Derek Laud, was evicted from Channel 4’s Big Brother reality TV programme on Friday. What he had to say once he left the house was somewhat inspiring, and he said it with considerable eloquence, grace and civility.

First and foremost:

…team effort is absolutely everything..and that’s fundamentally what works

Unfortunately, I’m not sure his housemates really grasped that concept on the whole (irony accepted). Team effort is everything: in a group of 10 or more people, it’s not worth being the only person, or the only two people trying to do all the work. Delegation is part of the game, but so it responsibility – it’s no use just sitting watching one or two people trying to do all the work, chip in a help them (especially if they ask you to!)

“team effort” == community.

Followed closely by:

it’s a lack of selfishness that’s very very important in life

The World doesn’t revolve around you. If you didn’t do your job, it wouldn’t be the end of the World. It’s not about “me me me” [cf].

I found this quote interesting and somewhat close to home:

other people are much better about making their problems seem more important than anybody else’s

Me me me. My problems are more important than yours ,listen to me, let me talk your ears off. Yes, a lack of selfishness is important, but so is taking your turn. Everybody has their problems, we just have to prioritise the solutions by importance and need.

And to finish:

listen more, talk less

Feedback is important, there’s little point soliciting feedback if you don’t listen to it and act upon it. Similarly, there’s little point in a one-sided conversation (which by its very nature is at least a two-way thing). And if team members bring problems to your attention, they’re doing it for a good reason, be sure you listen to them and act upon them.

Politics aside, a combination of Derek and Boris Johnson would revive the Tory party, perhaps? Just a thought.

Rants

National Lottery…

I don’t know what’s more annoying, the National Lottery site going down just after I click submit whilst buying the office syndicate’s tickets or the fact that they’ve got a happy smiley face highlighting a little anticipation of it coming back up…

…I certainly won’t have a happy smiley face if the tickets weren’t bought: I’ll probably be lynched.

But anyway, rant, rant, etc. Can you believe that they’ve actually put a Trademark on the “site down” message?

lottery down

General

Hillwalk – Ben Lawers

Last month saw a few of us climb Ben Lawers, amongst other associated peaks.

Apart from the fun element, this was Scottish Developers way of showing appreciation for the sterling presentation Dr.Neil gave the group the day before.

Here’s the Google Earth image, tilted to show terrain:

Ben Lawers via Google Earth
Google Earth shows off the terrain rather well

hillwalk
Craig admires the view. CodeZone caps get everywhere!

hillwalk
That loch in the background is Loch a’Chait

hillwalk
Dr.Neil, myself, Dave, and James

hillwalk
Dave, James and Barry – posing for the camera just before Craig decides to “leg it” with Barry’s camera…3000 feet up and in the middle of nowhere!

hillwalk
Dr.Neil, Dave and myself at the top of An Stuc

hillwalk
A triumphant Barry reaches the top of Meall Greigh

Thanks to James and Barry for the photographs!

General, Rants

Security hype “stifling new technologies”

2 Comments

It seems that security concerns are preventing us making progress. Robert Jaques has an interesting piece in the September 2005 issue of PCW (UK). Yes, I know August has just descended upon us, however PCW does seem to be published some two months ahead of the actual month it represents!

Whilst the rest of the world are making progress with IP telephony/VOIP and wireless networking and wireless hotspots, etc. it would appear that there are some folks who are thwarting progress by following the maxim “if it ain’t broke, don’t fix it”. Well, in this situation, that maxim doesn’t hold true. For example, I’ve just returned from Microsoft TechEd in Amsterdam, where Microsoft was kind enough to provide [potentially] 6,500 of us with wireless access to the Internet. It was a remarkably liberating experience. I was able to check my e-mail whilst attending sessions, blog “live”, provide session feedback within minutes of the session finishing, etc. It was truly amazing.

How did we ever live without wireless? I can’t imagine the Internet without it now, never mind the connectivity gains that I’ve acquired after pushing the wired LAN into the dark and distant past (OK, so I’ve a wireless ‘bridge converting the wireless into wired for use in the study…it still means that I don’t have wires running all over the house, much to my wife’s delight!)

Life without wireless/VOIP might not be secure according to the hype mongers; however, can we believe them? True, wireless networks do open themselves up to a wider range of potential attacker – the attack surface extends itself to the far reaches of the wireless broadcast. And yes, early wireless kit was delivered (out of the box) with all the security options turned off or disabled…but I seem to recall that some operating systems were delivered in a similar fashion. Nowadays of course, virtually all wireless kit (and the aforementioned operating systems too) arrive with all the security bells and whistles enabled so much so it’s sometimes difficult to miss. With a little care, it is possible to secure a wireless network and/or VOIP such that there is considerable business benefit.

Life without wireless/VOIP means a mess of cables. It means a laptop, a rucksack and a bag full of various network cables and adaptors – I carry five RJ45 cables of various lengths and an RJ45-to-RJ45 extender that allows me to daisy-chain two RJ45 cables together if required. I didn’t carry such excess baggage to Microsoft TechEd…the only wires I saw there were those leading to from laptops to power sockets and from the VOIP handsets to the controlling PC.

Life without wireless/VOIP means having to find landlines or worse, mobile ‘phones. It means having to stretch a fixed line ‘phone across tables/desks to get it close to your laptop which is plugged in to the network and the mains – and because neither the network provider or the electrician spoke to each other, they both kept their infrastructure as far apart as possible. If you’re lucky enough to have a network provider and an electrician who speak the same language, the floor sockets that house their respective outlets/sockets, and this is especially true of electrical outlets, are sunk into the floor, hidden underneath a tightly fitting lid that soon comes away in your hand the minute you lift it open. And if that wasn’t bad enough, you try to plug your laptop’s power adaptor in, oh, the huge transformer prevents you from plugging it in…or, worse, you have a regular-sized plug fitted with a less than flexible cable…the power outlet’s live/neutral plugs so close to the edge of the housing that you can’t even bend the cable to fit.

And just think of the triangulation involved in plugging a laptop into the mains at point A, the telephone at point B and the network at point C. The resulting mesh is a potential safety hazard.

Just in case you had forgotten what life without wireless looks like, here’s a very tame reminder:

not wireless