Managing Product Development

My book about hiring, Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People is available, as of today. (I don’t have my copy yet, and my reviewers don’t have their copies yet either. I’m hoping to be able to ship to my reviewers on Friday.)

I firmly believe that people are the foundation to any project’s or technical organization’s success. And it’s not easy to determine what kinds of people you need. In the book, I walk the hiring manager or team through ways to think about the kinds of people you need, how to find them, interview them, make an offer, and what to do if you can’t find the people you need.

I’m speaking at the Software Development conference this week, and the book will be at the speaker bookstore. In addition to my experiential session, Interviewing with Ease, I’m presenting two standard talks: pragmatic metrics and management lessons learned. If you’re in Boston this week, come over and say hi. I’ll be thrilled to sign the book — I even bought a new purple pen

Tweet This Post 

Eric Sink is writing a series on source control how-tos (also known as software configuration management). If you’re a project manager or functional manager and you don’t know enough about source control, read them. Heck, even if you do know about SCM, read them. Yes, Eric works for a vendor, so his examples are vendor-specific. It doesn’t matter. I don’t know his tool and still understood the examples. BTW, when I teach project management, I introduce SCM as the technical piece of the project that can save your project from complete disaster.

Here’s what I think you need to know as a PM: branching, labeling, and the ability to use a multi-level checkin scheme, so you don’t break the builds but can make progress concurrently in different parts of the project. The more you know, the better, but knowing how to do these has helped me take reasonable risks to move projects forward.

Tweet This Post 

I was reading An Elder Challenges Outsourcing’s Orthodoxy, yet another discussion about the merits — or not — of outsourcing. (You may have to register to read the article.) Whether you think outsourcing is an economic good or evil, here’s my perspective.

You can choose to turn your products into commodities or you can innovate. If you choose commodity, then select the cheapest labor market — because it doesn’t matter. You’ll get something good enough in an adequate time, assuming you made some reasonable choices about outsourcer and spent the time and money to get them up to speed.

But if you choose innovation, you can’t outsource. You can’t define all the requirements and hand them off to anyone in a highly innovative product — requirements definition and product development have to be a joint exploration — and you can’t do that when the definers and the developers (and testers) don’t sit near each other. You can’t wait for a product to be done — you need to see the product unfold and adjust the product (or the project) to accommodate the things you forgot.

The third option I’ve seen is to outsource ongoing development with a piece of the product and continue developing in the original country. In all the cases I’ve seen, outsourcing slows down the entire project. In my opinion, this happens in the same way all non-co-located development breaks down. People aren’t together, so they’re not tied into what other people on the project are doing. The lack of face-time prevents people from working as fast as possible.

You can get cheap development — and you can’t also get adaptability or speed.

You can get innovation and speed. It’s not cheap. But with careful project initiation and management, you can contain your costs. Just don’t make the error of thinking that you can create innovative products cheaply by relying on outsourced labor.

Tweet This Post 

I’ve turned comments back on. The spammers were still getting through even though no one else was. If anyone has converted comments from one system to another commenting system, please send me email. I’m considering it.

Tweet This Post 

I have — I hope temporarily — turned off commenting. I’m getting spammed by irrelevant and inappropriate comments. I’ve deleted close to 100 today already, and I’m not ready to delete more. Send me email if you want to talk or know of an alternative.

Tweet This Post 

When I do assessments, invariably someone says to me, “JR, how long should the testing really take? It takes our testers (4/5/6/30 insert your number of choice here) weeks, and we need it to take less time. Why can’t it take less time and how can we tell what’s going on so we know how much testing we need?”

This is, of course, an “it depends” answer. I’ll try to untangle this.

If you do test-driven development, then there is rarely a lot of extra testing. When I coach teams who are transitioning to test-driven development, I recommend they plan for as much as one iteration at the end for final system test and customer acceptance test. Once the team has more experience with test-driven development, they can plan better. I have found a need for some amount of customer acceptance testing at the end. And that time varies by project and how involved the customers were all along.

If you’re using an agile lifecycle even without test-driven development, I recommend starting with one iteration’s length of final system testing. I am assuming that the developers are fixing problems and refactoring as necessary during an iteration — real agile development, not code-and-fix masquerading as agile.

If you’re using any of:

• an incremental lifecycle such as staged delivery where you plan for interim releases (even if the releases aren’t to the customers)
• an iterative lifecycle such as spiral or evolutionary delivery
• a serial lifecycle such as phase gate or waterfall

I’d expect as much testing time as development time — but it doesn’t have to come all at the end as final system test as it looks like in the pictures. Any proactive work you do, such as reviews, inspections, working in pairs, unit testing, integration testing, building every night with a smoke test, fixing problems as early as they are detected, can all decrease the duration of final system test. If you’re the project manager, ask the developers what steps they are taking to reduce the number of defects they create. If you’re the functional manager, work with the project manager and the developers to create a set of proactive defect-prevention practices that make sense for your project.

If you’re the test manager, recognize that final system test includes several steps: testing the product, finding defects, and verifying defects. Your first step is to separate these tasks when you estimate the duration of final system test.

One question you should be able to answer is: How long will one cycle of “complete” testing take? We all know we can’t do complete testing, so your version of complete is the tests you planned to run and any other exploratory tests or other tests you need to run in one cycle of testing to provide enough information about the product under test. I realize that’s vague and depends on each project. I don’t know how to be more explicit, because this is a project-by-project estimate. If you work with good developers, the cycle time can decrease a bit from the first cycle to the last — because the testers know better how to set up the tests and the product has fewer defects, allowing the testing to proceed faster.

