Managing Product Development

The only good thing about this current spate of worms and viruses is that the spammers seem to sending less spam. Naively, a few months ago, I bemoaned the state of automated spam filters. Now I wish my mail program (Eudora) and spam filter (SpamSieve) could detect these ridiculous pif files and delete all mail with a pif attachment.

I’ve come to the conclusion that we buy our tools for emotional reasons, not logical reasons. Why else would so many companies and individuals buy an operating system with easily-exploited security holes? It can’t be for logic. Logic dictates that the second or third (or fourth or fifth or…) time the OS was exploited people would move to a new OS. But they haven’t. (Yes, there are options.)

I’m not out to convert everyone to buying my kind of computer (Mac) or OS. We live in a heterogeneous-OS world, and that’s to everyone’s benefit. If I could, I’d make everyone buy anti-virus software when they buy a computer. If I could, I’d make anti-virus software a part of Windows, so it wasn’t an option. It affects me (and huge number of other people) when other people don’t take care of their environments.

When we choose to own computers and connect those computers to the network, we need to take responsibility for our environments. In my town, we’re not allowed to burn leaves in the fall, because of pollution. When we connect computers to the Internet and don’t install the latest security patches and anti-virus software, we’re polluting the Internet. I don’t know what the right consequences are, but allowing people to be naive is no longer acceptable. Allowing companies to ship security-holed software is not acceptable. Allowing the worm-generators or virus-generators to get off with a slap on the wrist is no longer acceptable.

I don’t care what tools you choose to use. Multiple environments create richer environments for each of us. I care when your choices make my tools difficult to use or prevent me from performing my work. Choosing tools is a personal choice. And my obligation when I choose my tools is to act in an environmental-friendly manner. You too.

Tweet This Post

Earlier this week, I was at the Rational User Conference. I was part of a dynamic panel, “The People Factor: Experts Weigh In On The Soft Side of Software.” One question was about how technical managers or project managers have to be. Murray Cantor, one of the other panelists, summed it up this way: “They have to understand the dynamics of software development.” Ellen Gottesdiener reminded us about the value of interim retrospectives. Kurt Bittner, author of Use Case Modeling was our moderator.

I was my normal feisty self :-) I wrote up my position statement, and after editing it several times (and changing it the night before the panel), I’ve decided it’s worth posting, at least for comments. If you were at the conference, you’ll recognize that I ad-libbed during my opening remarks. Please do comment by email or with the comments here.

The People Factor in Software

The two most important factors for successful software projects are the ability of the managers to manage and the people to understand the domain of the software in which they are working. [1] Capers Jones claims that reuse of high quality components is significantly higher than those two factors, but to be honest, I haven’t seen enough reuse to apply that factor to most projects.

What that means is that people matter. And managers matter.

So what do I mean by people matter?

I’m not a people person by nature. I originally decided on a career in software because I thought I’d be able to interact with machines all day and rarely talk to other people. After all, that’s how I went through school, and didn’t school prepare me for life?

Well, unsurprisingly to us now, I soon realized I spent close to half my time talking with other people: discussing the designs, how we would integrate, who would get computer time, which module would do what thing, and who would manage the work in software that the hardware guys couldn’t do. As I became more aware that people are the vehicle by which software is developed, I realized I had to “care” about people.

I don’t mean caring about people in a touchy-feely way, although I do recognize that people have feelings. I care about people and they way they interact because that’s how we make successful products and projects:

• It’s logical to care about people because if the product is a success but the people all quit at the end of the project, the project was not successful.
• It’s logical to care about people because if they’re worried about the rest of their lives, they can’t give 100% to the project.
• It’s logical to care about people because if they work so much overtime that they’re punchy, they will create defects (if they’re developers) or miss defects (if they’re testers) or set the organization on the wrong strategy (management)

People are how we make projects successful.

But what about managers? Earlier, I said that managers matter too. Here’s why. Good people can triumph over inadequate process or inadequate management. But even the best people with the best process can’t triumph over bad management. Bad management trumps everything else. I’ve worked for bad managers, and I bet you have too, so you’ve seen the damage bad managers can cause.

