Managing Product Development

About a month ago, I spoke with a project manager who’d inherited a project in chaos. No one was making progress. He was stumped–he’d never worked on a project where the developers couldn’t do anything, the testers couldn’t do anything, and time was just slipping away.

I suggested he try baby steps. What’s the first thing the project needs to deliver? Just focus on one small thing. He did have an answer, but the feature was large. He thought it would take 2-3 weeks to deliver it, coded as well as tested.

Since he knew what the team needed to do, he could use timeboxes to focus people’s attention on that work. I suggested he use one-week timeboxes, to make sure people figured out what they needed to do, just for the first week, and that the project team work together to make sure they were all working towards the same goal. Once he got the first week working, he could do the same thing for the second and third weeks.

The reason one-week timeboxes work to focus people is that when a project is in chaos, people tend to be in chaos too. They get easily distracted. A timebox, especially a short timebox is really good for helping people make progress and breathe.

He had never done week-by-week planning, so I suggested yellow sticky scheduling, focusing on the deliverables that would finish the feature. It’s not a hard concept, so he was able to do it.

I caught up with him last week, and sure enough the timeboxes along with focusing on one feature at a time worked. He and the team were able to show progress, which bought them a slight decrease in pressure from the their senior management team. Now, he and the team could choose how to proceed.

I suggested he continue with the timeboxes and incremental approach to the project, to make sure people stayed focused and didn’t drift into chaos.

“But timeboxes seem like such baby steps. Do I really need to stick with the baby steps?”

No, he doesn’t have to. But there’s no reason to think that the people won’t go back into chaos as soon as they remove the focus of the timeboxes. And if he stops implementing by feature, they will revert to no progress.

I’m sure there are other solutions to the not making progress problem. But if an entire project is stuck, try small baby steps to bring some focus and progress back to the project.

Here’s a common scenario I was discussing with a colleague last night: They’re at the end of a project. They used some combination of a serial lifecycle, becoming more incremental as they proceed through the project. But they still have a ton of open defects, and a few not-quite-finished features. My colleague was complaining about the hour-long (!) sit-down status meetings they have (the whole team, not just managers) every afternoon. Could I suggest something?

Yes, of course First, separate the team problems from the management problems. The managers get to triage the defects separately from the entire project team. Maybe a technical lead meets with them, but don’t involve the entire team.

Next, separate the work into one-week timeboxes, starting in the middle of the week. The project team has some idea about how many defects they can fix in a week, and how many features they can fix. Set up each week as a timebox, saying, “We’ll fix 38 defects and finish 3 features each week from now until the release date. We’ll decide on Tuesday afternoon which defects we’ll choose for the timebox starting Wednesday morning. If we have a show stopper problem, we’ll move that one to the top of the list and move whatever is lowest on the list out.” Notice what this timebox does: it makes it possible to see if people are working overtime on the weekend (a Bad Idea), it helps the team predict what done means for a specific time period, and it focuses people on the work to finish before the release. It also makes the managers rank the defects, so the project team works on the most important ones first.

Now, it’s time to address the status issue. With these inch-pebbles, it’s possible to have a 15-minute standup meeting every day. Note: If I was the PM, I would abolish the daily hour-long meetings anyway–the team gains no benefit from those meetings. If necessary, I would make a daily 2-minute appointment with each person. But a 15-minute standup meeting is even better. But if you, like my colleague, works in a place where people love their hour-long meetings, and never finish the meeting early, go to daily written status reports. (I have a template for status reports, too.)

Once the team has done this for a week, the PM can assess how close their time estimates are (how many defects they can fix and how many features they can finish in a week), as well as how many new defects are arriving each week. It might be time to “slow” down the defect fixing by adding reviews of the fixes, if the fixes aren’t actually being fixed. (I discussed this in my most recent Pragmatic Manager email newsletter. I haven’t posted that issue yet, but here’s one you might find useful, too.)

If everyone, including the project manager and the other managers are willing to be pragmatic, they have many options at the end of the project. But it’s clear to me it’s time to pull apart the problems and work on one at a time. Stop with the serial status meetings and let the project team get back to work!

