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

A client recently asked me how many people should be on his agile team. “I have a two-person project here, and a 23-person project there. Do I want two teams, one of 2 and one of 23? Oh, and how many testers do I really need?”

I can believe there’s a small and short project that just needs two people. But when I asked him, he meant just two developers. I suggested he might want at least one tester, and what was the project? A boot ROM. I asked about the deadline. Three weeks. Was there any automated testing so far? No. Were there edge cases that were a problem? “How did you know that’s why I needed to rev the boot ROM?” (Lucky/educated guess.) I suggested three or four testers and maybe more people to develop some small simulators so the developers could test as they proceeded. “Why do I need so many testers?” Because there are so many possibilities of boards, OS’s, firmware versions, and some software, that even with combinatorial testing approaches, the fact that they felt they needed to boot all the way each test meant no test could take fewer than 5 minutes. That means a given tester is limited in the number of experiments he/she can do. If they had more time, maybe they wouldn’t need as many testers, and the developers would have to do more testing.

Now, for the 23-person project. I explained I would break that group into 3 teams, making sure there was a developer, tester, customer/ba/requirements person, writer, some sort of project-manager-type person on each team, and add however many other developers and testers the team thought they needed. “Isn’t there a correct ratio of dev to test?” No. (I discussed this in Manage It!: Your Guide to Modern, Pragmatic Project Management and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects and in It Depends.) Testing is all about obtaining enough information to assess risk. If you can’t easily test to get the information, you need more testers.

As for team size, I did some research (in addition to my experience) for Manage Your Project Portfolio, and found that while there is a somewhat ideal team size of roughly 6-8, fewer than three leads to worse decision-making. More than 9 leads to people grouping themselves into two teams. Once you have 10 or more people, the communication paths are so high that not all people have commitments to each other. Without those commitments, it’s impossible to create a team. You have a group, not a team.

I wish there was a recipe I could give you for team size and dev/test ratios. I can’t. No one can. Assess how many people need to commit to each other and how you will get the information from testing. Then you can make an informed decision.

Tweet This Post

Last Tuesday, I had a blast at Boston SPIN. I led a roundtable about transitioning to agile, and discovered that not everyone takes the feedback the timebox gives them. In this case, people weren’t finishing what they “attempted to commit to” in the timebox, but they extended the timebox. I suggested that was not such a hot idea; that they should take the opportunity to do a little retro and discover why they couldn’t finish in the time. Maybe it was an estimation problem, maybe it was something else.

For the main talk of the evening, Andrew Stellman and Jenny Greene spoke about Beautiful Teams. I wrote an article (what do you call it when it’s part of a book?) and Andrew and Jenny asked me to explain it during their talk! (If you click on their link, they have a picture of me too. How sweet is that?)  Abby graciously allowed me to use her as one of my props. I pretended to be tall and she pretended to be short. Great fun all around.

One of the best things about Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders is that aside from seeing patterns of teams that work and don’t work, none of the authors receive a royalty. All of the royalty money is going to PlayPumps. I don’t know how much money the book will raise, but I have some hope we can make a little difference in helping some villages manage their water needs in a way that doesn’t require half their workforce to get water every day.

Andrew and Jenny, thanks so much for giving me some microphone time. I had a blast!

Tweet This Post

I spoke recently with a (new) Scrum Master with a team who’s new to Scrum. One of the team members is a little stuck. He doesn’t feel comfortable going to the task board to take a task when he’s done. He wants to wait until someone else is ready and then work with that person.

Part of this is ok–the working with someone part. But my colleague asked, “How do I get him to take initiative?”

You don’t. You can make it easy for someone to take initiative. You can make it a team norm. But you can’t make someone take initiative.

I know something about this organization. For years, the managers have estimated everything. The managers doled out tasks. The managers told everyone how to do whatever needed to be done. The managers made all the decisions.

This guy started at the company right out of school, has been there for almost 4 years. Why would he change his habits of 4 years in one iteration? How can he trust the management to not return to their old behavior and tell him he’s working wrong and they will tell him how to work right?

This fellow needs to see that management will allow the team to work the way they need to, without management interference. I don’t think he needs 4 years of seeing it, but he needs more than one iteration. He especially needs to see what happens when the team doesn’t meet a commitment during an iteration.

