This section is intended to assist you in the team work you do for CS 132. The suggestions that are provided should enable you to have a positive team experience, thereby improving your overall team performance. Portions of it are directed to the large project to be completed towards the end of the term.
The issues addressed include motivation, team dynamics, organizing meetings, and dealing with internal team problems.
Suggestions for improvements to this document are most welcome.
There are many advantages to working in a team on a project:
Finally, team work provides practical real-life experience. Few people will obtain jobs that enable them to work in complete isolation; it is necessary to learn how to work with other people, even if you would rather work alone!
You should be aware at the onset that team members will evaluate each other at various points and that your participation in the team effort will be factored into your grade.
You should think carefully about the individuals that you would like to work with on the final project. The project is designed to be completed by groups of two members, but you may also choose to work alone or in a group of three. The size of your team will not have any impact on what we require as an end result.
Teams of three have their advantages and disadvantages. A larger team has a broader base of experience, can continue to function to some extent even if one person is missing, and obviously has more people to do the job.
Teams of three also have a serious potential problem known as triangling . This is where two of the people make an unconscious alliance resulting in the third person often feeling marginalized, over-ruled, or left out. Needless to say, this is an unhelpful situation — guard against it! If you feel like the outcast, don't hesitate to say that you feel triangling is going on and would like the other two members of your team to guard against it more diligently.
Pair-programming is a software development approach that is being adopted in both industry and the educational field. If you are interested in pair-programming, you should read this guide. If you do decide that you would like to pair program while working on the project, you should think about how this may affect the number of members in your group. Groups of two can easily employ the pair programming approach. Groups of three require a bit more ingenuity. For example, you could consider working in pairs with each of your group members or try triad programming (all three of you working at once).
Regardless of the approach that your team uses or how you choose to split up the work amongst the team members, each member is responsible for understanding all parts of the project. Any concepts involved in the project are testable material. The two major parts of the project involve implementing the model or logic of the program and implementing the user interface. It is in your best interests to work on and be familiar with both of these pieces.
There are a number of other potential problems that you should discuss with your partners.
Knowing the source of these problems so that you can deal with them head-on when they arise is half the battle!
As soon as you have chosen a group you should exchange basic information with each other. Write this information down and keep it handy!
You should do some preliminary project planning. This could include:
It is important to remember that preliminary plans and schedules may change. However it is far better to start with a plan that gets revised than to not have a plan at all!
Create a general information sheet containing your names, userids, phone numbers, topic and scope, possible enhancements, and your preliminary meeting schedule including both time and place. Each team member should keep a copy of this information.
During your first (and possibly the second) team meeting, you may want to begin thinking about the following:
Your meetings need not follow a formal structure, but you should be sure to cover the following in each of your meetings:
In addition, you may want to consider the following:
Once work is delegated each member has certain rights and responsibilities.
In any team situation, it is highly unlikely that all members will agree 100% of the time. There are three major decision-making strategies when team members disagree:
In Decision by Majority, a vote is taken and the majority rules. This strategy obviously will not work for teams of two people. Moreover, in a majority decision, the "election losers" do not agree with the decision, are not happy with it, and so may try to sabotage the project. At the very least, the "losers" will not likely be satisfied with the outcome of the project. Making decisions by majority is not recommended.
Unanimous consent occurs when everyone truly agrees on the course of action to be taken. If unanimous consent can be achieved, it is ideal. However, achieving unanimous consent may require an extremely large investment of time.
Consensus occurs when each person in the team feels that they have had a fair chance to influence the decision. Every member may not necessarily agree with the decision, but understands the final decision and is willing to support it.
Consensus is most easily achieved by compromise. Whenever there is a disagreement, no single member should expect to get everything their way. Each member must decide what is most important, and be willing to give in on other issues.
Making decisions by consensus is the recommended course of action. It is a more efficient means of making decisions than by unanimous consent, and is much more likely to result in overall satisfaction than making decisions by majority.
Information on how to avoid problems can be found in the Pair Programming guide.
Information about Common Problems and Suggested Solutions can also be found in the Pair Programming guide.
The material on teams was developed by Jack Rehder with the assistance of Bill Shalinsky and the other members of the TRACE office.