I’ve been teaching a project management workshop, and one of the participants said something brilliant: “If you estimate in days, you’ll be off by days. If you estimate in weeks, you’ll be off by weeks.” If you estimate in months, you will be off by months.

Here’s why. The more you can break a big task apart, the more likely you are to remember all the pieces and estimate each piece well. The less you know about a task, the more gotchas you’ll encounter, and the longer the task will take. And, the bigger the task, the more likely you are to fall into student syndrome.

If you’re a PM and you don’t understand why your schedule is slipping, look at the general task duration. Got a lot of week-long tasks? Or multiple-week-long tasks? Those tasks are slipping, and you won’t know why or by how much until the time is almost done. I bet your project will slip for a duration of several of those multi-week tasks. Replan now, breaking all those tasks into inch-pebbles. Then you’ll have a much better idea of what it will really take to finish this project. And maybe, just maybe, you won’t have that much of a delay, because delays of weeks are very different than delays of days.

I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem.

So what happens if there’s a requirements problem that led to a design problem that led to a larger (greater than a couple of days worth of work) development problem? To me, that’s a short project. Once the problem is larger than just coding errors, it’s not maintenance, in the sense that I think about it. If you have to rewrite requirements or fix the design or involve more than just the one or two authors, it’s bigger than “maintenance”. And once it’s a small project, I can manage it with all the other small projects that are part of a release.

This means that when I work on projects, I see the work differently than others seem to. Because I believe everyone has to fix the problems they created, and because I see maintenance as just fixing those problems, I don’t have a problem with maintenance. I do have a problem with scope creep, but not in the sense of new requirements. I have a problem with trying to finish the work the project staff said was already done but isn’t.

That’s why I ask people to plan inch-pebbles, why I use milestone criteria, why I ask developers to implement by slice instead of by architecture, why I request that technical staff completely finish one thing before they go on to another. A by-product is that I don’t normally have to deal with maintenance, unless I’m coming into a project after it’s already started.

What’s your definition of maintenance?

Student Syndrome occurs when the person with the task waits until the last possible moment to start. Some people spend their entire academic career waiting until the night before a project is due and then starting it, pulling an all-nighter, and getting some (hopefully adequate) grade. Student Syndrome isn’t for me, but I know lots of people who do this.

I use these techniques to avoid Student Syndrome:

• Ask each person to develop inch-pebbles so that person (and the PM if necessary) can track progress.
• Use Estimation Quality Factor to continuously predict the end of their current task (not just the end of the project).
• Ask “What have you completed today?” Just asking can help jiggle people into starting the work.

These techniques work for me too, not just when I manage other people. Just because I don’t wait until the last possible moment doesn’t mean I don’t procrastinate every so often. (In English, that means I procrastinate too

Student Syndrome isn’t the same as being stuck, although if I’m stuck, it can look like I’m procrastinating instead of working on the task. I use a timeout to see if I’m stuck. For any given task, if I can’t make progress on it in about 30 minutes, I ask for help. 30 minutes may be too short or too long for your tasks, so adjust accordingly.

If you’re a PM or functional manager, notice if your staff are waiting until the last possible moment to start. If so, try something to help people start earlier. Late-as-possible starts lead to late projects.

---

The reason I thought of this today was because of voting. I hate waiting in line, so I vote in the middle of the day. Mark is an early bird, so he voted at 7:30 this morning. On an errand, someone told me she might not have time to vote. I asked “Can’t you take 20 minutes right now? There aren’t any lines. You could do it and come back to work later.” (She has the ability to do this.) She replied, “I’ll just wait until the end of the day.” Student Syndrome all over again. If you live in the USA, don’t delay. Go vote.

Just in case you hadn’t heard enough from me about inch-pebbles, here’s an article I wrote for Computerworld.com.

---

Bloglet readers, it’s possible I have finally convinced Bloglet there’s nothing wrong with my blog. You’ve missed a couple of weeks worth of postings. Sorry about that.