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.

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,

• Look at the nightly builds: can you build nightly and then run an automated smoke test that passes?
• Don’t forget to ask your staff about their confidence in the end date: do they still think they can meet the requested completion date?These aren’t the only ideas for seeing your project’s state, but it’s a start.