Great managers recognize that any software worth doing has to provide significant value over previous (or other) projects. Managers, as well as the technical staff know they have to learn about the software as it evolves so they can manage the unknown risks. As I was driving in yesterday on US 4, I saw lots of construction. I realized that the people rebuilding the road were working on the next release of the highway, something we do in software as a matter of course. But there’s huge difference between managing people who construct the next rev of the highway and managing the next software release. With the first release of the road, you’ve already uncovered most of the construction gotcha’s. You know where the water table is, you know where the animal habitats are, you know the ground composition as you move along the highway. In software–any software worth doing–you don’t know what you’re going to find. Just because you discovered something in the first release, doesn’t mean you know enough about how the software has to evolve to understand what’s going to happen in the next release, with the new requirements and the changed implementation. You have tons of unknown risks. I claim that the best managers help their staff recognize and manage those unknown risks. The worst managers don’t. And because unknown risks can occur anywhere, the best managers use qualitative and quantitative data to understand the state of their projects.

Successful organizations work on the highest value projects; hire people who can succeed in their environment; and teach those people, including the managers about the product. Managers who understand that their job is not just to deliver results for this particular project, but also to continually build capacity and work through and with others are successful. Technical people who are continuously curious about the product and how to make it better drive projects to successful completion.

We need people who are knowledgeable in two significant dimensions: they understand what their job entails (whether they are developers, testers, release engineers, and so on), and they know how to apply that knowledge to the product. We need knowledgeable managers, people who understand how to manage projects and people, and who know enough about the product to make good decisions.

I claim that the practice of software management in 2003 remains significantly behind any of the technical factors in producing great software. When we decide management is valuable and we demand managers perform good management, we will build capacity in each person and our products will improve.

The soft side of software, the people, are the trump card in software projects. Want a successful project? Make sure your people can work together, including their managers, and that they understand the problem and solution domains of the software. Make sure your people have the functional skills to succeed. Then you can select any reasonable process, and the people will succeed.
1. Jones, Capers. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley, Upper Saddle River, NJ. 2000. (page 133).

Tweet This Post

Release trains, the technique of planning releases on a particular date several times a year (such as quarterly releases, on the 12th of the last month of the quarter), can help you manage your development and test staff as well as machines and tool resources. I wrote about release trains a while ago here. If you’re suffering from these problems, consider a release train:

• Your users want more releases of the software and you can’t figure out how to release faster to release more often.
• Your users want fewer releases of the software and you don’t want to maintain too many releases.
• Developers are stomping on each other’s code, in service to separate projects. Or, if the developers manage through the configuration management system not to stomp, the merging is difficult.
• You have many small projects, all of which require significant development and testing resources.
• The testers feel as if they can’t make progress on their testing, that they keep testing the same products over and over because the products keep changing due to the small projects.

Here’s what you need to make release trains work:

• A program manager who reports into the people who determine the corporate-wide initiatives, the reasons for doing all these projects. The program manager manages the release criteria, the project managers, and whatever corporate-level issues need managing to make each release successful. The program manager determines if something is going to miss a particular train and if it should be postponed to the next train. The program manager helps each project maintain its cohesion and reduces coupling between projects.
• Project managers for each project for each of the trains. Each project is a significant effort, so requires at minimum a technical lead, and more likely a project manager to make sure the developers and testers (and the other necessary staff) estimate and deliver their work on time. The project manager has to ensure the developers do no more than necessary. YAGNI, You Aren’t Going To Need It, isn’t just for agile projects, it’s for all projects. The project managers have to be close enough to the project to understand the inevitable tradeoffs and discussions of what’s in and what’s out.
• Great configuration management, both the tool and the release engineers, so you can have up to four simultaneous codelines and the developers can still build to get exactly the sources they need. The release engineers will have to merge the codelines into the mainline too, in case you need to make a patch separate from the next release. (But don’t do it, unless the lack of a patch means corporate death.)
• Enough estimation ability by developers, testers, project managers, and any other project staff to be able to estimate the necessary work, so you can meet your projected release.
• Ability to develop enough automated tests for regression testing. A release train is a combination of an iterative lifecycle, with increments for each release. You’re guaranteed to change the same modules again and again. If you don’t have enough automated tests (and I don’t have a number I can give you), you won’t be able to release when you want to.

You’ll need all of these things to create a successful release train. Cisco and Sun are both releasing product with release trains.

Release trains help you manage all your resources, because you can group similarly-sized or similar-impact projects together into one program. Because there’s one program manager whose job is to satisfy the execs or other corporate stakeholders, one project doesn’t “win” over another project. The sub-optimization that can occur at the project level can’t occur in the program, or the program doesn’t allow the train to release on time.

Software release trains aren’t the only answer. Using agile techniques also help manage resources. If you use agile techniques, your projects are more likely to complete on time. But if you don’t see how to make agile techniques work in your environment, try release trains. They are more like traditional projects, which may mean other people will accept them more readily.

