Managing Product Development

Rant on.

There’s a flame-fest on the scrumdevelopment list about the use of “resources” or “people” to describe the human beings on projects.

I like “humans” or “human beings” or “people.” And, I actually prefer “resources” to “man-hours.” I can live with “people-hours,” and prefer that to “resource.”

I bet you’re a little surprised. I’ve written that People are NOT FTEs. And, in A Funny Story About Manage It!, I said that I didn’t refer to people as resources.

So why would I prefer to be a resource than repository of man-hours? Because it doesn’t matter how many hours I work, dammit. I am never going to be a man. (We can all be thankful for that!) I don’t count in man-hours. And, man-hours assumes that we can tell how long a task takes. Ha! Not a new task, which are the most interesting tasks. Fuggetaboutit.

I like calling people “people” and talking about what they as a team can accomplish. People are rarely fungible. (I’ve never seen true fungibility, but I haven’t seen everything.) Resources, to me, mean machines and other hard equipment. Every so often, I think of resource as the on dictionary.com:

a source of supply, support, or aid, esp. one that can be readily drawn upon when needed.

That resource might be a human who is not a part of our team. Maybe that’s a slip and it makes me more human.

I grew up looking for jobs in high school when the classifieds were split into “men wanted” and “women wanted.” The men’s section was always at least five times larger than the women’s section, and had the interesting jobs. I thought I was over it, but I guess not. I’m still rankled by the difference. At least “resource” treats us all the same way.

A project team is composed of people. Those people, working together as a team, have a certain capacity. Let’s keep that in mind, ok? I don’t care if those people are red, white, blue, black, brown, purple, men, women, something else. I care about how well they get along and what they, as a team, can do. Team capacity, that’s the key.

Resource is a backwards way of attempting to define team capacity. So, our HR departments (I much preferred when they were called “Personnel” btw, which they were when I started to work back in the age of the dinosaurs) don’t get it. HR doesn’t get much, except how to keep the company out of court. (See I Don’t Hate HR.) We, the technical leaders, will lead HR in how to hire people, in how to manage people, and in how to compensate people who work in tight-knit teams.

In some ways, I think of HR and their policies as a resource to me, as a manager or leader. But I certainly don’t think of the people with whom I work as resources. Sometimes I call them project staff when they are a group of people. Sometimes I call them a project team, when they work as an interdependent team.

They are people. Just like me.

Rant off.

Tweet This Post

Esther and I were teaching a Behind Closed Doors tutorial at Better Software yesterday. One of the participants was a program manager. He couldn’t see the value of the standup meetings the Scrum teams used every day. “They talk to each other all the time–why do they need the standup? I can’t see the value.”

That’s because the standup has little or no value for a program manager. The value is all for the team. The standup is where the team recommits to each other–every day. The standup is where the team can build burnup or burndown charts (with virtually no overhead). The standup provides the team, not just the Scrum Master, with early warning signs the project is stalled (e.g. if someone consistently misses deliverable dates, or if related features were mis-sized).

The standup is too granular a level for the program manager. (Especially if the program manager really is managing several interconnected projects or several releases.) I asked the program manager if he received the data he needed from the team–and he did. He wanted to save the team the less than 15 minutes a day they spent on their Scrum. I suggested he stop going to the standups altogether. Less than 15 minutes a day is a small price to pay for receiving early-early warning signs of project problems.

If you’re attending standups, and you’re not part of the product development team–the people developing the product– are you receiving any information you really need? If you stopped attending, what would happen to the project? (Hint: it might go faster, because no one will be inhibited by your attendance. The team will discover problems earlier and fix them earlier.)

Labels: meeting, project team, Scrum

Tweet This Post

A number of my clients and colleagues are struggling with the problem of bringing people into their organizations. In Hiring the Best …, I recommend the buddy system for bring people on. I wrote a little article, How2 Create a Buddy (Informal Mentoring) Program.

But maybe you didn’t know that, or can’t figure out how to make the buddy system work. That was the case in a recent conversation I had with a colleague. He’s working for an organization that has a heavy emphasis on finishing the product that brings in revenue. They have no unit tests, no smoke tests, no automated regression tests. They’ve hired a bunch of new people to work on the next release, but all the experienced people are on the old product, finishing the release to generate revenue. He said, “No one has time to spare for the new people.”

So, to spare people from interruptions, he’d thought of a technical idea: develop a static code analysis tool, and derive a functional spec from the code. I suppose that’s possible, but I have doubts as to how that will actually work. In my experience, people need to talk to other people. Reverse engineering small pieces of code is ok, but not large pieces.

Using the Rule of Three (need three alternatives), I suggested he had other alternatives rather than just a technical solution. He could ask people to pair with each other, so that they learn as they develop. (Even if the new people were pairing, they’d be better off. The best was to pair an experienced developer with a new developer.) He’d get technical review along with people learning all the pieces the system (the project management alternative). He could still ask people to buddy with each other, but limit the buddying to one person each week with one other person (the management solution).

I don’t know what he’s decided to do, but I hope he considers more than the technical solution. In this organization, having people work alone is not helping. The more people work together, the more likely they will be able to release something.

Labels: buddy, project team, rule of three

Tweet This Post