Now that I’m approaching the end of my minivan years, I’m looking for a relatively high mileage four-door sedan. I have a few other requirements, but if you look at the comparisons of cars, you still don’t see US carmakers in the top tier for high quality/low price/high gas mileage. And if they are, the cars are not fun to drive.

I know enough about the car business to be dangerous, not to be helpful. But one of the reasons Detroit is in so much trouble is that they have such long cycle times. It takes any of the US automakers much longer to bring out a new model than any of the other non-US automakers. The longer it takes to finish a car (and let’s not talk about what done means here)–the cycle time, the longer it takes to see if your strategy is right. If it takes you 2-3 years to take a car from idea to manufacturing, and it only takes your competition 1 year, who’s more flexible? Who can react to a relatively changing market?

In my work with high tech companies, the organizations who can release faster (and I mean done, not releasing a product with major defects) have a variety of term strategies. The have near-term strategies, mid-term, and long-term. If you only have long-term, it’s like a waterfall project; you can’t get any feedback on the strategy until too much time has gone by. (Yes, their portfolio management does reflect their planning.)

To be honest, in this economy, everyone needs a short-term strategic plan that you can adjust frequently. Hopefully, you don’t have to throw it out, but just adjust it. You also need a mid-term plan so you can keep your eye on the path you think you want to take. And, you need a long-term plan so you can understand and adjust the business you’re in.

How to do this? Make your projects short, or at least, have them use an iterative/incremental lifecycle, so you can finish them at the end of a timebox if you need to. Now, at the end of each timebox, you can see progress and adjust if you need to.

I do understand that building a car is not like building software. The cost of the raw materials is huge, so the kinds of prototyping you do and the duration of the prototyping is quite different. But organizations who can successfully prototype quickly and move to manufacturing quickly have a marked strategic advantage over those who can’t.

And that’s true no matter what your business.

I haven’t been using the word “abandon” when I describe stopping projects. I’ve been using the word “Kill” and the concepts of permanently stopping projects (killing them) and putting projects on the parking lot (stopping them for now). John actually says the words from a developer’s perspective:

It can be a tremendous relief to abandon a project.

He’s right. It is a huge relief to stop working on a project.

Here’s why I’ve been using the word “kill” instead of abandon. I want people to make a conscious decision that this project is not worth continuing at all. (The three possible decisions are commit to; kill; or transform a project.) Abandoning feels more like we can just stop the project in whatever state it’s in and walk away from it.

But I don’t know people who can do that. Every time I’ve seen managers attempt to abandon projects, the technical staff want to wrap things up, or get them to a state where the project can be shelved and restarted again later. That’s why I separate the ideas of stopping a project for now (and putting the project on the parking lot) and killing the project.

Here’s an example of why I feel so strongly about this. I was working for a small company as a developer many years ago. We were not making enough money. Management stopped a project “for a while” where the duration was indeterminate. Over lunch, I asked my boss when we would start it back up again. He said, “Never, with any luck.”

But that’s not what was communicated to the technical staff. One developer said, “Well, management has abandoned this project. But I’m not. I’m going to save this project.” Ouch, not what management wanted and not what the company needed. The company needed us all on a project that could actually make money, not the money pit. But the other fellow thought that management had abandoned the project, not made a decision to stop it. If our management had considered the killing or parking of projects, maybe my colleague would not have continued working on a project that had no future and was diminishing the ability of the company to make money. We would have been in better shape if we had killed that project.

Maybe kill is too strong a word.  But if we want to stop a project permanently, I do want to kill it. I don’t want people doing skunk work on it. I don’t want more investigation. I do want it killed. For me, abandon isn’t a strong-enough word.

And, if we can’t sufficiently fund this project now, I want to put the project on the parking lot, or somewhere in the unstaffed work list.

I hope you chime in with your reaction about abandon vs. kill.

We have only two registrations available for PSL in Sweden left. Take a look at the information page if you think you’d like to participate.

He said, “I want to teach a thoughtful kind of agile. The kind where you work in timeboxes, but you still have requirements documents and functional design specs before writing any code.”

