Managing Product Development

I’m particular about two things: calling a prose plan a project plan and calling a Gantt chart (or yellow stickies) a schedule. One of my colleagues emailed me last week, explaining he’d spent a week developing a project plan and was hoping I could take a look at it. “Sure,” I said. “Send it along.”

He did. It was a Gantt chart for the next three months, with one- and two-week tasks. I called him and asked for a project plan, with release criteria. Did he have any? No. Had he checked with the people who were going to do the work to see if they could buy into the schedule? No, none of them were assigned yet. Dead silence on my end, trying to figure out how to ask the next question: Did he realize his schedule was already behind because 6 people were supposed to have already started?

I finally just asked the question, ignoring tact. He was quiet. I asked, “Why is this schedule so important to you?” “My manager wants the project done in three months.”

Managers can want anything they want. But wanting it doesn’t make it happen. This is where it’s critical to get started on working by chunk, so you can finish some work, and see where you’re going (I use velocity charts).

He challenged me, “What do you use for a schedule if you don’t make a Gantt chart?” I explained I kept a three-to-four week rolling wave schedule, using inch-pebbles.

If you’re given a deadline, you don’t need a long schedule. You need a short in-depth schedule, along with knowing what done means. You need to spend your time managing the project, not defining a schedule.

If you want to try some templates for a project plan, take a look at the Manage It! templates.

Dave Christiansen wrote a lovely article, Plan a Better Project. He mentions Manage It!. Thanks, Dave.

I gave a talk at a local ICCA chapter last night, and met a project manager who told me he was managing 7 projects. I must have lost my poker face, because he chuckled and said, “Well, you do what you can with that many projects.”

You do. And I don’t buy that you’re actually managing them, or more than one of them. Sure, you might be doing damage control, or helping people see that they have a disaster. But you’re not evaluating and managing risk. You’re not checking in the team to know what done means. You’re not seeing if what you need from others across the organization will be ready when your project team needs it. Dare I say, you’re not managing. You’re busy.  (Way too busy multitasking.) You might even be providing help to the projects, but you’re not being proactive and you’re not there when the team needs you.

I don’t buy this business that a project manager can actually manage several simultaneous projects. Even if the projects are small. You PMs who are trying to do this: your managers are deluding themselves. Your call on whether to tell them. (Don’t tell them they’re nuts, that’s a career-limiting-conversation

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 one of the comments, for When is a Scrum Master (or a PM) Not?, Craig Brown said

Process, process, process.

What about people? At the end of the day the process is just one of several enabers (alongside culture, technology and tools, etc.)

Won’t an experienced and talented team just deliver regardless of the process? ANd doesn’t that indicate that the process is relatively unimportant?

Well, yes, if you have “experienced and talented” people, they will manage to deliver just about regardless of the process. My experiences over the last couple of months lead me to believe these folks don’t have the experience. They may well have the talent, but not the experience, or the self esteem to do what they know they need to do.

One of the reasons the XP folks are so adamant about their practices is because the practices create a system (a process, if you will) that helps people accomplish the work. We Tried Baseball and It Didn’t Work is a humorous take on what happens if you say you’re playing baseball, but don’t follow the process. Same thing with XP, Scrum, or cleanroom or anything else you choose to do. If you don’t follow the process, it doesn’t help. You can call it anything you want, but calling it Scrum (or something else) doesn’t make it so.

So what do you do with an inexperienced team? (Let’s assume they are talented.) I still think someone needs to help with the process, so the team gains experience and succeeds. Without the willingness of someone to stand up and say, “No, that’s not the way this is supposed to work. And, here’s why…” the team cannot be successful.

I’ve met process police, and no, I don’t want to work with them. But a little process does go a long way when organizing or managing a project. If I want to use timeboxes because otherwise people fall prey to Student Syndrome, I should have that option. It’s quite reasonable to want an iteration backlog before an iteration starts, so the team can estimate it and commit to it. It’s not reasonable for a person who’s not developing or estimating to lengthen the timeboxes and reject retrospectives because he doesn’t think it will help the team. The people who reject the agreed-upon process are not helping the team, even though they think they are.

Leaders, no matter what they are called, are the people who guide the team through it’s designated process. They are especially necessary when the team is inexperienced, whether that’s general inexperience or inexperience with a particular project organization.

I have a new column posted at Stickyminds: What Project Managers Need To Know About Testing. Also, check out the podcast related to the article.

I’ve also used Agile life cycles (Scrum with different size timeboxes) in combination on a project.

Here, the developers in the corporate location had a series of features that were big. I did suggest they break the features apart into smaller chunks for ease of estimation and implementation, but they didn’t want to The remote team was responsible for smaller chunks of features, and were having trouble estimating the size of their stories. They decided to move to 2-week timeboxes to reduce what they were trying to estimate.

I’ve used another variation on multiple life cycles, especially for larger projects where the project staff or project management didn’t want to or know how to use an agile life cycle. This combination life cycle has two incremental pieces. The developers (the top of the picture) use staged delivery.

The testers, on the bottom of the picture, use design to schedule. This way they keep up with testing as much as the life cycle will allow, and if they are forced to finish the project early, they have “finished” all the testing to date. They don’t have partial bits of tests–they know what they’ve done and have not yet done.

I’m not a purist. I use whatever tools make sense for the context I’m in, and when it comes to organizing projects, I use whatever life cycles–in whatever combination–make sense to me. In response to a mailing list query, here are ways I’ve used life cycles for a few projects.

Let’s assume you’re collaborating with another organization. You would like to define an architecture sooner rather than later. You’re nervous about an architecture that emerges from implementing some features–you want a little more planning than that.

So you decide to prototype the architecture for a little while in the project (an iterative life cycle), and then move into implementing by feature (incremental life cycle). I’ve used this combination life cycle with and without timeboxes.

Is this a perfect life cycle? Nope. But it beats the uncertainty of a waterfall.

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.