| Software Engineering |
You will need to create a team for your project. The team may be 4-6 students. Larger teams will need to do more coordination. Smaller teams will need to assign more work per person, but larger teams will need spend more time coordinating. The recommended team size is five.
The membership of the team must be clearly defined on your team deliverables website. Include all the information indicated in the team definition template.
It is important that the members of the team have sufficiently compatible schedules that there are at least two times during the week when you can all attend a meeting. Look for a combination of skills and training that will cover all the needs of the project. Use the discussion board, e-mail, and direct conversations to "interview" one another to see if your personalities are compatible. It is also important that the level of effort each team member is willing to put in, and the grade expectation, be about the same. For example, it will not do if one member can put in 10 hrs per week, but another member can only put in 2 hrs per week, or one member is determined to earn an "A" at any cost, but another member makes a habit of doing the minimum necessary to earn a "B".
You may (and perhaps should) exchange roles during the term. If you do change roles, you should document the changes in the team minutes (also known as log), on the team deliverables home page, and let the instructor know of the change if it has affected the location of the team deliverables home page.
The following are examples of some traditions roles for team members that you might use, for a team with five members.
If a team has fewer than five members, some of the above roles will need to be combined, and if it has six, some role may need to be split. A team of 4 students (the minimum) might consist of the following members:
For teams of fewer than four members, further merging of roles, along with some re-distribution of duties, is required.
You should recognize the above model as one of the modifications of a Chief Programmer Team discussed in the class notes on team organization, where the technical leadership and administrative management roles are split.
You may also try the Scrum team model, in which there is one coordinator (called the "ScrumMaster") and the rest of the team members act as equal partners, sharing work equally, each taking on jobs from a shared list called the "sprint backlog". If you choose this model, every team member should take the time to read about how it works. A good starting point is the Scrum Primer. Links to other references can be found in the class notes on SCrum.
If you follow this model, choose the person with the best management skills for the initial Scrum Master. Then plan on rotating at least one other person through this responsibility before the term is over.
You are not required to follow either of the above model. You may develop any team organization that works for you, ranging from a Democratic Team to a Chief Programmer Team. However, you may not work without a model. You must define your team model, and document it in your Team Definition table. If you change your organization during the term, record the changes and reasons for changes in your minutes.
Whatever organization you choose, every team member is responsible for doing a fair share of the work on each project deliverable.
Be careful when if you take on any leadership responsibility. It will look good on your resume that you served in this role but you have to be able to do the job.
On member of each team should be designated for leadership personnel matters, and one should be designated for leadership in technical matters. The explanation below uses the term Project Administrator for the former, and Project Leader for the latter. If you have a Scrum Master, that person may handle both kinds of issues, but even if you decide you like the democratic aspects of the Scrum model, you may be wise to modify it to the extent of designating one person other than the Scrum Master to break ties when you cannot reach team consensus on a technical decision.
The Administrator is responsible for such items such as:
This person needs to be very reliable, and a good mediator.
The Leader is responsible for the following:
Make sure your strongest technical person has this position.
The following protocol assumes a dual-leader team, with one Project Leader and one Project Administrator. If you combine these functions in one person, that person must be careful not to mingle technical and personnel issues when discussing them outside the team.
Project Administrator or ScrumMaster
Only the Project Administrator can come to the professor with personnel complaints. If a team member complains to the professor (even slightly) about a team member or the team in general, the complaining team member will loose points on that specific deliverable. Additionally, if the project administrator was aware of the problem and did not resolve it, he/she will also loose points on that deliverable.
Project Manager or ScrumMaster
Only the Project Administrator can bring problems regarding the technical aspects of team deliverables and decisions of the system to the professor. Technical problems should be worked out by the Project Manager if possible. There are no points removed for bringing a technical question to the professor by the Project Manager.
Team Members
While team members should work through their representative regarding technical questions on team deliverables, any team member may ask questions regarding individual deliverables. Note the difference on the calendar. Meetings between team members and the Project Manager with the professor to discuss technical issues are arranged by the Project Manager. These can be done via conference call, chat sessions, email sessions.
No team member should berate or be disrespectful to other team members. No cursing, using inappropriate words in emails, etc. If you would not say it in the front page of the local newspaper, or if you would not write it in a letter to your grandmother, do not put it in an email. Be Respectful.
Issues of beratement or disrespect should be reported to the Project Administrator with a formal email stating "This is a formal complaint regarding....." Warning, this type of formal complaint does not help get the team to work better together. So be very careful to use them only as a last resort.
If the Project Administrator warns the offending team member an adequate number of times regarding bad behavior and notifies them that a formal complaint has been made against them. However, it the Project Administrator cannot stop the bullying or abuse, he/she should notify the professor. Points will be lost for these offences. Part of your grade is your ability to work as a team.
Your textbook describes a slightly different set of roles, on pages 30-32. In addition, you have the class notes on team organization and on Scrum.
| Adapted by T.P. Baker from original by Dr. Sara Stoecklin. $Id: TeamInstructions.html,v 1.2 2010/09/19 22:29:17 baker Exp baker $ |