If someone is afraid of committing, or of taking work, or of anything else that smacks of self-management, take a look at the recent history. Does that person have a reason to be concerned? If so, address the issue at a retrospective. Don’t expect people will change just because you want them to.

Management who are attempting to move from command-and-control to encouraging a team to be self-managing need to extend trust first. Even if the team has shown no reason to be trustworthy–yet. Management needs to make it easy for people to succeed at new behaviors.

And if you’ve hired people with little initiative (hard to believe, but possible), explain what you need, ask for results, and back off for a while. Let people learn how to take initiative. There’s a reason it’s called “take initiative “and not “give initiative.”

Tweet This Post

Via Jack Vinson, I found this gem: Stop doing half-actions.

All of you who are separating your developers from your testers? You are doing half-actions. Separating the writers from the developers and testers? Half actions there, too. Even when you define architecture and implement across the architecture, instead of by feature, that’s a half-action. A half-action means you have technical debt and will have to get back to that area of the product.

Silos encourage half-actions (or third-actions or sixth-actions). Defining the architecture and implementing across it encourages half-actions. Create a cross-functional product development team. Have them finish one feature at a time. That’s a full action.

Tweet This Post

I was talking with Don Gray this morning about our work on the AYE Conference. I’m the marketing chair, he’s the program chair. We were discussing the sessions we have so far, and I said we could put one of the management sessions into the team effectiveness track. “No,” Don said, “Managers aren’t part of the team.”

Blow me over with a feather. I agree that managers aren’t part of the technical work that their team performs day-to-day (although some of my clients try to use their managers that way). And the more agile the team is, the less the manager can participate in the same way that the developers and testers do. But I thought managers were part of the team.

So, I started thinking about what a team is. Esther and I used Katzenbach’s and Smith’s Wisdom of Teams: Creating the High-Performance Organization as a source in our definition of a team in Behind Closed Doors:

• Teams are small, generally 5-10 members
• Teams are committed to a common purpose or goal
• Teams have an agreed-upon approach to the work
• Team members have complementary skills
• Team members have interrelated or interdependent interim goals
• Team members make commitments about tasks to each other

Here’s what I’ve seen. Yes, the manager (project manager, functional manager, whatever manager is associated with the team) has additional goals than just one project or team’s work, especially if that manager is managing several projects or teams. The manager has additional commitments than just the ones with a given team. And managers who don’t take their commitments to the team seriously are not part of that team. (I’ve been part of teams where we were united in our goals against the managers.)

There’s always a tension between the managers and their management work–especially managing up–and the team’s work. But I guess I’m still missing why great managers are not a part of their teams. Are your managers part of your team?

Tweet This Post

Laurent’s post, The team building lunch prompted a bunch of (hopefully now organized) thoughts about the role of food in high tech projects.

One of the things I notice when I perform assessments is whether there is some sort of cafeteria or other food-eating place. Projects that have a physical place large enough for a project team (or two or three) to eat lunch together have multiple opportunities for learning and problem-solving.

• We know that defects cluster within modules. I also believe that defects cluster across a project. If the interfaces aren’t well-defined, and if the lifecycle or practices don’t help people determine how to resolve the interface issues, more defects arise at the (logical) interface. Informal conversations over lunch help people detect those problems and fix them.
• Testers can talk to developers, writers can talk to developers and testers, support staff can talk to everyone. Even though many people recognize that the org chart isn’t supposed to prevent them from talking to one another, sometimes it does. Or the geographical separation of people (on different floors, in different areas) prevents them from easily speaking with each other. Lunch (temporarily) removes the separation, whether by organization or geography.
• Discussion over lunch can become an informal peer review, not necessarily just by the other people in a single product area. When I was a tester at Symbolics, I regularly ate lunch with the developers. I learned about the product internals, and asked lots of questions, especially when I didn’t understand the design or the progress the developers claimed they’d made.
• As a project or program manager, I used lunch as a technique to hear the project status in a different way. People will discuss what they’re having trouble with over lunch, or if they’ve succeeded at solving a particularly thorny problem.

Now, when I work with a project team where the testers don’t know a lot about the product, I usually suggest the testers and developers have lunch together. Or, when I teach workshops or consult with an organization, I eat lunch with the people I’m working with.