Tweet This Post

Hal’s post about the meaning of project management got me thinking about accountability and how we use it in organizations. In the last three weeks, I’ve heard these definitions:

• “I want to know who’s accountable. Who do I get to fire if they screw up?”
• “The testers/project manager/management team is accountable for the bugs. They let the developers put them in the product.” (Yes, in one organization, the testers, PM, and managers were all held accountable for the developers’ practices. Amazing.)

I looked at dictionary.com, and found this meaning:

“Liable to being called to account; answerable. See Synonyms at responsible.

That can be explained: an accountable phenomenon. “

So when I think about accountability, I think of the person with the answers and explanations, and the person who can make things happen. When I look at the above blaming statements, I wonder why the person blaming the other people is so quick to escape responsibility or explanations. Inevitably, the person pointing the finger of blame is the person who has the answers and ultimate responsibility.

Here’s what I think accountability is for managers and project managers:

• The ability to see the current state, in all its ambiguity.
• The ability to look for explanations of that state without blaming other people
• The ability to work with people to change the current state to the desired state, learning about the project and the product as the work evolves

Accountability has nothing to do with blaming other people; it has everything to do with seeing the work and understanding how to move the work to the next state.

Tweet This Post

In his comment to my previous post, Babu said, “unqualified project managers quickly sink a project which would’ve otherwise fared better.” (Keith, I’ll respond to your next comment in another post.) I’ve had the pleasure of meeting great project managers, and some not-so-great project managers. Here’s my list of necessary skills for great project managers:

Non-technical qualities, preferences, skills

• Listening skills. See Hal’s last e-tip.
• Negotiation skills. PMs need to ask for resources, trade resources and information…
• Writing skills. PMs need to be able to write down a plan, so that everyone understands the plan and the tradeoffs
• Oriented towards a goal. PMs need to be able to finish a project and keep people focused on the goal
• Interested in the people who work on the project. The PM doesn’t have to be everyone’s friend, but the PM has to be able to see when people are struggling, when something isn’t working, as well as when things are working
• Able to manage ambiguity — to live with the ambiguity and make decisions. So far, every project I’ve managed, not just the software projects, has had periods of ambiguity.
• Able to manage the details. Even if the PM isn’t a detail person, the PM has to find a way to manage the details.
• Ability to steer the project — to observe the current state, note what’s different from where you want the project to be, and the ability to guide the project to the new state

Technical Skills: Functional skills

• Understand different lifecycles, and which one(s) is most appropriate to this project
• Project scheduling
• Task estimation
• Risk management
• How to deal with configuration management. Hmm, that may be too software-specific. Maybe in more general terms this means dealing with assets, earned value.
• Extracting data from the various tools to see where the project is

Other Technical Skills

• PMs don’t need to know the details of both the problem to be solved by the project, or how the problem is solved, but without one or the other — some form of domain knowledge — the PM doesn’t know enough to make good project decisions.
• Either knowledge of a project scheduling tool or an assistant who knows how to use the specific project scheduling tool.

As you can tell, I believe the non-technical, not-easily-assessible skills are most important. And, they’re the ones no certification test can adequately examine.

If you have other suggestions for this list, or modifications, please comment or send me email and let me know.

Tweet This Post

In addition to Frank Patrick’s excellent post of the Top 10 Sources of Project Failure, I have one more: No project manager.

In the past week, I’ve received inquiries from people, asking how they can successfully complete projects or programs without project or program managers. I tell them I don’t know how to do that. I explain that if there’s no one looking out for the whole project, or the series of projects in the case of a program manager, the effort will most likely fail. Then I hear questions such as, “If I have to choose between testing and project management, which one do I choose?” I’m often tempted to reply with “47″ or “widget” — I want to respond to meaningless questions with meaningless answers.

Instead, I ask, “What value does this project have for you? Have you ranked this project among the other projects?” Once we start talking about relative value, the other person has a chance of understanding whether it’s worth fully investing in the project or not.

If you have projects you’re not willing to fully invest in, stop doing them. Cancel the project. But if you are willing to invest in the project, make sure you’ve got a project manager or program manager able to manage the project to completion. One person (not a committee) takes the responsibility for organizing, steering, and managing the project. If you’re not willing to hire a project manager, don’t do the project. Spend your money on something else.

Tweet This Post

