]
]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.
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, and 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. See here for an explanation of other team structures 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, 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.
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, and playing this role is a valuable learning experience. Ideally, all students in a team should get this experience. Consider the following mode of operation: After completing each major milestone (i.e., V0.1. V0.2, V0.3), current leader has to step 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. Try to do your best to help the current course of action succeed. 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's 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: The rest of the team seems to be doing fine without you, and they don't seem to mind your lack of contribution. Their attitude seems to be "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 didn't 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 rectify this situation, and make sure you actually do a fair share of the work. If evaluators find out at the end that you were indeed the spare wheel, and you didn't alert the supervisor early enough, you will be penalized. Follow the recommendations for the problem "My team cut me out!".
Problem: When you submitted your part of the work, you found that another team member has done it already, without telling 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: All the other team members are from country X, except you. Most of the team discussions are done in their own language.
Recommendations: This is unacceptable. If the team doesn't respond positively to your request to use English for project discussions, alert the supervisor immediately. If you didn't alert the supervisor early enough, your cannot blame this problem later.
Problem: as the title says
Recommendations: No team member is perfect. You may be weak in programming, but 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. Who knows? in time you might even become as valuable a member as anyone else in the team.
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 turning in an unsatisfactory product.
When a particular team member appears to cause problems within the team, it is important that he/she is made aware that the team is not happy about what's happening. Keeping silent will not solve the problem, and will deprive this person of a chance to amend his/her ways. For all we know, this problematic behavior may be unintentional. 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.
These 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.
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, and acts like the most active member of the team. But that's all he/she does.
Recommendations: Being active is good, as long as it does not stifle/overshadow other team members. What's not 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, the leader should try to sort out the issue with the culprit, and 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 others, and thinks he/she has no time to waste with "amateurs". He/she may do a major chunk of work, but 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 doesn't 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 he/she is engaged in. However, a team cannot afford to 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 university guidelines.
Problem: The leader just sits around and pretends he/she is just a team member, instead of doing the "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's 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. To reduce the risk, use cross-testing, or 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 wants the 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. When the imbalance of workload is noticed by the supervisor, the whole team will get into trouble. Please give correct information about the workload of each team member. You are doing an injustice to all other fellow course-mates if you don't. Besides, having one less contributor puts your team at a great disadvantage.
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 routine tasks assigned to him/her.
Recommendations: This is not a big problem, as long as you don't have
too many such teammates. 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.
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 appears to be willing to do only "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-evaluation, 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.
Given below are some more negative personalities you find in teams, as given in this article.
nitpicker, blocker, recognition-seeker, dominator, bragger, aggressor, playboy
Problem: The team becomes highly polarized over a critical decision.
Recommendations: It's 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's important that everyone try their best to implement the choice made. Also, don't 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: The leader usually gets the same grade as you, and 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, joking, or arguing. No one is willing to break away, for the fear of hurting the team spirit.
Recommendations:
Problem: Several team members form 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 rest of the clique comes to the defense of the clique member, although they have nothing to do with the issue being discussed.
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, you might need the involvement of your supervisor to balance things out. For example, if you think the clique is forcing the team to make a non-optimal decision, 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.
Build a team identity. Take a "funky" team photo (Examples: 1, 2). Brainstorm for a catchy code name for your team/product.
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 "not reachable" 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.8, 3rd Sept 2008, 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, because
it shows how you took deliberate decisions at various points of the project,
rather than whatever that came to your mind first.
