For example, if you have cross-functional teams in Boston, Chicago, San Francisco, and Bangalore, you have 4 distributed teams. If you have 4 teams, each with 2 developers from Boston and Chicago, a BA from San Francisco, and a tester from Bangalore, you have dispersed teams.

You’ll have the same number of people with different results. The dispersed teams will take longer to create deliverables of sufficient quality to use. Not because they aren’t capable, just because the time difference creates delays in finishing work.

We see examples of successful dispersed teams all the time–open source projects are a prime example. But if you have a short schedule, distributed teams are better than dispersed. And, co-located teams are best, assuming you have schedule constraints.

I’ve been working with programs of people who have dispersed teams all over the world. Those people are finding it quite difficult to be agile, because the dispersal creates a systemic obstacle. I’ll get into that more later.

I also am reading Hackman’s Leading Teams: Setting the Stage for Great Performances. There’s a great matrix on p. 52 that talks about the four levels of team self-management: Manager-led teams, self-managing teams, self-designing teams, and self-governing teams. On Manager-led teams, the team members execute the team tasks. In self-managing teams, the team members also monitor and manage their own performance. On self-designing teams, the team members decide how to organize to execute the tasks, and decide if they need new people and what they need to do. Self-governing teams also set the overall direction as well as everything else the other teams do.

I was trying to decide what to call Team A. On Team A, there are a number of specialists, who are quite happy to take items on a backlog, claim them at the planning meeting, estimate them alone, complete them alone. When a problem is reported, these folks often say, “It worked on my machine.” To me, Team A is a manager-led team. The team has not determined how to monitor and manage their own performance.

Team B is also comprised of specialists. Team B does not have a formal structure; it exists within a serial lifecycle in its silos. But the people on Team B often have lunch together, and discuss their issues over lunch. (A different form of a standup!) They tell their managers what they need to do. They have included people and excluded people from critical-path tasks. They are the ones driving the project to completion. They developed release criteria and milestone criteria. To me, Team B is a self-designing team. (Yes, that organization is lucky Team B exists.)

To move from manager-led teams to self-managing teams, there is often a transition state. I’ve been calling that state “self-directed” but that may not be the right word. (If you have a better word, I’d love to hear it.) In this “self-directed” state, the team members transition from working along to working together. They commit to the work and deliver the work as a team. But, they still don’t address their team process. They still don’t know how.

That’s where facilitative management comes in. If you are a manager and your team has managed to move past the “I own this work” to literal team work, and they don’t discover issues at their retrospectives, you need to facilitate their discovery of their problems. Maybe you throw out a question, “What would it take if we wanted to move to one-week iterations?” Or “What if we decided to use a kanban system to reduce WIP? Are our stories sufficiently small?”

If you are a team member, assess the kind of team you have. Are your managers determining your iteration duration, team makeup, who does what? You may be working in timeboxes, and you are still a manager-led team. I see a lot of agile transitions that look like this. Are you on a team who is not quite ready, as a team, to address your work processes, even though you commit to and deliver work as a team? What do you need to do or to learn to take that next step?

If you are a manager, look at your actions. Are you enabling the team(s) to work without you, or are you keeping them dependent on  you? Do they need team training, that is training in how to facilitate their work as a team?

Assessing the team state is the first step in identifying a team problem. Look at your team and ask yourself, “What state is this team in, and how long has it been in this state? Is that state okay, or would we benefit from moving to another state?” Then you can ask yourself, “What can I do to help?” Now, your assessment is worthwhile.

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.

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.

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:

• Iterative planning and development : No one has to predict the entire schedule or how the entire product will work in advance
• Get small things working: Don’t wait unti the end of the project to get feedback on things from the beginning
• Work together: Collaboration makes the best products, whether those are software products, documents, or bird cages
• People create things, processes don’t: Make sure you have an environment in which and a staff with whom everyone can work.There’s more, but these are the practices that speak the loudest to me.When you create projects that use agile techniques, you break down artifical barriers (hierarchy) and create working teams who develop and release working product. Sounds good to me.