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.

Rules of Jazz

My kids are both into jazz. They have a pretty good program at the high school they both attend. I heard someone talking about the rules of jazz recently;

1. Learn the rules
2. Practice the rules
3. Break the rules

The idea with jazz of course is to improvise, but that doesn't mean play which ever notes you want. However, it does mean you aren't just playing the notes written on the paper.

This is also the idea to having an adaptive project management approach. First, learn the rules. Get your Scrum certification, read some books, or attend a conference. Apply what you learn on your projects. I've talked to a number of folks that say the way to implement Scrum is to first do it by the book (rule 2).

Once you get to know what you're doing, move on to rule 3. Every project is unique, so figure out how to break the rules for your project. Again, it doesn't mean drop everything. It means knowing how to improvise without throwing the whole structure away. Have you had your jazz today?

Don't have a backup plan

I'm still working my way through Seth Godin's Linchpin and came across another good idea. Don't have a backup plan. If you do, you could give up easily on your idea because of the backup plan. You know you have a fallback position, so you fall back instead of fighting. Rather than having a backup, keep pushing on your main plan until you are either successful or you truly fail, and if you fail, learn from it.

Passion

One of the other books I'm making my way through right now is Seth Godin's Linchpin. The book is about making yourself indispensable so your company can't do without you because you're so unique and valuable.

One of the topics is passion. I recall when I was interviewing for the job I have now, one of the interview questions was "what are you passionate about?" Of course I said project management.

The idea here is that if you're passionate about something, you are going to work on it not because you're getting paid but because it's important to you, the end result is you become a linchpin.

So my question to you...are you passionate about what you are doing? If not, how can you find the passion?

Are you part of the problem?

I am reading Karen White's book, Agile Project Management, A Mandate for the 21st Century. She uses the term adaptive problems to describe the types of problems our projects are meant to solve. I've see this term used before, it means our problems can't be solved by our traditional tools; we have to adapt out tools to meet the specific problem. Applying our standard approach just won't work on the complex problems of the 21st century.

This can apply whether your using agile or a more traditional approach to your projects. If you blindly follow a standard approach, you may be creating problems rather than solving them. We have to admit that we don't know the answer and be willing to learn as we progress through the project.

I've seen this with one of my clients. They were following agile and all the ceremony associated with it. They had their stand up meeting, iteration planning meeting, and even their retrospective, but I didn't see their approach evolve as the project progressed. The retrospective became a thing they had to do, because the methodology said so, but it wasn't helping them learn and adapt on the project.

So where do you draw the line? You don't want to throw the baby out with the bath water; abandoning the things that are working, but you have to be willing to adapt and fix the things that don't work. This is where you need to be a leader and help the team adapt while focusing on delivering the value your project was undertaking to deliver.

For example, if you are measuring progress through story points and you drop in the number of points you deliver from one iteration to the next, you need to figure out why and adapt so that next time you deliver more. So how are you helping your team evolve today?