Managing Product Development

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’m in Israel right now, doing an assessment. That means that I’m the one at “another” site for my US projects. Staying in touch is hard. I’m between 7 and 10 hours ahead of everyone I need to work with. Not easy to stay in contact.

I do some reasonable things while I’m here: rent a cell phone, use email and vmail when necessary, even IM. But Elizabeth Keough has an even better way to use IM. See IM is your friend.

Everyone sets their Yahoo Status message to show what they’re doing.

How smart is that?

Mike Kelly posted some reflections on Behind Closed Doors: Making Progress Visible. I love it when people understand why their managers are asking questions.

I met a manager recently who relayed his technique for making sure his testers stayed focused on their jobs. “Our defect-tracking system logs people off after 30 minutes of idle time. If they’re logged off, I know they’re not working.”

This was a new one for me. I’ve heard of counting lines of code. I’ve heard of counting cars in the parking lot at 7pm. I’ve heard of counting number of defects found or fixed (depending on whether you’re a tester or developer). All of which are incredibly stupid measures. But this is the first time I heard a manager use a necessary tool to determine who was working.

I can think of lots of reasons a person might not be actively working in the tool. I played the bounce-back game with a developer many years ago (”it’s a defect”… “No it’s not” … “yes it is” … “No it’s not”…) until I finally decided that what the developer was really saying was “I can’t see the damn defect, so it’s up to you to make it obvious to me.” Took me 4 hours to create the simple test case (I’d already written up the complex test case). In that time, I referred to the defect on my screen, brought up other apps, made notes, tried a few things on my machine, done research in the lab, talked to a few people, and finally, 4 hours later, wrote the 5 steps into the defect report.

I was working the entire time. And if my manager had used licenses as a way to log me out, I’d have had to change context to get back to the defect I’d been working on before the system logged me out. I’m sure it would have taken me longer.

When I asked him why he allowed the system to log off the testers, he explained that they didn’t have enough licenses for all the developers and all the testers to have the defect tracking system open at all times. How much was a license? $1500. Each licenses costs 3 person-days. How many person-days do you think they’ve wasted because someone couldn’t get a license or someone was logged off? A prime example of being penny-wise and pound-foolish.

If you need to keep the costs of development down, use agile lifecycles, or at least agile techniques. If the developers test code before they check code in, you might not even need a defect-tracking system. (Index cards will do.) But don’t keep the cost of development down by not providing all your technical staff with the tools they need. One manager’s salary (and there’s almost always a surfeit of managers in organizations like this) will pay for all the tools you need.

To track work, track completed, deliverable work (features/requirements implemented, tested, built, and able to be delivered to a customer). There is no other substitute.

Rick commented on my last post that some engineers think that status checking slows them down. Mark said that engineers push back on demos and pointless measurements and then said in another comment, “progress metrics can always be free.” Here’s how and what I look for, to determine status.

If I’m managing a traditionally-planned project, I have weekly status meetings with everyone on the project. (For large projects, each project lead has these meetings and I meet with the leads individually.) I ask people to explain the status of their work and what they’ll do next week, and how they’ll track status. I request that people think of their tasks as to-do lists with inch-pebble level work. I won’t put their inch-pebbles into the project schedule; that’s just too complex and I’m not about to track each person’s work. I ask people to monitor when they are stuck and to tell me if they need help in some way. Asking for help is fine. Floundering is not. I request that people peer review each other’s work product (unless we have more formal reviews in practice), so that they get peer feedback about the quality of their work. If someone’s working on a big work product, I ask them to consider what they want to show me: interim designs with chicken scratches, performance measurements of algorithms, number of scripts they threw away, something that shows me progress. Since the engineers determine their tasks, deliverables, and when they need help, I don’t usually come across as micromanaging them. I hear them describe their work products, when they’ve had problems or needed help, and I have a fairly good handle on the project state.

Every so often, I run across an engineer who thinks his work requires privacy to complete. When that happens, I explain that I don’t know how to manage the project adequately with his need for privacy, and what is he willing to show me or give me so I can see his progress. That doesn’t always work, so I ask him when his deliverables will be complete. If he gives me a date of more than two weeks, I explain that’s too long. In many projects, we can afford for one person to be off by two weeks, but I’ve never worked on a project where any one person could slip a deliverable by more than two weeks without affecting the entire project. I’m willing to give the engineer the benefit of the doubt, if he can come up with deliverables that are fewer than two weeks in duration, and maybe I can wait to see the status at the end of those two weeks. If an engineer can successfully deliver work every two weeks, I’m still nervous, but I can manage my nervousness. Once an engineer misses a deadline, we negotiate a different way to track tasks and status. So far, this has worked well. I’ve run into people who hated this, but we figured out a way to deal with my need for information. (I meet with the engineer whenever the engineer wants it, as long as it’s sometime within the normal work day.)

On traditionally planned projects, I send out an email every week explaining the state of the project. Project team meetings are optional. Problem-solving meetings for the project are not optional. (They are two different meetings.) I keep people focused on the end goal and aware of interim milestones.

On agile projects, status is much more obvious to everyone on the project. Since there’s a standup meeting every day, everyone explains what they’ve completed, obstacles they’ve run into, and what they’re going to do. Since I still have to prepare a report to management on project state, I send that by email to the project team also.

When I look for tangible work products, I look for: checkins, designs, how many designs were rejected and why, data about performance or reliability (depending on the product), algorithm development and debugging, people working together on pieces of the product, people working alone, how many people are actually working on this project, number of pizza cartons or other food containers, how long people seem to be at work. If I think there’s too much overtime, I ask people what’s happening and what we should do about it. I really want to prevent people from making stupid mistakes.

When I explain why I need information and the level at which I need the information, most engineers are willing to work with me and I obtain visible progress about the project state.

I was working on a newsletter article about how to see your project’s progress, and got stuck. It’s easier to see project progress on a project with a tangible deliverable; it’s much harder for software or a service project. So, I took a break and read Esther Derby’s blog entry, Start Seeing Software from 3/13/03. Esther suggests milestone reviews, retrospectives, and metrics. In addition,