SE361 Team Roles and Responsibility Areas

This document describes various responsibility areas.  Each team member must take responsibility for one or more areas. Roles will last for the length of the term, however you are encouraged to switch roles periodically if everyone in the team is agreeable to it. Please inform the instructor of changes in roles, and also note the change on the Team Roster document.

Note that roles indicate responsibility for ensuring that particular concerns get addressed well, NOT that the person who has the role must do all the activities for the role.  Thus it may happen that the team coordinator participates extensively in testing, while the testing coordinator helps to sort out configuration management problems.  Assigning coordination responsibilities to a particular individual indicates that they must take leadership in ensuring that the objectives in that area are met as well as possible.  The specific activities in each area may be done by any of the members on the team, based on knowledge and ability, allocated tasks and need.  Ultimately, all team members share responsibility for the success project i.e. everyone is empowered to contribute in any area and any way they can.

It is required that all team members participate in development (coding).

Review the list of goals for your role(s) every week, and make sure that they are being met.  If they are not being met, this is an issue that must be brought up and resolved.

Team Leadership & Planning (Team Coordinator)

Teamwork focuses on effective cooperation within the team.  The goals include:

• Participation: Everyone on the team must participate in ensuring the success of the project.  They must be fully involved in team meetings and decision making.  Everyone must have a shared understanding of the goals, the decisions (technical as well as managerial), and the reasoning behind decisions.
• Effective use of resources: Each member of the team should be put in a position where they can contribute effectively to the project e.g. if someone is good with tools, but not strong in Java, they should be given opportunities to contribute based on their strengths.
• Alignment with individual goals: People who have an interest in developing a particular aspect of their skills should be given an opportunity to do so (if possible).  For example, if someone wants to learn more about building GUIs, interface development tasks may be given to them, even if they are not proficient at it.  Note that sometimes there may be conflicts between team needs and individual desires: the team may benefit more from a task being done by somebody who can do it well, but someone else may be more interested in doing the task, even though they are not good at it.  Balancing such considerations is one of the challenges in teamwork. Tasks that “no one wants to do” must be shared fairly among team members.
• Motivation: All team members should be motivated to meet the team goals and produce a really good product.
• Interfacing with the instructor: The instructor should be kept informed of progress and issues.
• Effective meetings: Team meetings should be participatory, orderly, short and effective in decision-making and alignment (i.e. ensuring everyone on the team is on the same page). 
• Issue resolution: Any problems within the team should be identified and resolved.
• Activity identification and sequencing: Identifying all the tasks that must be performed (development tasks, testing, quality tasks, reporting and documentation etc), identifying their dependencies and sequencing i.e. which task should be done when.
• Task allocation: Each activity must have an identified person(s) who is responsible for completing it .  Task allocation must take into account team member capabilities, individual preferences as well as balancing of load.
• Progress tracking: Each week, team members should set themselves targets for what will be completed, and progress against these targets should be tracked, so that it is clear whether the project is on track.  This can help avoid situations where progress is held up because of dependencies on some task that is not yet complete.

Capabilities needed: Work well with people: good communication, interaction and empathy (“understand where each person is coming from”).  Creative problem-solving to resolve tough situations. Meeting facilitation skills. Being systematic and organized.  Strong task focus: “getting things done”.  Preferably previous experience with team development. Planning and coordination skills.  Understanding interests and abilities of different team members and matching them with tasks.

Design and development (Development coordinator)

This role involves serving as the technical “point person” i.e. ensuring that the product has a clear and consistent technical vision and design, and that all technical aspects and issues are being addressed.  Goals include:

• Technology selection: Selecting the right implementation technologies and libraries to use / reuse.
• Design quality: Developing a good design that addresses all the requirements, and results in a product with good quality attributes (performance, reliability, usability, maintainability).
• Design vision: Leveraging ideas from all the team members, but working through them to come up with a single consistent vision of the product and the design.
• Interface specification and interface control: Creating a good modular design with well-defined interfaces, particularly interfaces between modules being developed by different team members.  Managing changes to the interface.
• Implementation problem resolution: Debugging and overcoming other implementation hurdles.

Capabilities needed: Previous experience with designing software to be developed by multiple people.  Good understanding of design approaches and design and implementation issues.  Familiarity with technologies. Willingness to listen to others’ design ideas and synthesize them into a single design concept. Willingness to understand and resolve implementation difficulties.

Requirements Management (Requirements Coordinator) - in teams of four, this role is combined with the Test Coordinator

If you do a great job of building the wrong product, all your effort is wasted.  Hence requirements are critical to product success.  Goals include:

