Managing Product Development

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.

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?

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.

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.

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.

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: