Think back to the last time you joined a new organisation. What was your onboarding like? “Hi, here's your laptop. Here's where the toilets are. Here is the printer. Here is the cupboard with the pens. Here are a whole bunch of people whose names you won't remember for weeks. Here's a technical introduction to the work. Here are your logins to the tools you will need. Off you go.” There might be a welcome lunch to help you get to know the people you will be working with, or some sort of ritual embarrassment at the next all hands meeting so they can "get to know you" a bit better (what's one thing about you that no one knows...). There will probably be some mandatory, cover-our-legal-butts "training" in health and safety and various HR policies that will leave you feeling dumber than when you started.

I suspect most people around the world have similar onboarding experiences in just about every organisation. It's the way things are done. And it's wrong. Not so much for what it includes, but for what it leaves out. The traditional onboarding experience misses some crucial things that help new people get settled into a new role in a new organisation. While it might give you the basic mechanics of your job, it doesn't help you integrate into the new organisation. You are left to discover all the hidden little things all by yourself. The fact that we can't raise that topic in meetings because of last time. The fact that while the process says this, what we actually do is something else because of history. Or the fact that, given a choice between this and that, we always chose this because that's what is important to the organisation. In short, what traditional onboarding doesn't do is introduce you to the culture of the organisation you have just joined.

A few months ago I saw a meme floating around contrasting a good agile team with a group of cowboy coders. Their chosen metaphor was a nautical one. The good agile team was the navy (age of sail style) - disciplined, focused, effective, working together for a common purpose. The bad team was, of course, pirates - rough, undisciplined, attacking stuff at random, scary but ultimately ineffective.

I looked at that, and knowing a little something about pirates (real ones, not the Long John Silver/Jack Sparrow/Captain Hook type Hollywood ones) it didn't quite ring true. In fact, if you look a little deeper, the age of sail navy is actually quite a good metaphor for traditional organisations and pirates actually make a great agile team. Since this is International Talk Like A Pirate Day, heave to for a moment ye scurvy dogs and let me explain.

The responsibility trap is a very easy one to fall into. The symptoms are easy to spot - it's 11pm, you are sitting in an empty office, buried in work up to your eyeballs. Everyone else went home hours ago. Weekends are a myth. You haven't seen your family for days. The agile principle of sustainable pace applies to everyone on the team... except you. How did it happen? The trap is a really easy one to stumble into because it's insidious. You can wander in without realising you are inside, you won't notice until you are deep inside and by then it's too late. Try to leave and the trap will snap shut around you. While anyone can fall into the trap, it's particularly easy for people in expert, leadership or coaching roles to get stuck in it.

The trap is really simple, it works like this - the team needs something done. You, as "the expert" in the area, take it on and do it. The next time it needs doing, you do it again. Now, everyone just expects you to do it. Then something else comes up and, as "the expert", you step up and do it. And so on, until you are buried in a pile of work. Your intentions were good - the team needed something done, they were busy, it was urgent, you did it. What's wrong with that?

They say that when all you have is a hammer, every problem looks like a nail. It’s the same in business – when all you have is a project management methodology, everything looks like a project. Most organisations have become very project focused. Everything is a project. New release of software – project. Some process change – project. That’s great. Projects are good. They are certainly better than the ad-hoc approach we had before projects. But projects do have some drawbacks.

To work out what the drawbacks are, we need to look at what a project is. A project is defined (by the PMI who should know) as something that has a defined scope, a defined start and a defined end date.  So projects are finite in length. Anything without an end date isn’t a project, it's business as usual.