• Understanding the project goals.  The project description document describes the goals, and the Project Concept and Requirements should be checked to make sure that all the goals are met.
• Understanding customer needs.  The instructor serves as the customer.  The Project Concept and Requirements should be checked with the customer, and there should be constant continuing interaction with the customer to check whether the product being built meets all customer needs.
• Understanding the problem domain.  Checking if similar products are already available, and understanding how they work.  Learning more about the problem area in general so that the team can build a more effective solution.
• Identifying and resolving requirements gaps and conflicts: Constantly looking for gaps between the current Project Requirements and what the customer wants or needs.  Identifying contradictions between requirements or “infeasible” requirements (that cannot be met for some reason).
• Documenting the requirements: Creating the requirements document and keeping it updated.
• Managing requirements changes.  Requirements changes may originate in three ways: either customers may change or add new requirements, or there may be errors in the requirements that need fixing, or the development team may come up with ideas for improving the product.  In all cases, the change to requirements must be managed.  When requirements change, the entire development team must be informed, and all development artifacts (designs, code, documentation) must be updated to be consistent with the changed requirement.  Also the customer must be kept informed of the change.  If the development team wants to modify the product requirements, it may only do so with prior consent from the customer, otherwise the changes will be considered to be bugs.  For example, if you wish to add context-sensitive help to your product, but this was not part of the original requirements, you must obtain the consent of the instructor before adding it.  (Yes, this is how it works in industry – unauthorized “improvements” are NOT welcome).
• Ensuring requirements coverage and requirements traceability for design and acceptance tests i.e. that the design and acceptance tests address all of the requirements, and that they do not address features not in the requirements.

Capabilities needed: User-oriented thinking and user focus.  Good interaction skills.  Preferably some knowledge of the problem domain.

Test Management (Test Coordinator) - in teams of four, this role is combined with the Requirements Coordinator

Good test design and effective testing require considerable technical skill and creativity, and have a huge impact on project success.  Goals include:

• Test strategy: Selecting the test strategy, particularly for integration testing.  Identifying module granularity for unit testing.
• Designing acceptance tests: Developing a good acceptance test suite based on the requirements and using it to drive development, with a minimal-but-comprehensive set of test cases.
• Designing unit tests: Developing unit tests with good coverage of each module’s functionality.
• Testing: Performing tests, identifying failures and ensuring the problems are fixed.
• Regression testing: Deciding which tests need to be performed again when changes are made to the implementation.
• Tracking and reporting: Keeping track of which tests were executed, whether they passed or failed, and re-doing tests after bug fixes.

Capabilities needed: Excellent understanding of the requirements and design.  Excellent development understanding (actually test coordination needs this as much or more than development coordination).  Being systematic and organized. High technical creativity.

Configuration Management / Quality Management (Configuration/QA Coordinator)

Configuration management is critical to the success of team efforts with multiple artifacts and releases.  Goals include:

• Managing concurrent activity: If multiple team members try to make changes to the same files concurrently, chaos can result.  Configuration management tools such as SVN and development environments such as Eclipse provide part of the solution, but they must be complemented by procedures that minimize the possibility of unwanted conflicts, while still enabling work to get done most effectively.
• Using versioning for releases and for backup: Artifacts such as documents and code evolve continuously, but it is necessary to create “release” versions for customers (instructors) so that what they see is consistent and does not keep changing.  Versioning is also critical for creating backups, so that if something goes wrong, the team has a recent “good” version to fall back upon.
• Defining build procedures for integration: When several people are working on code simultaneously and constantly making changes, each of them need to compile and test their code together with everyone else’s code – but they want to see “good” versions of other people’s code that does not have compile errors!  Facilitating this requires careful setup of a hierarchy of workspaces and defining build procedures for the team.
• Identifying and selecting tools and other resources to support development: This includes both selecting the basic development tools such as compilers, as well as identifying tools that simplify development such as GUI builders and test generators. 
• Tools expertise: One of the biggest hurdles typically faced in projects is hassles with the development tools: something goes wrong and all hell breaks loose until someone who understands the tools well can fix things.  Time and energy spent in learning how to use the tools properly saves large amounts of effort later on, and at least one person on the team needs to develop expertise on each tool.

Quality management is about ensuring that the best results are obtained for effort put in.  Goals include:

• Processes definition: Ensuring that appropriate processes are used for team meetings, managing concurrent edits to files, managing requirements and design changes, testing and bug fixes etc.
• Process tailoring and improvement: Ensuring that the processes match team needs and are well suited to the project and team characteristics.  Optimizing processes to maximize chances of project success.
• Proactive quality: Creating (or finding and reusing) templates and checklists that save effort and avoid problems.
• Quality procedures: Using reviews / inspections, causal analysis (finding the causes that contribute to a particular problem) and metrics to improve the effectiveness of development and eliminate problems.
• Monitoring: Keeping tabs on all aspects of the project (including people aspects), identifying potential problems and flagging these as issues to be addressed.
• Quality assurance: Proactively checking the quality of artifacts to be delivered: code and documentation releases.
• Customer satisfaction: Interacting with customers to ensure that they are satisfied and that their concerns are addressed.

Capabilities needed: Familiarity with quality procedures (or enthusiasm to learn them).  Ability to step away from the details and look at the big picture. Friendly interaction with all team members.  Willingness to raise unpleasant questions, and ability to get them addressed without antagonizing people.  Strong commitment to quality and project success. Familiarity with tools / willingness to invest large amounts of time in learning them well.  An understanding of the challenges of concurrent development, and the concepts underlying configuration management. An interest in “finding easier ways to get things done”. A “support mentality” – enthusiasm to help other people to work more effectively. Web expertise.