Change what you're passionate about

I came across an interesting idea in Seth Godin's Linchpin

Transferring your passion to your job is far easier than finding a job that happens to match your passion.

I've read a lot lately about how you should figure out what you're passionate about and then find a way to make money at it. I think about photography, which is something I am passionate about. Would I feel the same way if I had to do it to make money?

The alternative that Godin is proposing is to become passionate about what you're doing now and that will in turn make you more successful because you bring your full self to work.

Graduation

My niece graduated from KU School of Journalism this past Saturday. The keynote speaker talked about 1988, the year most the students were born. I started thinking about how much journalism has changed since then. This was pre-web. Not many people even had home computers back then and newspapers had no idea what was coming as far as the changes in their industry. The professors must spend a lot of time updating their knowledge so they can send graduates out with the latest skills, but that won't be enough. The new graduates will have to continue to keep their skills updated if they want to remain competitive in the workforce.

How much time are you spending updating your skills? Stephen Covey talks about taking time to sharpen the saw; stepping back from the day to day work and focusing on your skills. Finding the time to do this can be challenging, but the options are also increasing. Now we can attend a 1-hour webinar on a topic of interest. We don't have to take 3 days off and attend a conference just to pick up some new knowledge. There are other on-line training opportunities, self paced classes, and of course books, blogs etc. What you need to do is make the time. Block off an hour or two this week to sharpen your saw so you can keep up with the changing world.

Anatomy of a project delay

So I was playing a small part on a large program not to long ago that was marching to an impossible date. Late in the game, the senior executive decided to push the roll-out date by a month, recognizing that the original date was not achievable.

So my first question was, why did it take so long? I can understand keeping the pressure on, but I think there's a difference between an aggressive date and an impossible one. In one case it will motivate you to work hard, in the other, it will only discourage you. Did this decision maker not have the information needed to make an effective decision? Were people afraid to provide the information?

Of course the throw more bodies option was used at one point prior to the delay. Anyone who has tried this knows that this approach doesn't really work. Nine women can't have a baby in a month and you can only divide up a project so much before you're spending more time on overhead then on development, not to mention the increased complexity of communications.

I've seen a number of huge projects that go down in flames and every time I see a new one starting I have to wonder why. In some cases it may be necessary, but in many cases a better option might be to break the big program down into more manageable chunks. This will reduce the overhead, communications challenges, and impact to the organization.

Done

So this week I introduced my team to the concept of done and done-done. I first got this idea from Dave Prior. Done means the developer thinks they've finished the task. Done-done means someone else has verified the task is really complete; such as a tester saying it passed testing or and end user verifying it is what they need.

This becomes important when you are trying to accurately track your progress. If a developer says they're done but they forgot something or it doesn't work right, there's still work to do. You may be nearing the end of your iteration and have a lot more work left than you think if you have a lot of tasks in the done stage but not really done-done.

So I don't even try to get % complete estimates I have found these to be notoriously inaccurate. I ask the developers to tell me either not started, in progress, done, and done-done. For those tasks in progress, I look for when they will be done. The tasks are all pretty small, around 8 hours of effort. That way, if I don't see at least some tasks getting done (and done-done) each day, I know I have a problem.

Agile is about being able to identify when you have problems as early as possible so you have more time to fix the problems. Having an accurate status plays a strong role in knowing the health of your project.