Some years ago, you may recall, everyone was upset about the possibility of software development deserting the U.S. and going overseas. Now we’re upset again, though the destination countries are different. The problem was that the Japanese were going to set up software factories that would crank out software widgets and reduce systems development to a process akin to building with Lego blocks. Well, that didn’t happen. The thing is, we can have a factory to build semiconductors or cell phones, but we can’t have a factory to build software. There is only one thing that creates software, and that is a human brain. There is only one thing that creates lots of software; lots of human brains working together.
Right there we have the problem. It’s that "together" word. We mostly train software developers to work on their own. In fact, we have a special word used for effective collaboration on software projects in colleges. The word is "cheating." Colleges teach software people to solve software coding and design problems by themselves. Industry requires, nay needs, people to solve different kinds of problems and to solve them together. We find that many engineers just don’t know how to do this. True, some colleges have started students working on teams. Having run many technical team development programs over many years, I often ask people: what were their finest and most awful team experiences. The typical college software project (along with anything to do with the game of volleyball) features heavily in the "worst experience" column. The reason is simple: people are put onto teams and expected to function in a teamly manner without knowing how to do it. Not surprisingly, it tends to be a negative experience.
The team-building card has, unfortunately, been somewhat overplayed in the last few years, perhaps generating burnout on the subject. A friend of mine working for a major U.S. company noted that he was currently on seven permanent or semipermanent teams at the same time: two product teams, two different process improvement teams, a member of the Division SEPG, a management advisory group, and a customer support SWAT team. Additionally, he was regularly called on to be a part of inspections teams, not to mention teams in professional organizations outside of work. At the mention of the "T" word he would run screaming from the room. Clearly, there is a danger of wearing out the batteries.
Nevertheless, people do like to work on effective teams, and we do need them to work on effective teams. So what is it about the software business that affects how we build teams? Contrary to popular opinion, software engineers are actually people underneath it all. While the average social need for software developers has been recorded as being significantly below the "average" for the population-at-large [4], even programmers are social animals at some level. And while the need for exquisitely intricate meshing of peoples’ intellects and understanding is somewhat lessened by good modular design, they do need to talk to each other and understand what each of the members is doing, if we are to have any hope of their products meshing when we put them together.
Here are some pointers to creating, or more correctly, growing, good technical teams.
As an industry, we don’t accomplish much effective team development, or if we do, it’s not done about the business of software, or it’s not done relating to the activities and mental disciplines of the software environment. Not that software people are that different, it’s just that we don’t seem to think about it much.
Low social need. This is probably a great oversimplification, but many engineers simply do not like to interact socially as much as other disciplines (like, say, talk show hosts). This is not a bad trait or a good trait, but it is a trait. I know of two good friends who sit in adjacent cubicles, who routinely email each other with questions, answers, plans for lunch, and even jokes. They do have a rationale for this behavior, but whatever the reason, it works for them. One of the mistakes made in team development is the "if you’re not participating you’re not a team player" attitude. While it is perfectly appropriate for an effective team environment to stretch people beyond their comfort zone (which is the only place they’ll really learn), an effective team does accommodate different working and communication styles. In posing some quite difficult technical problems to teams-in-progress, I often see them attempt to force a highly involving social style on the "quieter" members that is alien to them. It doesn’t work well.
Lack of team training. Partly as a result of their college experience, partly due to the rather cerebral nature of systems development, and partly through a process of self-selection, many software engineers get little or no exposure to team concepts and some of the basic models of communication. The plus side of this situation is, if it is done with some finesse (please, no "trust falls"), they are very open to some of the simplest ideas in team development. I think the social basis of software engineers is changing, and I see younger engineers being noticeably more social than they used to be.
Mental models. Code is a mental model of a problem/solution space. Ditto requirements models, designs, and even project plans and test cases. Software itself is thought put down in a particular place using a particular convention. The trouble with this is we all think differently, and it can be quite surprising to find that your colleague really does not think like you. One primary value of a methodology, or even a programming language, is it tends to force a certain commonality of thinking. The thinking process is what we use to recognize, understand, and create software. Since different people think differently, it’s not surprising that, given the same input, we end up with different answers. One of the challenges in software is it requires so many different types of reasoning for which some mental models are useful and some are not. As examples of the different reasoning needed, we could point to the generally inductive process of requirements definition and the generally deductive process of debugging. Psychologists have some interesting approaches to understanding thinking applied to software development. This is surprising since software is all about thinking.
Communication. I routinely work with engineers from the telecommunications industry who spend all day figuring out how to make one machine communicate with another. Yet they know little about how to communicate with each other. At a systems level, human-human communication and machine-machine communication have similarities. There are protocol conversions (related to the difference in mental models), ack-nack handshakes (often given nonverbally), message headers and packets, direct and indirect addressing, summary trailers, and a whole bunch of other routine systems conventions in software development. We do it between systems and between machines, but not between ourselves.
Different people. As well as different mental processing, we are different people. The classic manager is verbal, directive, and results-oriented whereas engineers tend to be cerebral and inductive thinkers with a strong streak of process orientation. This makes for some predictable misunderstandings.
- Boss: "Bill, I need this design completed by next Wednesday."
- Bill: "Uh, boss, I’ve never done this kind of design before, what should I do?"
- Boss: "I already told you. Do it by next Wednesday."
- Bill: "But what process should I use?"
- Boss: "Use whatever process will get it done by next Wednesday!"
The Boss leaves this discussion thinking that Bill needs his hand held too much, while Bill thinks the boss is arbitrary, abrupt, and singularly unhelpful. They are, of course, talking about different things. The goal-driven boss is talking about the end-state, the result; the inductive-thinking Bill is looking for guidance on how to get there—the process. There is evidence that people who are sufficiently process oriented cannot even visualize the end-state unless they can sort out the steps to get there.
As an industry, we don’t accomplish much effective team development, or if we do, it’s not done about the business of software, or it’s not done relating to the activities and mental disciplines of the software environment. Not that software people are that different, it’s just that we don’t seem to think about it much.
What Works Best
Participate in only one team. Not everything has to be a real team. There are working groups and loose associations. There is a set of key factors that determine if a team is a team. If these factors are not present, the team is just a bunch of people breathing the same air. People cannot effectively identify with and invest in too many different groups. Best to save it for when it really counts.
Create a shared goal set. A common, participative purpose is the sine qua non of teams. Often, particularly in software teams, an explicit and fully factored vision of the goal(s) is not possible early on. It must be constructed over time. Curtis et al. [3] showed that the software vision has three parts: what the customer needs, what the team will produce, and how the team will produce it. These correspond to the requirements, the design, and the process. The extent to which a team unconstructively disagrees on any of these will often determine the team’s effectiveness.
Develop a common language suite. To communicate, we must share languages. These obviously include programming and design languages, but they also include languages that govern the interactions between the team members. Most effective teams adopt a team code for discussing issues, often involving in-jokes, and an explicit or implicit code of conduct that governs their rules for behavior.
Co-locate. Groupware notwithstanding, there are few things we can do to cement a team that works as well as putting people together. Close proximity allows communication and understanding in a way that makes the communication much more efficient, and personal relationships much more effective.
Experience a collective discomfort. The U.S. Marines use this technique extensively to forge teams. While sending a bunch of programmers to Parris Island might be somewhat extreme, a shared discomfort while not, well, comfortable, cements a team like few other experiences. Ironically, the complete failure of a project sometimes qualifies as one such experience. The challenge in building a team may be to make this formative experience strong enough without disabling the team, or causing it to be disbanded.
Experience some success(es). The other side of the discomfort coin is for the team to jointly experience a win or two. These successes must be accepted as team successes, rather than the result of individual effort. While individual effort is really important, it is the mark of the true leader that he or she genuinely acknowledges the role of others in whatever success is obtained.
As an industry, we’ve spent an awful lot of time in the mechanism area. Maybe it’s time for a bit of the organism.
Leadership. While it is sometimes overblown, the role of the true leader is crucial. Jerry Weinberg pointed out that leadership on technical teams is often diffused over many people, each person leading in some respect [5]. Managing is not the same thing as leading. Good leaders are not manipulators of people, they are ethical, consistent, and capable people who have a vision, and share and merge that vision with the people they lead. This is not the same thing as "managing."
Talk it up. One of the most obvious characteristics of good teams that I’ve observed is they talk themselves up. They constantly tell each other and themselves (and sometimes anyone else who will listen) how good they are. While this may be viewed as self-aggrandizing, I have seen it help to forge team spirit more than a month of bowling nights.
Ask for what you need. Teams do not work in isolation. While most of the team’s behavior and much of its success can be self-generated, the team still relies on the organization to provide it with the resources it does not have. The obvious prerequisites are time, equipment, and people, but they also include information, authority, and influence. An effective team will lobby, or even demand, the resources necessary to be successful.
Profit. Lastly, there has to be something in it for the team and the people working on the team. Basically, the rewards for behaving like a team must exceed the rewards for not behaving like a team. The very fact a person is working on an effective team is often a singular reward. But there is much that a leader, a team, and an organization can do to create team-based rewards that are meaningful to the people and to the team.
There are two parts to a software organization: the mechanism and the organism. The mechanism is the process, tools, organizational chart, task assignment project plans, methodologies, languages, and so forth. The organism is the people, how they think, what they feel, what motivates them, and how they work together. As an industry, we’ve spent an awful lot of time in the mechanism area. Maybe it’s time for a bit of the organism. On the very front cover of two of the most erudite and influential books on software development, Barry Boehm noted that, of all the factors that effect software productivity, the most important, by a long way, was team capability [1, 2]. Go team!
Join the Discussion (0)
Become a Member or Sign In to Post a Comment