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

Tweet This Post

If you haven’t read Duane Nathaniel’s thoughtful comment on What Happens When You Can’t Finish What You Wanted in an Iteration?, do so now. Duane makes some great points.

RUP has iterations; they’re not timeboxed–they’re deliverable-based. (Take a look at the link that Duane points to.)

In the RUP, an iteration results in a deliverable. If it takes a little longer to get to the deliverable, that triggers some decision points. But while the RUP uses iterations, it doesn’t use timeboxes.

Timeboxes are time-based iterations, not deliverable-based. Which is why if you’re using timeboxes, it does matter if you keep to the timebox, because the timebox allows you to compare what you completed in each timebox.

This says to me: decide if you want a deliverable-based iteration or a timeboxed iteration. The two are different. What you get is different. With timeboxes, it’s much easier to compare velocity and track estimates. With deliverable-based iterations, it’s easier to deliver some specific thing to someone else, and create decision dates in the schedule. Your project might need one or the other. Maybe pieces of the project need both.

Duane was right when he said project managers need to think about the tools they use, and make sure they’ve chosen the right one for the situation.

Labels: iteration, timebox

Tweet This Post

Pawel caught me being ambiguous. See his comment, “1. I’ve seen features/fixes which required 2 days to be developed and released.”

Sorry, me too. But what I tried to say was this: A feature was estimated to be some duration of person-hours. Those person-hours have come and gone. The feature still requires another 10-12 person-hours, according to the developer. In that case, I don’t trust the estimate of 10-12 person-hours left. In my experience, the reasons for the delay generally have not been addressed. If interruptions caused the delay, more interruptions could still happen. If the delay was caused by having to change the architecture, that could happen again (and I suspect it’s likely). In my experience, until the feature is done, it’s quite difficult to predict when it will be done, which is why I like to start a new iteration to make sure it gets done.

I tried to imagine what would convince me that an updated estimate was more accurate. In the past I’ve only had one thing that would convince me: I would have to see visible progress of more work complete (more pieces of the feature complete) to agree that the estimate of what’s remaining to finish is correct. I’m trying to think of more things, and can’t right now.

Labels: estimation, iteration, timebox

Tweet This Post

I ran a little workshop today about transitioning to agile. I was talking about timeboxed iterations, and one of the participants asked this question. “So I don’t quite finish one of the features I want to finish in this iteration–and it’s the end of the project. I think it’s going to take me a couple more days. Do I extend the iteration or do another iteration?”

I said, “End the iteration at the end of the timebox.” There are lots of good reasons to do so: retain the reasonable pace and rhythm of the project, be able to gather data to compare this iteration to previous iterations, and to see why the team thought they could finish all these features in an iteration but couldn’t.

The participant didn’t agree with me. He has deliverables to other people. He can release at the end of an iteration. If he starts another iteration, why should people wait 4 more weeks rather than 2 days for the release?

Aside: I’ve never seen a 2-day estimate at the end of the release actually finish in 2 days. I’ve always seen it take several weeks. But let’s assume it really is just 2 more days of work, and feature is the only thing left to do. He could start another timebox and end it early. Or, why not just use an interim build as the deliverable, if the build is not for an end customer?

The class had a vigorous discussion about whether to end or continue the timebox. I hope that he tries ending the timebox when the time is over–otherwise it’s not a timebox. It’s too easy to let this iteration go over by a couple of days, let the next one go over by a week, and pretty soon you’ve got 5-week, 6-week, 7-week iterations, and the value of being able to do iteration re-ranking of features and the ability to make releasable software every x (here 4) weeks is gone. You’ve got something that looks like a staged delivery lifecycle, assuming you’re integrating as you go.

So, what do you do if you have just a little bit left in an iteration? I suggested that aside from ending this timebox on time, that they reduce the timebox duration to two weeks, and see if that improves their estimation and iteration planning. (My concerned participant was not excited about that option.) If you have experience with this, please comment.

Labels: iteration, timebox

Tweet This Post