]
]If your instructor allows you to choose your own team members, do not take it lightly. Try to assemble the best team you can - it certainly doesn't hurt to have a great team.
When someone offers to join your team, try to find out whether he/she has done a good job in previous course projects. In extreme cases students hold formal interviews to select team members. You can also check the workload that person is planning to take, including extra curricular activities and external commitments. This is to ensure that he/she can commit enough time to the project. Schedule and location compatibility matters too. For example, teamwork is easier when team members have similar schedules and live close by (e.g., in the same student residence).
You need not pick only those with good programming skills, as team members' skills should complement each other; Remember, the course is not just about programming. Having said that, programming skills are critical to the project - try to pick at least one or two good programmers.
While creating a team out of your best buddies have many advantages, there is a downside too. For instance, you will find it hard to maintain a professional atmosphere to your project. Fruthermore, you may be forced to put up with low contributions from some of your team members for the fear of loosing the friendship.
Unlike a typical project team in the industry, ...
Considering the above factors, the following is one suitable team structure.
Note that the above team structure is just one suitable team structure; there are other ways to structure a team, such as the "chief programmer team" and "egoless team".
A guru's role is to specialize in a given area; to learn the area in-depth, help other team members on matters related to that area, and ensure sufficient quality in your product with respect to that area. For example, testing guru will look for good testing tools, help others in writing test cases, troubleshoot test tools, ensure that adequate testing is being done, etc. It will be the testing guru's responsibility to earn the team as many points for "good testing" as possible. Other possible guru-type roles include SCM guru, documentation guru, Build guru, Integration guru, Visual studio guru, C# guru, Performance optimizer, Design maintainer, Deadline watcher etc.
Note that every team member should have basic knowledge of all aspects of the project, not just the area you are guru of. The testing guru cannot limit him/herself to testing only. The idea is to become a "Jack of all trades, and a master of at least one", i.e., to acquire a so-called "T-shaped" skill set. Here, the horizontal bar of the T represents the breadth of knowledge in many areas i.e., "jack of all trades", and the vertical bar represents the depth of knowledge in some areas i.e., "master of at least one". Such a skill set, said to be in high demand in the job marked, should greatly enhance your employability.
Note that all of you are novices to begin with, but everyone can become an expert in a given area, if you spend enough time on it. Choose an area you like; that should help to keep you motivated.
It is recommended that some assume the role of the 'team lead'. 'Team lead' role does not put the person holding it above others in the team. Treat is simply as another role one has to play in the team, albeit an important one. Assuming that everyone will share the leadership role (and the responsibilities) rarely works in a student project.
Leading a team of software engineers is no easy task. It has been likened to "herding cats" (in The Pragmatic Programmer).
The role played by the team leader is slightly different from the other team members. Playing this role is a valuable learning experience. Ideally, all students in a team should get this experience. Consider the following strategy: after completing each major milestone, current leader steps down if another team member volunteers for the leader role. This should not be considered "challenging" the current leader; Rather, it is saying "that looks like something worth learning, I want to try it too". However, it is OK if you want to keep the same leader for the whole project.
Another way to lessen the burden of the team leader and spread the leadership experience around is to have group leaders for each sub-group. The team leader can be one of these group leaders, or a separate person altogether. If the latter option is chosen, the team leader will only make high level decision that affect the whole team (e.g., decisions related to system integration), while he/she will be working under the respective group leader at other times.
A team/group leader is generally expected to consider opinions of the other team members and achieve a consensus before making decisions. However, there will be times when the leader has to make quick and hard decisions on his/her own, either due to time pressure, or due to irreconcilable differences of opinion between team members. A team/group leader can also consult the supervisor to get one more opinion before making decisions. Once a decision is made, others should respect this decision and try their best to implement it.
These are the problems that make you feel like you are not "part of the team".
Problem: Your team took a decision against your opinion.
Recommendation: While the team's decision may be different from what you believe to be the best way to proceed, it might still lead to a reasonable outcome. Do your best to help the current course of action succeed. Do not try to sabotage it or distance yourself from the work. You can also persuade the team to get the supervisor involved in the evaluation of options. Finally, make sure that the decision point is well documented (see Note 1).
Problem: You want to contribute. But the team appears to cut you out (e.g., when the other members have a history together, and you are the "outsider").
Recommendation: Voice your concern to the team (E.g., "I worry that I'm not pulling my share of the load, can I have more work?"). Alert the supervisor if the situation doesn't improve. Above all, don't delay. This problem surfaces in the early stages of the project and it should be solved in the earliest. It is your responsibility to notify the supervisor early if the the team does not respond to you positively. If not, you might get penalized for not contributing enough.
Problem: Your team is doing fine without you. They don't mind your lack of contribution. Their attitude is "stay out of the way, and we'll let you share our success for free". They give you good ratings during peer-evaluations although you did not do enough to deserve it.
Recommendations: If you ride along, you are taking a BIG risk. There are ways other than peer-evaluations to gauge your contribution. (E.g., your SVN/CVS activity statistics). It is your responsibility to do a fair share of the work. Most evaluators will penalize you for being a spare wheel if you did not alert him/her early enough. Follow the recommendations for the problem "My team cut me out!".
Problem: Someone else has done (without telling you!) the work formally assigned to you.
Recommendations: If you did your part on time and with the required quality, you have a right to insist that the team uses your work. However, note that this is usually a symptom of other problems (E.g., team has lost confidence in your work). Alert the supervisor so that those problems can be sorted out.
Problem: Others are from country X except you. Most of the team discussions are done in their own language.
Recommendations: This is unacceptable. Alert the supervisor immediately if the team does not respond positively to your request to use a common language. If you didn't alert the supervisor early enough you cannot blame this problem later.
Problem: as the title says
Recommendations: No team member is perfect. You may be weak in programming while you still may be good in some other aspect. Don't make your weakness an excuse for a free ride. If your teammates are much stronger than you, don't expect an equal share of the credit they earn for the team. Accept tasks that you can deliver and then deliver it to the best of your ability. As you learn more, the team's confidence in will you grow.
A "jelled" team is a team functioning smoothly - like a well-oiled machine. Unfortunately, student teams do not jell that often. Problems within teams are common, and working them out is part of the learning experience. This means "team problems" is not a valid excuse for making a mess of the project.
When a particular team member is causing problems within the team, we should consider that this may be unintentional. Therefore, it is important that he/she is made aware about the team's concerns. Keeping silent will not solve the problem. Rather, it will deprive this person of a chance to amend his/her ways. Do this in the earliest possible moment, but discuss the issue informally and gently. Firing off an "official" email to everyone and CC'ing the supervisor is not first thing to do. However, if the situation does not improve within a short period (say, within a week), it may be time to alert the supervisor.
Given next are some undesirable personalities we sometimes see in project teams. See whether you fit any of them... If you do, probably your team mates realize it too, and its up to you to change for the better. Note that the uncharitable name we have given to each personality is just for the ease of reference. Please do not use them in belittle your team mates.
Problem: The leader delegates everything. He/she acts as the "management", and treats others as employees!
Recommendations: This is unacceptable. Effective delegation is a part of being a leader; but the leader (and everyone else) should do a fair share of work in all aspects of the project. Alert the supervisor. If the leader continues to evade work, change the leader at the next milestone.
Problem: One team member does a lot of talking during the meetings (especially, if the supervisor is present) and acts like the most active member of the team. But that's all he/she does.
Recommendations: Active participation during discussions is good as long as it does not stifle/overshadow other team members. What is not so good is dominating team meetings just to cover up lack of real contributions. Everyone should do a fair share of work in all aspects of the project. If not, try to sort out the issue with the culprit. Alert the supervisor if the situation does not improve soon.
Problem: A team member does not abide by collective decisions.
Recommendations: Let the supervisor know if reasoning with him/her does not work. However, note that working in a team does not mean every decision has to be made collectively. E.g., if a certain decision's impact is local to a component, let the person in charge of that component decide whether to make the decision on his/her own or involve others in the decision. On a related note, you are not helping the team by blowing up every trivial decision (local to your work) in to a team discussion.
Problem: A team member thinks he/she is more "experienced" than the rest and thinks he/she has no time to waste with "amateurs". While he/she is willing to do a major chunk of the work he/she does not want to get involved in anything else such as team meetings. (E.g., "I did the component X, didn't I? that's the most difficult part; you guys sort the rest out and leave me alone!")
Recommendations: This is unacceptable, particularly from a person who thinks of him/herself as "experienced". This behavior is going to hurt the team no matter how good the code he/she has produced. Such code usually makes many assumptions the rest does not know anything about (because there is little interactions between the team and this person), and is inflexible in ways that hinder the future progress of the project. Let the supervisor know if the team cannot get this person to cooperate. Those who fail to work as a part of a team (an essential part of being a software engineer) should be penalized, no matter how much work they do alone.
Problem: A team member is good in all other ways but cannot commit enough energy to the project because he/she has a busy schedule (extra curricular activities, other modules, competitions etc.)
Recommendations: As fellow-students and teachers, we should do our best to support this person to succeed in all the things this person is engaged in. However, a team cannot jeopardize the project due to this. If possible, adjust schedules/plans etc. to accommodate this member's availability. You can also allocate this person less work (as much as he/she is willing to take, and able to deliver) and keep the supervisor informed about this imbalance of workload. The grade needs to be adjusted accordingly.
Problem: A team member comes down with an unexpected personal problem (death of a loved one, financial/health/relationship problems, etc.), often, due to no fault of his/her. This prevents the team member from contributing equally to the project.
Recommendations: As fellow human beings, we should do our best to support this person in this moment of personal misfortune. If possible, adjust schedules/plans etc. to accommodate this member. You can also allocate this person less work (as much as he/she is willing to take, and able to deliver) and keep the supervisor informed about this imbalance of workload. The final grades will be adjusted accordingly and as per institute's guidelines.
Problem: The leader just sits around and pretends he/she is just a team member instead of doing "leader stuff". This makes the whole project effort uncoordinated.
Recommendations: Some people are not natural leaders. Change the leader at the next milestone.
Problem: A team member is inexperienced and lacks almost all skills required for the project. Helping this person appears to slow the team down.
Recommendations: No matter how "green" this person appears to be, it is well worth spending time to help him/her acquire the skills needed for the project. Always try to work in groups during the initial stages. Even coding can be done together if you use pair programming (highly recommended technique to improve coding skills). It is a mistake to cut this person out, make him/her a "spare wheel", or only assign trivial tasks to this person; you need all members of the team to contribute fully for the project to succeed.
Problem: A team member is really weak/slow, and has a track record of ending up at the bottom of the class. This is different from inexperienced team members (see the greenhorn)
Recommendations: We have to learn to make the best use of "below average" team members. Do not make them "spare wheels" or assign them trivial tasks. Instead, assign non-critical tasks that matches their ability to deliver. Your peer-evaluation should reflect the correct level of contribution from this person. But remember to give him/her a chance to contribute to the best of his/her ability. By the way, it is a big mistake to appoint the weak member as the tester of the system.
Problem: A team member suggests (or appears to be) using unscrupulous means to do project work, such as plagiarism or outsourcing.
Recommendations: RED ALERT. The whole team will be held responsible in the end. Inform the supervisor immediately.
Problem: A team member continues to deliver work of low quality
Recommendations: Inform this person that the work is below expected quality. Insist on better quality work and refuse to incorporate low quality work into the product. You can use cross-testing to reduce the risk. You can also assign earlier deadlines to this person to allow enough time for rework if needed. If the quality does not improve over time, keep the supervisor informed so that grades can be adjusted accordingly. Cutting the person out of the team is not the answer.
Problem: A team member insists that he/she will take care of a critical task. He/she is unwilling to discuss details of how it will be done or the current status of the task.
Recommendations: This may be OK if this team member has a track record of making good his/her words. In general, this is a risky situation. If the project failed because one person promised something but never delivered, the whole team will be penalized (as they should be). Make status reporting compulsory. Insist on incremental delivery. Do not assign critical components to someone before testing out his/her delivery quality. If in doubt, make critical components joint-work rather than entrusting to a single person.
Problem: A team member wants others to give him/her a free ride. Sometimes a person may try to take advantage of the goodwill of the other team members (often, who are good friends of the culprit) to let him/her share the credit without doing work. And often such a person has some "legitimate" reason for not being able to do work, and wants the team to "help" him/her out. Freeloading is also called "social loafing".
Recommendations: If the team goes along, they will have to lie about the share of the workload during peer-evaluations. the whole team will get into trouble when the imbalance of workload is noticed by the supervisor. Please give correct information about the contribution of each team member. You are being unjust to yourself other course-mates if you do not.
Problem: A team member does not take an active interest in the project. He/she keeps silent during meetings and does not contribute any ideas/solutions. However, he/she does all tasks assigned to him/her.
Recommendations: This is not a big problem as long as you do not have
too many such members. If this is due to shyness
or for the fear of being overruled, you could entice a more active role from
this person by assigning him/her more responsibility.
You can also assign tasks that force this person to participate more actively.
For example, assign him/her to "come up with an alternative design and describe
it in the next meeting".
Adopt the practice of recording each person's contributions including ideas they
contributed. This could coax the observer to be more active in the project.
However, if this person is deliberately shirking responsibilities, then it is a
serious matter akin to freeloading.
Do not blindly equate the observer's lack of involvement to his/her support for
what the team is doing. The rest of the team should continue to seek any
alternative opinions the observer might have.
Problem: A team member is less committed to the project than the rest. While you are working very hard for an A+, this person is "doing just enough to get a pass".
Recommendations: While this is frustrating, there is no easy way to motivate this person to work as hard as you are doing. Assign as much work to this person as he/she is willing to take. However, it should be clear that his/her level of contribution will affect the peer-evaluations and this person should expect a lower grade than the others. In addition, whatever this person does should be of the expected quality. Doing less is not the same as doing a shoddy job; the latter is much more damaging.
Problem: The team is highly polarized over a critical decision.
Recommendations: It is healthy to have alternate views, be passionate about your views, and be prepared to defend your views. But protracted arguments can actually hurt the team. Try to find ways to objectively evaluate the alternative views (e.g., implement a prototype of both alternatives and measure which one works better). You can get the supervisor's opinion into the equation as well. No matter which alternative you choose, it is important that everyone tries their best to implement the choice made. Also, do not forget to document the decision (see Note 1).
Problem: The team relies on the leader (or another dominant member) to do all decision making ("You are the leader, you tell us what to do!").
Recommendations:
For the team members: You are in this as much as the leader. You should share the burden of the leader, and take responsibility for the success of the project as much as the leader. The leader might not see all the alternative paths; it is up to you to point them out.
For the leader: Delegate. Assign a role to each team member (e.g., appoint gurus).
Problem: All team members are strangers to each other, preventing the team from achieving the flying start the project needs.
Recommendations: Well, the only possible remedy is the get to know each other, fast! See here for some tips on how to promote team spirit.
Problem: The team spends long hours working together, sometimes late into the night, yet accomplishing very little. A lot of time is wasted on casual conversation, teasing, flirting, joking, or arguing. No one is willing to break away for the fear of hurting the "team spirit".
Recommendations:
Problem: Several team members have formed a close and closed group (i.e., a "clique"), alienating everyone else. For example, when one of the clique members get into an argument with a non-clique team member the whole clique comes to the defense of the clique member although the discussed issue does not concern them.
Recommendations: If possible, let the clique become a sub-group, and let them work together on a sub-system. This should reduce friction between the clique and the rest of the team. If the clique continues to undermine the project harmony, get the supervisor involved to balance things out. For example, if you think the clique is forcing non-optimal decisions on the team, get your supervisor's opinion on the decision as well.
As soon as the team is formed, make it a point to spend some time together; this lets you get to know your team members quickly. Even small adjustments like having lunch together or going for a movie together can help in this area.
Doing early project activities together further strengthens your team spirit and helps you gauge the strengths and weaknesses of each other. Consider the task picking a project topic; instead of emailing back and forth about potential topics, meet together and talk it over face-to-face. Remember to pick small and easy activities for the whole team to do together quickly. This will boost your confidence in your team.
Take a "funky" team photo (Examples: 1, 2).
Brainstorm for a catchy code name for your team/product.
[side note] Names to avoid: difficult-to-pronounce names, names too similar to
existing products/companies, names that sounds like several other words, silly
names
Groups norms are mutual understandings as to "the way we do things in our team". Try to build positive group norms. E.g., "we always come to the meeting on time", "we never submit code without unit testing first", "No short messaging during meetings", etc.
When a team member is "unreachable" for an extended period of time, the usual excuse given is "oh, I don't check that email account" or "I was using my other phone that day". As a team member, it is your responsibility to keep the team informed about how to reach you.
However, it does not mean that you have to be reachable all the time. It is OK to be unavailable for project work for acceptable reasons as long as you keep your team informed of your unavailability. For example, "I don't check mail during 11pm-8am" seems quite reasonable. You can also "take leave" from the project (e.g., to go on a trip) as long as you inform the team early and your absence is officially incorporated into the project schedule. In addition, try your best to minimize the impact of your absence (e.g., finish your assigned tasks before leaving, rather than postpone them).
While you cannot blame everything on bad team dynamics, it pays to keep your supervisor informed about problems within your team. This could ensure that the whole team does not get penalized for one person's actions and could sometimes count towards extra credit for "good team management".
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.9, Jan 2009, Copyrights: Damith C. Rajapakse |---
Note 1: Documenting decision points
Make sure you document decision points (what were the options considered,
pros and cons of each choice, which was chosen, why, did it turn out to be
the correct decision in the end, etc.), and include them in the final report. This can earn your
team extra credit whether the decision was the correct one or not. That is because
it shows how you took deliberate decisions at various points of the project
rather than do whatever that came to your mind first. Hint: use a tool like
GoogleDocs or Twiki to maintain a project log that everyone one can
collaboratively update.
