Managing Product Development

I’m at the Software Development conference this week. One of the hot topics I discussed in my presentations and with attendees during and after the talks were about context switching and multitasking, Focused Performance and Breakthrough Thinking on Worker Productivity and Multi-tasking Makes you Stupid, studies say.We agreed that:

• several pieces of work at different levels causes problems (defects in code, inappropriate project plans, etc.)
• too much work, when you try to work on it simultaneously, causes you to make no discernable progress on anything

But, you’re a development/test/project manager. You have too much work to do, and not enough time to do it. What do you do?

1. Make sure you know your boss’s priorities. What does he need now? Too often the boss says everything, in which case, go to #2.
2. What is strategically important for the company now? Note that this is not strategically important for your group, but strategically important for the company. Talk to your boss, yes, but then focus on what helps the company most.
3. Kill the projects you need to kill. Too often we have too many projects hanging around, or products we support because we always have. Stop that now, and only support what is strategically important.
4. Work on things that bring in revenue (or contribute to revenue) now.

Another piece of multi-tasking is to “create” more time in your day by:

• not attending meetings you don’t need to attend
• allowing interruptions from voicemail, email, pager, cellphone, and blackberries at specific times, not when the interruptions come in
• allowing people at the lowest level of the organization make decisions about their work, so you can make decisions about your work.

I’m still thinking about this, so I’ll try to post more helpful hints later this week. (Especially once I get my connectivity worked out.)

I was on the phone this morning with a senior manager. He was describing their current project: “Well, we’ve got 25 people: 12 developers, 6 testers, 2 writers, 4 support people, and 1 project manager.” I asked about the managers of the developers and testers. “Oh, the dev manager is running the project. We don’t have a test manager yet, we’re interviewing.” There are no technical leads, no sub-project leads, no other management other than the project manager.

This project is headed for disaster, not because they need more levels of management, but because the project manager is attempting to manage the project and manage 25 people. That’s not possible. The project manager could manage the project of 25 people, but he can’t help 25 people do their work, plan for their upcoming work, and deal with the little problems that arise.

If your project or organization is in this position of having just one manager trying to manage the project and the people, ask yourself these questions:

1. Are there more than 6 people altogether? One manager can manage 6 people relatively easily. A talented manager can probably manage the 6 people and the one project those people are working on.
2. Does the effort have more than one functional area, and are those functional skills diverse? The more functional areas involved in the project, and the more diverse those skills, the less likely one project manager can effectively manage both the project and the people. A project manager who knows a lot about development may not know enough to guide the testing. In the example above, the project manager doesn’t know how to organize the testing.
3. Does the project manager need to heavily interact with the customers or sponsors? The more interactions, the more the project manager will feel pulled in multiple directions. If the project manager is also attempting to manage the people, the people management will lose.

If you answered yes to any of these three questions, it’s time to separate the project management from the people management. Help your projects succeed by funding both the project management and the people management. If you have to skimp on management, make it senior management. After all, there won’t be anything to manage from the senior level if the projects don’t finish.

I seem to have a vision theme happening this week

How many kinds of review do you perform on your project’s work products? Especially with software projects, it makes sense to review interim work products, so you have some idea about how good the final product could be.

Sometimes when I ask project groups about reviews, they physically recoil, and say, “Oh no, JR, there is NO WAY we are taking the time to review things. Reviews take a long time and we just don’t have that kind of time to spend on reviews.”

Well, if you’re on a strict-schedule project, you don’t have time to NOT perform reviews. You don’t have to use Fagan-style inspections, the most formal type of review. You could use walkthroughs, pair development, or peer desk-checking. Each of these techniques are low-time investment and higher return than no review at all.

I like walkthroughs, where the author presents the work product to an audience, best for project plans and schedules. When I walk the technical staff through a project schedule, they have the opportunity to point out dependencies I didn’t know about. When I walk the senior management through a project plan, they can tell me whether they agree with the project vision and release criteria.

Pair development is great for requirements, designs, code, and tests. Pair development works best with one keyboard, one mouse, one screen, and two people. If you’re not sure how to make pair development work for you, see Laurie Williams and Robert Kessler’s book, “Pair Programming Illuminated”, ISBN 0201745763. When you’re done with the work product, two people know it intimately and have discussed the alternatives.

I find it difficult to use strict pair programming for writing English, because I don’t always know what I’m going to say when I sit down to write. For me, the act of writing a natural language generates more ideas. Writing a computer language is different. So, for English language work, I use desk-checking techniques.

Desk-checking, where someone else reads your work product and tries it out or comments on it, is another great technique for finding inconsistencies in writing (whether it’s code or a natural language). Desk-checking, because it is so informal, depends on the expertise of the person doing the checking. Someone who’s familiar with the work product and has the time will do a good job desk-checking. Someone with less expertise, or is having a bad day, or is tired will not perform as good a review.