I’ve been musing over types of people on projects lately. This morning, my husband and I exhibited two common types: the serially, walk-through-the-whole-thing-systematically type (hubby), and the big picture, can’t-wait-to-see-it-put-together type (me). See this post for more information. Mark’s a Guardian (SJ in MBTI terms), I’m a Rational (NT in MBTI terms). Here’s what happened.

It’s been humid in Boston for days (weeks?), and we had another fan (still in the box) for the workout area, waiting to be put together. Mark normally puts things together, because he has the patience to read and follow all the directions. I normally leave out an early step in my excitement to finish. Since we know that, we can work well together. Mark usually asks me to read step 2 or 3 again. (It doesn’t matter how many steps. I always have to read steps 2 or 3 again.) But today, I decided I wasn’t going to wait for him to put the fan together. I needed a fan now.

I have the fan almost all put together. There’s an extra part. I know, on my internal checklist, that extra parts are No Good. I won’t throw it away; I know there’s a place for that part. Mark has been working out, watching me assemble the fan. He’s done and walks over to me. He says, “Did you read step 2?” I proudly reply, “Of course. I read all the steps.” He smiles and says, “Did you do step 2?” I reply, “Sure.” “How about step 3? Did you do that one too?” I checked. Uh oh. I missed step 2, and had moved onto step 3, thinking it was step 2.

I’m not stupid, and I am mechanically inclined. But I do have a hard time wading through directions. Mark likes following directions. We bring different strengths when we work together.

Our different strengths mean we aren’t fungible (interchangeable). It means that if we were to both work on a project, I would have the ideas for which tests would be manual step-by-step, and Mark might be able to develop and execute them. Mark would know where we’d need exploratory testing, I would perform it. I might talk about a feature, Mark would be able to specify it in excruciating detail. I would see the design in my head, Mark would help me write it down so that other people could see it too. In fact, when we worked on our house renovation, those were precisely the roles we took.

Pairing dissimilar types can be useful on a project. Even if people don’t specifically work in pairs, having multiple types of people helps the project complete different types of work. If you have all similar people, remember to hire different types (if you can), the next time you have an open req. Even without open reqs, you can encourage people to take other roles, as a way to help other people test their work. Sometimes, I pull on my detail hat and say, “What would Mark do now?” I’m not always completely successful, but I have better results by thinking of what other people would do, instead of just thinking about the work in my normal way.

People with different capabilities and perspectives add considerable value to a project. If you’re on a project that’s stuck, look to see if you have enough different capabilities and perspectives. If not, consider changing the people, or asking some people to act as if they have a different perspective. At the least, you’ll uncover something about the sticking points in the project.

Tweet This Post

Every so often, I hear managers say things they vowed they’d never say when they were technical contributors. (Yeah, parents do that too, but that’s not the topic today :-) Here are a few of my favorites with their translations:

• “We have expertise in that area.” Translation: We have no idea what you’re talking about, never mind any experience in this. In fact we have no idea what your product is, what it needs, who the users are, or anything else. We are clueless.
• “You shouldn’t want that.” Translation: This is the most important feature for the product, the project, the process, the event, whatever. But since I don’t know this is most important, I will tell you not to want it.
• “Don’t care so much.” Translation: I don’t care, so why are you all up in arms about this event? What do you know that I don’t know?

I’m really not cynical — but it’s hard to tell from my translations. Managers, whether they are project managers or functional managers, fall into management speak because they can’t admit they don’t know. Admitting you don’t know, especially as a manager, is impossible for some managers, just difficult for others. As long as we remember the company pays managers to make good decisions, not be omnipotent, we’ll be able to admit we don’t know.

Tweet This Post

It’s worth taking a quick listen to Commentary – Overtime’s not good for your health. The folks from University of Arkansas actually have data that says overtime is ok and doesn’t reduce productivity. Hah! I wonder where their data came from. On the other hand, Joe Robinson’s commentary makes perfect sense to me. Here are some of his comments:

“Excess overtime reduces productivity during regular and excess hours” (paraphrase by JR)

“People working 7 50-hour weeks produce less than people working 7 40-hour weeks”

“Long hours are a tragic failure of the knowledge economy”

So forget the idea that you’re making progress by working overtime. It’s not going to happen. I wrote a bit about preventing overtime in my last Pragmatic Manager newsletter. Some ideas: ask how little you can do, look at your fix rate to verify you’re making progress, look at multi-tasking, create release criteria, and review if everyone’s late, or just some staff. Help those staff where necessary.

Whatever you do, understand that you can push as much as you’d like, but you still can’t think any faster. (Thanks to Tim Lister, from whom I first heard that gem.)

Tweet This Post