Managing Product Development

Read this about “Business Improvement” and weep. Mindboggling, just mindboggling.

Good thing you won’t have to wait too long for Tuning Up Teams. I’ve been reviewing the book for Esther and Diana, and with this book you won’t have to waste time answer some multiple-choice questionnaire and still not have information. They explain how to do short retrospectives (specifically for after each iteration), as well as longer retrospectives (post-release and post-project). I won’t say more yet, because they’re still finishing the editing.

I had the opportunity to read Practices of an Agile Developer: Working in the Real World. The book has 45 tip to help developers become agile. And, it’s clear that Venkat and Andy know the problems of becoming an agile developer, because along with each tip, there’s a devil-thought to show people what happens in the real world. There are also angel-thoughts to show people why this tip works.

My favorite tip, and something I’ve been saying in my assessment reports for the last 10 years is “Architects Must Write Code.” (p. 155 in this book.) Venkat and Andy say this about ineffective architects:

They typically come in during the beginning of a project, draw all kinds of diagrams, and leave before any serious implementation takes place. There are many “Powerpoint architects” out there, and they aren’t effective because of lack of feedback.

I’ve been a part of projects for 30 years. I’ve been assessing projects for 10 years. And every time I’ve seen an architect who doesn’t participate in the code-writing part of the project, I’ve seen an architecture that doesn’t do what it’s supposed to do, never mind extend to inevitable changes in requirements that occur during the project.

Architects need feedback about their architecture. The only way to get feedback is to write the code, integrate it, and see what happens.

Some of my suggestions for people in my classes are simply to buy some good books for some specific information. When I suggest this, I sometimes hear “my manager won’t let me buy books.” As a bibliophile, I can’t understand that :-). Even though I do accept that not everyone is like me, you can convince most managers to buy books.

First, realize that you’re selling the idea of buying books to your manager. If you haven’t taken a selling class or read a sales book, do that first on your own time. I took a Miller-Heiman class a long time ago that talks about different kinds of buyers (economic, coach, technical, user buyers) and ways to work with each of them. For this blog entry, let’s assume your manager has the money to buy the book (is the economic buyer) and can make the final decision.

Next, discover any objections your manager has. “Oh, is there a problem with this book?” If the manager has no problems, you can go on to articulating value. If your manager doesn’t believe in books in general, overcome the objection by showing there is more than just the book: “Oh, the author also writes articles and a blog. Here are some I found useful. And, so-and-so sent email to the author and received a response that helped him figure out his problem.”

Here are common objections to book buying and ways to overcome them:

1. “The book costs too much.” Your manager is talking about value here for the price. You can counter this by saying one of these things:
   • “Well, $30 is worth about half an hour of my time. I’m sure I can recover half an hour by reading this book and applying what it says.”
   • “What wouldn’t be too much? Maybe I can find an alternative book that would cost less.” If you’re considering a $100 book, this is certainly an option.
   • “Hmm, let me explain the value of the book to me.” Explain it. “Do you still think it’s too pricey?”
2. “You’ll take time away from working to read the book.” You can counter this by saying, “First, I’ll read it on my time. Once I’ve read the whole thing, I’ll bring it into work where I can apply it.”
3. “Everyone will want books.” Counter with, “Well, if our budget is tight for books, we could make a library. Then whenever someone buys a book, they can read it and put it in the library when they’re done, so others can read it.” Or, “Make book budgets part of our next raises, so you can have the discussion with each person separately.”

Whatever you do, make sure you have a win-win situation with your manager at the end of the discussion. You’re offering to become more valuable and a better worker for the investment of one book. Make sure your manager sees that. Use your sales skills to help your manager understand the WIIFM (What’s In It For Me), and you’ll know how to overcome objections and convince your managers to buy books.

Some books aren’t worth the paper they’re printed on. But some are invaluable. Determine which ones they are, and buy them.

About 15 months ago, Denise Robitaille and I met for lunch. Denise was explaining how she helped her clients implement a reasonable corrective action program. I explained how I’d helped some of my clients figure out what was really wrong when they had problems. We were struck by the similarities of our approaches. So, we wrote a handbook together.

Here’s an example of how I’ve used this approach. A client was convinced that the testers took too long to complete testing, with the result that the testing was slowing down the release cycle. We first defined the problem statement to avoid blaming the testers, and then collected some data about who was finding defects and when. We discovered that for one product, the defect arrival rate was a hockey stick. (You can click on the image to see it larger.)

When we investigated why the defects arrived late, we found that the project manager wasn’t managing the project, that the developers never knew which requirements were top priority, that the developers performed no peer review or other early defect-catching techniques. In fact, the testers were doing as good a job as they could.

For another product, we found a more even distribution of defects. (Click on the image to see it larger.) The test time was still long, and the testers were still finding more defects than the developers had, but they had many fewer defects escape the release. This project manager had no release criteria, so the entire project was held hostage by the senior manager who kept requesting more data about the product state before he would allow release.

They had other projects with different problems. For one product. The testers hadn’t learned about combinatorial test techniques, so they did take longer than necessary in the test part of the project. If they had stuck with their original problem statement, that the testers took too long for testing, they never would have seen each project’s root cause, and would have been unable to take appropriate corrective action.

Corrective action involves defining the problem, gathering data (quantitative and qualitative) to understand the root causes, developing a plan (and obtaining buy-in for that plan), executing the plan, verifying that the plan worked with appropriate results, and then closing out the plan. This handbook helps you do so.