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!

In the PM (it’s actually called “software methodology, but I assign a project, so students can experiment with methodologies) class I teach at TGI, I ask the students to create (and then use) a project dashboard, so they have a quantitative way to see their progress (or lack thereof). The students presented their dashboards last week.

One of the teams adapted a traffic light, with red, yellow, green, and blue (for done). The student who presented the traffic light to the class, said something like this, “We added blue, to denote done. I think it’s right there.” I said, “Can’t you see it?” He said, “No, I’m color blind.”

I did about 5 minutes of online “research” and realized that about 5-7% of men can’t distinguish red from green. Some fewer can’t distinguish between blue and green (the problem my student had).

So, if you’re going to use a traffic light (which I don’t like. See Sunny Skies or Storms? for an alternative to the traffic light), make sure your viewers can see it.

Labels: dashboard, project management

I taught my project dashboard workshop today. One of the things most people want to measure is progress towards project completion. But you can’t measure project completion progress unless you have completed features: developed, integrated, and tested features. A completed feature is done enough for someone to use.

Implementing by architecture leaves all the feature integration up in the air until the end of the project, so if you must implement by architecture, you just can’t measure completion until the end. That’s too risky for me. But if you implement by feature, you can start measuring completion as soon as you’ve implemented one feature.

I’ve encountered a number of projects where people didn’t know the context of their work. As developers, they were working on the thing they had to develop or fix today. They might remember what they had done yesterday, but there was no sense that they knew what they needed to do tomorrow, or that they were working on something that’s part of a whole. (I wrote an article about this years ago, Of Crazy Numbers and Release Criteria) I’m at a client now doing an assessment and I saw some data yesterday that made me realize people assessing projects need trend numbers, to see the data over time, not just snapshots of data.

When I do assessments, I always ask for trend data (about velocity, requirements, defects during the project and defect escape rates, sometimes code). For many of my clients, the data doesn’t exist, and it’s hard to obtain.

Trend data shows you the context of your progress, whether it’s fast or slow. Velocity charts show you how much work you’re accomplishing over time and how much change is in your project. Defect trend charts show you how well you’re dealing with defects (are they overwhelming you or are you keeping pace). Trend data allows you to see the context of a project. Are 15 (or 150 or 1500) open defects good or bad? It’s hard to know without trends. PMs can’t make decisions about how to guide the work until they know the context, not individual pieces of data.

If you’re managing project work, take a look at your project. Do you have trend data or daily (or weekly or monthly) snapshots? What would you have to do start gathering trend data? And what would the trend data show you?