I replied, “That’s not agile unless the customer is demanding the specs as output. Are they?”

“No. But it’s impossible to do good software development without specs. I have xx years of experience that says so.”

“Your years of experience in a serial lifecycle don’t translate to agile, or even to an iterative or incremental lifecycle. Can you even imagine a project where you don’t need specs?”

“No.”

I tried again. “Have you worked on an agile project?”

“No, I was planning on talking to people who had worked on agile projects to see what it was like.”

I was angry and frustrated at spending time with this person. I declined the opportunity to co-teach. Here’s someone who’s never been on an agile project, who’s never tried another path, who wants to teach “thoughtful” agile–and pass it off as the real thing.

Maybe this isn’t criminal, but it’s darn close.

If you’re looking for agile training, ask the instructor about his or her experience doing, coaching, managing, whatever agile projects. Don’t blindly look for certification or a syllabus you like (although a good syllabus is helpful). Ask about experience. If you’re learning how to pair, how can you learn from someone who hasn’t and doesn’t know the pitfalls? If you’re learning how to use continuous integration or timeboxes, how can you learn from someone who’s never used CI or timeboxes?

I don’t buy the “I can hear about it and teach it” argument; that’s what leads to “People who can, do; people who can’t, teach” maxim.

Thoughtful agile is when you choose an agile lifecycle or set of practices, and follow them to the letter until you succeed. You inspect and adapt as you go. After you’ve succeeded, then, only then, can you change things to make more sense. (Read Ron Jeffries’ article We Tried Baseball and It Didn’t Work.) But you can’t change agile until you know how to make it work. And, if you can’t do agile, have never tried agile, and have no real idea what agile is, you can’t teach it.

Just had to get that off my chest.

P.S. Added the before writing any code to make it clearer what I objected to.

Maybe they went to the resort to do strategic planning. An off-site is good, as well as leaving behind laptops, pagers, pdas, everything that can interrupt you. Keep the tools, leave the interruptions. If your business has changed or needs to change, as I would hope it does after being rescued from bankruptcy, you do need to do strategic planning.

Here are the strategic planning steps:

1. Define your mission. (Why are you in business? Who do you serve? What benefits do you provide?)
2. Analyze the current situation
3. Define the plans for the new situation

There are lots of ways to do the analysis and planning. SWOT (Strengths, Weaknesses, Opportunities, and Threats) is a common way because it’s easy to see and easy to do wrong. Armstrong has a different approach: Seeking commitment as you specify objectives; generate strategies; evaluate strategies; monitor results. Armstrong’s approach appeals to me because it’s an iterative process, not something you do once while at a nice resort. There are other approaches also.

One of the best ways to do strategic planning is to do it constantly. No, not to take off-sites constantly, but to devote a little of your time each week to reviewing the mission, analyzing the situation, and see if you need to redefine your current plans. Of course, for that to work, you need data about sales (or the equivalent if you work in IT or a non-profit), where your projects are, and if you are truly serving your chosen customers. Then, once a month, maybe at the project portfolio evaluation meeting, you can review the strategy.

You might still need to do an offsite once a year. But not a really ritzy resort, where the booze, the golf, and spa treatments take you away from the business at hand. (Manicures and pedicures are not necessary for strategic planning.) Strategic planning is work. Hard work. Don’t treat it like it’s a day at the beach.

Full disclosure: Yes, I facilitate strategic planning meetings. They don’t look like the AIG meeting.

P.S. I forgot to point to the Armstrong paper: The Value of Formal Planning for Strategic Decisions: Review of Empirical Research

Yes, I need a new microphone. It’s on my list, but not for this week

She’s right. You certainly can’t finish something you don’t start. But the real question for all of is: Should we start this project at all?

My current todo list is way too long. That’s because we took a couple of days off to visit with Mark’s family, and with the Jewish holidays mid-week both last week and this week, I’m “losing” time to family and personal obligations. (No, I don’t really think of it as losing time, just about the actions I choose when.)

In order to get my list of projects down to a manageable number, I’m choosing which projects I need to finish this week, which ones I need to make progress on, and which ones can be postponed starting until next week. Notice that I listed the projects I can finish first in that list.