In any case, no matter which review techniques you choose, consider which techniques are useful when for your project. The more eyes on intermediate work products, the better the final product will be. (And if you have any ideas about how to review blogs *before* they’re published, let me know

I was working on a newsletter article about how to see your project’s progress, and got stuck. It’s easier to see project progress on a project with a tangible deliverable; it’s much harder for software or a service project. So, I took a break and read Esther Derby’s blog entry, Start Seeing Software from 3/13/03. Esther suggests milestone reviews, retrospectives, and metrics. In addition,

Sometimes, it’s not clear that you should fund or staff a project. If you’re not sure how to discriminate between alternative projects, here are four questions to ask:

1. What’s the strategic reason behind this project? (Does the strategic reason behind the project change the importance of the project?)
2. How does this project fit into all the projects we’d like to do? (What tradeoffs do we have to consider?)
3. What environment/staff/resources do we need to make this a successful project? (If we’ve never done a project like this, or if we have doubts, or if we’re missing necessary resources, are we dooming this project to failure?)
4. Can we adequately fund this project as we’ve envisioned it?

If you can’t define the strategy behind the project, or how this project fits, or the prequisites for success, or the necessary funding, you can’t have a successful project. So don’t start it. Ask your four questions, and listen to the answers.

I’m facilitating a roundtable, Test Management 101, on Stickyminds, and someone just posted a question about how to measure testers to show return on investment: measuring the number of defects they find. Ouch. When you measure developers on the number of lines of code, or testers on the number of defects, or carpenters on the number of cabinet doors they create, that’s a single-dimension measurement. Single-dimension measurements skew everyone’s thinking about who’s good, who’s not, and what to do about it. Single-dimension measurements lead to Dilbert-esqe situations, such as the one where the PHB (Pointy Haired Boss) announces extra pay for each defect fixed. Wally decides to write himself a minivan (create defect-laden code which isn’t measured, and then fix it, which is measured).

Technical staff assesssment is impossible to measure with a single-dimension measurement. You need at least some combination of how the person works, how much they create, and how good that creation is. Fuzzy to start? Yes. Customized to each situation? You bet. Hard work? Yup. And, that’s the job of management - to look beyond easy non-answers to define the real measurements.

(I’m working on an assessment mechanism that will require each manager to define the kinds of people, the knowledge required, and how the employee applies that knowledge to the product as part of the assessment. It’s hard. And when I’m done, it will be much better than single-dimension measurements or those useless review sheets companies use now. If you want to help me test the tool, email me. )

Fred Brooks, in his classic, “The Mythical Man-Month,” talks about a chief programmer team (chief programmer, and programmers of lesser hierarchy until you get to the peon). The chief programmer team works when one person can keep all the details about the product in their head. If you use several hierarchical teams of chief programmers, each one keeps their part in their head and the chief-chief programmer keeps the whole thing.

Except that on large projects, that’s asking for people to forget important things and make mistakes. We then call these mistakes defects (or bugs or problems).

But what if we didn’t have to keep the whole product in just one head? What if more than one person could see the whole product, and learn pieces of the product intimately? That’s what agile development is all about.

If you want the best of everyone, not just the chief programmer, consider some of the agile practices:

Sometimes on a project, we focus on an intermediate milestone in the project, such as Beta, or first performance test, or early ship. The project team works like dogs to make that intermediate milestone. Then, there’s still the rest of the project. Uh oh. Now you’re starting to cross the desert. (Thanks to Jack Nevison of Oak Associates for that great metaphor.)

In our house remodel last year, we focused on the upstairs bathroom completion. The bathroom was completed in February. We had about 8 weeks of work remaining. The project completed in September. (!!) The project completion was so late because everyone had juggled previous commitments to meet the intermediate milestone and worked too many hours on our project, ignoring the rest of the contractor’s work. It took forever to complete our work.

This happens on software projects too, sometimes with even more dramatic results. On one project, the team worked 10-12 hours a day, 6 or 7 days a week for three months, to make a Beta release. We did. Everyone took the next week off, leaving the tech support people fielding calls. We came back to work, somewhat refreshed. However, we had significant work to complete before we could release. We were still exhausted and burnt out. And, now that the customers had the product, we had even more pressure to complete the project.

Crossing the desert hurts. It hurts the people and frequently hurts the project. If you have to focus on an intermediate milestone, pace your project team. Don’t let the project team start with overtime before the very end (last week or two) of the complete project. Early overtime == later project completion.

You won’t find an oasis. So don’t cross the desert.

If you’re a project manager, a functional manager, a technical lead, or someone who wants to improve their work, start a journal or a log.

When I was an engineer, I kept an engineering notebook. I discovered a bunch of ways I created the same defects. (Yes, developers create defects as they create products, and we pay them to do so.) For example, when I wrote FORTRAN code, I was great at creating infinite loops. As I wrote the code, I didn’t pay enough attention to the start and end conditions. By tracking how I didn’t pay enough attention, I was able to reduce the number of infinite loops I created.

I used that learning when I started running projects. On my first project, I got stuck, not achieving part of the end state. Since I was still keeping an engineering notebook, I wrote this sentence, “Gee, this seems just like those inifinite loops I wrote. Will this project never end??”

That sentence was a clue: Look at my initiation and end states. Had I set up an infinite-loop project? What did I have to do to stop the loop?

I use journals (engineering notebooks, management notebooks, notes at meetings, whatever you want to call them) to track my individual patterns and learn when they help me and when they hinder me. Then I have a choice about continuing the behavior pattern.

So, if you’re not yet keeping a journal or log, consider it. Write down your decisions and why you chose to make them. Write down your problems or defects. See if you can discover the root cause of the problem. After a few months, you’ll know more about how you think and act at work — which, for me, is a Good Thing.