Once you know how long a cycle of testing takes, estimate how long it will take the developers to fix the problems. I use this data: the number of problems found per cycle in the last project, my gut feel for how many more/less we should find per cycle in this project, bug-tracking system data telling me the average cost to fix a defect pre-release. If I knew that the first cycle in the last release found 200 problems, and it took the developers half a person-day each to fix problems and I have 10 developers, I estimate 10 working days to fix problems. That’s a long time. And yes, I was on a project where that’s what it took. It was agonizing — we thought we’d never be done fixing problems.

Now you know how long a cycle takes, how long it will take for fixes after the first cycle. How many cycles of testing do you plan for? When I set up projects, I tend to use some proactive defect detection and prevention techniques, so I generally plan on three cycles of testing. In a casual conversation with Cem Kaner a number of years ago, he said he planned on eight cycles of testing. For one project where I was a contract test manager, we had almost 30 cycles of testing. I can’t tell you how many cycles of testing you’ll need because that depends on the product’s complexity, how good your tests are, and how many defects the product starts with.

Here’s what I have noticed from my work with multiple organizations. The groups who want to decrease testing time tend to perform the least proactive work reducing the overall number of defects, and they typically perform primarily manual black box testing at the end of a project. I understand their desires, but they’ve set up their lifecycle and processes to produce exactly the wrong result.

The best guess for an estimate I have is to estimate the number of cycles you’ll need for testing, the duration of one cycle, the time it takes for developers to fix problems between cycles. Add up the testing plus fixing/cycle and multiply by the number of cycles you think you’ll need, and you’ll have an estimate of the testing time needed. BTW, when I do this, I never give a single number, I always give time per cycle, my estimate of the number of cycles, and my estimate of defect-fixing and verification time. That way I can show the costs of not performing proactive defect prevention in a nice way. And I can show my uncertainty in my estimation.

If you want to reduce testing time, create a low-defect product, test all the way through with a variety of test techniques, and use iterations, so you know at the end of 2-4 weeks where you stand with defects. The lower the number of defects and the more sophisticated your tests, the faster your testing time will be.

Tweet This Post 

My colleague, a senior manager, is inundated with too much to do. Hundreds of emails, seven of hours of meetings every day, hundreds of emails, hiring the next level managers so he doesn’t have to backfill, project portfolio management, and backfill of those management roles not yet filled. My colleague is trying to manage his work, but he’s working too many hours and not finishing enough. Luckily for him, this is a short-term problem, but it’s not for too many managers.

Here’s what I suggested he do:

1. Collect all the work. (Esther and I call this the universe-of-work.) The work includes projects, periodic work, ad hoc work, and ongoing work.
2. Decide what you need to do at your level. The higher you are in the organization, the more strategic work you need to do. (Every position has strategic work, the work that helps you get the rest of your work done.) Even if you can only do one of your strategic things every day, make sure you do one every day. I recommended he continue to focus on filling those management positions that would free up many hours of meetings and the backfill of management work he’s attempting to do.
3. Decide what you don’t have to do. (Esther and I call this the not-to-do list). If you transitioned out of a previous job, don’t fall back into it. You can make a conscious decision to take on some of those responsibilities if you decide it’s strategic for the organization.
4. Ruthlessly cull out the work you don’t need to do. In this case, I asked him if he had to attend every meeting he attended.
5. Admit you’re not reading all your email. Filter it into mailboxes and decide what to read when. David Allen says to make your inbox truly an inbox. I can’t say I can do this all the time, but I’m there about 10% of the time – which is a huge improvement for me over last year. See below for Allen’s techniques for managing actions. I also tell people not to copy me on email unless they want me to be able to make a decision about something. And if they think they know my decision and don’t like it, they shouldn’t send me email
6. When your managers or project managers go on vacation, do not allow them to delegate the work up to you. Make sure they delegate to people in the project or in the functional group.
7. When you’ve done that, try David Allen’s approach to managing actions. First, if you can handle this thing (email, paper, whatever) in two minutes or less, handle it. If not, place it into one of these folders: Action (which could be any of: Call, At computer, Errand, Office action, At home, Agenda, Read/review), Waiting For. (See Chapter 7 of David’s book, Getting Things Done: The Art of Stress-Free Productivity for the whole story.)

This sounds easy but it’s not. If you are really stuck in to-do-list hell, take one of Allen’s seminars. I took one a few years ago and learned a ton. I implement part of what I learned. My husband (the incredibly organized guy who likes this stuff) implements much more. But I get to 0 emails in my inbox more often.

So where does the decision part come in? If you’re managing your actions and all the information flow, you’ll be able to make good decisions quickly. If you think you don’t have enough information to make a reasonable decision, think about where and when you received information leading up to the decision. Too often, the information is buried in all the emails you receive every day.

Whatever you do, remember that you have two responsibilities as a manager: deliver results and increase capacity. The way you do that is by managing your actions and deliverables and by helping your staff increase their value to you. You can only do that if you take control of your information flow and make good decisions. Remember, the more strategic your decisions, the more valuable they are to the organization. Not easy, but necessary.

Tweet This Post