I hate having partially finished projects, which is why I’m trying to finish a bunch of things this week, even though it’s a short week. I literally get stuck with all the projects on my list if I have too many projects.

Here’s my general mode of working:

1. Make a list of everything I have to do. Get it out of my head and onto paper. Yes, this is directly from Getting Things Done: The Art of Stress-Free Productivity by David Allen.
2. Look at the list and see when I have to complete what. Make sure I know my interim deliverables.
3. Lay out the deliverables week by week for a few weeks (not more than 4 weeks total, generally only 2).
4. For the deliverables owed this week, I do 2 things:
   • Ask, “Should I do this project at all?” It’s worth making sure this work is still valuable.
   • If yes, finish the deliverable this week. Now, my deliverables may not be done-done-done. I might have to draft an article or something and let it sit for a few days, but it’s a deliverable to me.
5. Of the deliverables this week, see if there is something I have to finish earlier rather than later. Do those.
6. Make sure I ask “Should I do this project at all?” for each project left.
7. Of the rest, do the ones that take the least time (which tends to be the most valuable for me), and get them off my plate. Since I don’t estimate that well, I never know exactly how long things take, but I’m pretty good at relative sizing.
8. Loop forever.

This is the essence of project portfolio management. I happen to be using it for myself, but it works. If you know that the work is valuable, then it’s a matter of slotting it into your week or weeks. And, if you use inch-pebbles the way I do, it’s easy (well, easier) to keep up with the work.

When my friend says she starts lots of projects and then decides if it’s worth finishing, she’s asking the “Should I do this project at all” question repeatedly. I tend to ask that question before starting, but the key is to keep asking. If you don’t, you are throwing good money after bad, wasting time.

If your projects are hobbies, it may be worth starting a bunch of projects to see what you’re interested in. But if you are making decisions on behalf of the organization, timebox each project. Make sure you know what the deliverables are and see if the team can finish those deliverables in a timebox. Now, your starting and finishing makes sense.

Many people who travel are employees. They are just not your employees. No, I didn’t use the elevator–although I was tempted. (That’s the evil part of me.) But it would have been much more convenient. The elevator I was allowed to use made me walk far out of my way on the arrival floor and then back on the baggage claim floor.

Why is it easy for your employees and not me? Why do you trust your employees and not me? Ok, for airport security, it’s probably the right thing to not trust anyone. But I sure would like to see employees use the same entries and exits I use. I don’t see why I should trust anyone when it comes to airport security.

We see this in software all the time. Have a problem with an application, call the service number, and the nice folks fix you up in no time, but not with a command you can use.

Is software security the same as airport security? (I argue no. In some ways it’s much more scary to entrust your vital information to a software application.) What would you have to do to your application to trust me to do the right thing? Even if I’m not your employee?

Aside from spending 50,000 miles (is it possible to get a ticket for 25,000 miles? We haven’t in years), it cost $5 for the ticket, $75 for the “services fees” and $15 to check one bag.

Yes, this is still cheaper than buying a coach ticket, but not by much.

I understand why the airlines are doing this. The real question, is what’s the effect on flyers, especially frequent flyers? Will I still fly with my family someplace I can take them on frequent flyer miles? Maybe not. Not if it’s still going to cost us $400 to get there (4 people, $100 each ticket). If our “free” tickets are no longer free, we will think long and hard about traveling and spending our money someplace.

But the real question is what about my expectations? When I originally earned those miles, the ticket fee was $5. There was no additional service fee. There was no bag-check fee.

This is the problem with “loyalty” programs. If you have to change the expectations of the consumer in the future, how loyal will they stay to you? If you’re a frequent flyer, you have loyalty  to some airline. If you, like me, live in a non-hub city, you have loyalty to a number of airlines (not loyal at all, is it?).

Promising a return in the future for a product you buy today is tricky business. If you’re trying to hold onto your customers with a loyaly program (this can be as little as a customer service agreement), watch out if the price of holding onto your customers increases. You could find that your loyalty program is working against you, rather than for you.