I don’t know of a good substitution for a lunch place, where people can sit and eat and discuss their work informally. (The little kitchen areas many companies have are good for brief informal conversations, but there’s no place to sit.) The quality of the conversation over lunch tends to be richer, especially when people take a full hour for lunch. The introverts finally have their chance to talk (one of Laurent’s points). If you’re a manager and you think you can’t afford the space for lunch, think again. Lunch is free peer consulting across the organization and offers the possibility for technical problem-solving at its finest.

Tweet This Post

I’ve been subjected to a bunch of team building activities that fell flat for me. My Last Word column in this month’s STQE talks about alternatives to team building. Here’s the quick recipe:

1. Choose a topic the team has a vested interest in solving. (If the people can’t come up with one, you don’t have a team, you have a group. Let them go back to work.)
2. Create a situation where the people have to work together to solve the problem.
3. Debrief the solution and the activity.

Every so often I’m asked to speak at a big corporate event that’s supposed to be a rah-rah or team-building activity. When I do that, I ask for enough time so we can perform an activity together, either all of us, (or more likely) in small groups. Then people learn from each other and create sub-groups that can function as teams.I dislike pep rally-like things (nope, didn’t like them in high school either), or other situations where some desired result is based on something I can’t control.If you’re looking for team-building, or you want the whole company behind you, first break down the problem into something teams can solve. Then break into small groups that can function as teams. (Teams can be cross-functional, depending on the problem.) Facilitate the teams to perform at their best. Voila! Now you’ve created a team situation that works, where you’ve helped solve some problem important to the company, and we haven’t rah-rah’d, hugged, or sung a (foolish) song.And, if you’re the kind of person who likes those rah-rah things, or singing company songs, more power to you. (I don’t think many technical people fall into this category.) Let us technical people help you by providing background work to make you successful.I do like team situations; I don’t like artificial closeness to people with whom I work.For more on meeting ideas, see:

• Managing Group Meetings
• Round Robin Pattern
• Measure ROTI
• Esther’s ideas about the weekly status meeting
• Freedom From Meandering Meetings
• Meetings that Work from the Aye Conference wiki.

Tweet This Post

I think of development and test as partners. The developers create product and defects. The testers detect product and defects. They both need to understand what the product is supposed to be and how it’s supposed to work (the requirements). The more the developers explain the architecture and design, the better the testers can test the product and detect defects.

So why do some people think that developers and testers are supposed to be antagonistic? The “necessity” of antagonism shows up in surprising-to-me but altogether too typical ways:

1. Retaining the end schedule date even though the developers have slipped their schedules, reducing the time allowed for testing. If the product hasn’t worked up until now, why would you want to reduce the amount of time for testing? Wouldn’t you consider increasing the time for testing, if it was important to deliver a product with fewer defects? If it’s not important to deliver a product with few defects, why assign testers at all?
2. Saying “It’s just a one-line change; you don’t need to test that.” Yeah, right. All of us know the fallacy of that statement. But when we say it to testers, what we’re really saying is, “We don’t care if you did find something with this change; we’re going to release anyway.”
3. Making the testers responsible for quality. Testers didn’t create the product, they can’t be responsible for quality. They can report on their detection of the state of product quality, but they can’t be responsible for quality.

I suspect the reason to create tension between development and test is to mask incompetent project management. If the project manager can’t figure out how to create a quality product given the constraints, s/he can blame the developers and testers by creating tension between the developers and testers. By the time they’re done yelling at each other, the project manager can look like an island of serenity and competence.

Instead of creating tension between developers and testers, let’s create projects where the entire team is out for the same thing. Where everyone understands the project’s constraints and requirements, and creates ways to work together to achieve a successful project. (In my post tomorrow, I’ll talk about the project’s constraints and requirements.)

In the meantime, if you see a project where the developers and testers are in tension, step back and look at the big picture. Is the project manager helping or hurting the project? Does everyone know how little the project can accomplish before the project is done? Does everyone know what the project’s goals are? Does the schedule make sense? Is anyone measuring anything about the project?

Tension between developers and testers is not creative and does not help the project. Teamwork, where the entire project is focused on one goal helps the project. Look for teamwork, not tension on your projects.

Tweet This Post

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:

Tweet This Post