Managing Product Development

I’ve been working with several clients on their transition to agile approaches to their projects. They all have a common state:

• Many features to implement
• Huge technical debt
• Many defects

They want to get a handle on all the work they have to do. I suggested they consider three backlogs, making sure that for a given iteration, they consciously choose what they want from each backlog so that an iteration has only one backlog, all agreed to by the product owner. That is, they bucket the work by features, technical debt, and defects. Rank each of those buckets. Now, for each iteration, the product owner chooses from the lists. I recommend looking at the #1 slot in each bucket. Which of these three is the real #1 for this iteration? That goes on the iteration’s backlog. Now, the next one from that bucket pops up and you only have three things to compare again.

One of the problems each of these organizations has is that their technical debt and defects were invisible to the decision-makers. Now the technical staff and the project managers have a list that is is visible to the product owner/customer. None of the work is secret–it’s all out in the open. They can discuss, poke, prod, ask, and negotiate to a reasonable conclusion.

It’s too early to tell if this will work for them. But the value of the three backlogs is that they can look across all the potential work in the organization and make a conscious choice for now. That choice doesn’t have to be permanent. Because they are working in backlogs, they have a shot at making decisions and adapting their choices later.

Tweet This Post

I was at the Better Software conference last week, met a bunch of great people (including Jim Shore and Joel Spolsky).

Another important person is someone who’s not famous–and important nevertheless. A senior tester explained her situation and asked for some help. “Most of our testers can’t read code. And, we don’t know what the developers are putting into the code when they fix problems. Even if the testers could read the code, we don’t know what to look for. We don’t know what to test. The developers add and change features without telling us.”

I asked if the developers had to write check-in comments. She said that they did not. I suggested she work with the build people to write a script that forwarded every check-in comment to an email list of all developers and testers. If there was no comment, it would be an empty email with just the person’s name and the filename. If there was something in the email, she and the rest of the testers might have more information with which to test.

On this project, there is little transparency about who is doing what and the kind of progress they are making. Normally, I wouldn’t email check-in comments to an entire project, but if there is no other way to see what’s happening, it might work.

Transparency in a project is key to the project’s success. No, it’s possible that not everything has to be transparent. If you’re working on a project where you have different levels of clearance for product content (something that occurs on DOD projects), then it’s critical to keep some content opaque, not transparent. But most of us work on projects where transparency would help–sometimes dramatically.

I didn’t gratuitously name-drop at the beginning of this post–I had a reason :-) Both Jim and Joel make portions of their work transparent to the rest of us, so we can learn from them. We need to learn from our own projects too. If there’s a piece of your project that seems to be causing problems for another part, think about how you could make the output of the “troublesome” part more transparent to everyone. You may well discover the troublesome part is reacting to someone else’s work that’s not transparent.

If you’re a project manager or involved with project management in some way, think about what is not transparent to the rest of the people involved with the project. Could you create some transparency to make things clearer? It’s worth a little thought.

Tweet This Post