Distributed Software Development Teams: Who is Who
Imagine these situations:
Three developers talking about the difficult bug that one of them had spent most of the night fixing. Nothing wrong with that. Just some colleagues talking informally about their work.
The Product Manager meets the User Experience (UX) Lead to decide on the priorities for the next release. Again, perfectly appropriate. Part of the job of the Product Manager is to establish release priorities. Meeting with each engineering group is one of the ways to get this done.
A Sales Account Manager asks a developer to make a change in the next release on a customer demand. Oops. We just crossed a line here. Of course a client-side Account Manager represents his customer interests. However, turning to a line-level engineer is an inefficient way to handle this situation.
The client calls a developer at the vendor firm to ask how a particular feature in the application works. The line just got crossed again. The client should have a primary contact at the vendor firm. Thus a Product Advocate or Project Manager can field this type of question and provide an answer in the most productive way possible.
These examples point clearly to the need for defining communication paths within project teams. But how can you define them in a way that encourages a helpful informal atmosphere and also ensures formal communication the project needs to move forward?
Defining communication – why bother?
Distributed team management combines various approaches. At one extreme you could view a distributed project team as a network with potential connections connecting each team member with all other members. But if everyone could always talk to everyone else, the team would take a long time to achieve its goals. At the other end of the spectrum you could have a tightly-controlled communication that defines exactly who can speak to whom. This approach allows for no flexibility in the team communication system and is overly restrictive.
The key to the most successful distributed team relationship lies somewhere in the middle. What is that middle? Before answering the question, let’s take a look at the difference between formal and informal communication. At Waverley we think of formal communication as any communication that causes changing work priorities, goals, influences productivity. Everything else is informal. So formal communication includes events like team meetings, client emails and design reviews. It also includes non-essential and lengthy client calls to engineers.
The solution is to define communication paths. The task is not to deprive the team of informal communication, but to create a healthy balance, get the most of both team communication styles, formal and informal.
The communication paths in distributed teams are controllable, even for team members in remote locations, if everyone on the team understands and plays by the basic rules. Early definition of communication paths will help to avoid problems. As the project evolves, communication paths can evolve with it.
So how does a team go about defining communication paths? It starts by defining member roles and responsibilities.
Standard roles
Every distributed team will have certain project roles and these roles tend to be the same from project to project. In small projects, several roles may be handled by a single person. Lacking an industry-standard lexicon we propose the following list:
1) Sponsor or Client
The individual paying for the project (IT executive, manager, entrepreneur). The Sponsor is the final decision-maker but tends to be hands-off, relying on the Program Manager to flag issues.
2) Product Advocate
May be filled by one person or several people. Responsible for ensuring that requirements and functional specifications are generated and that the Sponsor is happy with progress and results.
3) Program Manager
The main coordinator of the project. Status reports, risk analyses, planning, action items and regular meetings are all handled by him/her. Also the “keeper” of task priorities and schedule.
4) Project Manager
Each site must have one. Coordinates schedules, reporting and status for the groups at his/her site and manages the site’s deliverables. On smaller projects, the Program Manager fills this role.
5) UX, Development, QA, and Technical Writing Managers
Manage the personnel in his/her skill set (whether design, development, writing, etc) and are involved in issue resolution on the project as needed. May also function as skill set Leads.
6) System Architect
Responsible for the software architecture and design, and for how the software fits into a larger infrastructure. Also involved in technology stack choices, approaches to system interfaces, data flow and database design.
7) UX, Development, QA, and Technical Writing Leads
Manage the workload and direction of their skill set on a daily basis. May also function as the skill set Managers. On smaller projects the Development Lead is also the System Architect.
8) UX Designer, Developer, Quality Engineer, Technical Writer
Line-level roles that actually design and create the product. UX Designers write specifications, draw wireframes and define visual elements. Developers write code and resolve bugs, Quality Engineers test code and flag bugs, and Technical Writers create written documentation for the product.
Supporting roles
In addition to the roles listed above, some projects will benefit from (or even require) input from Business Analysts, Subject Matter Experts (SME), and Technical Experts as well as representatives of the areas (business, organizational or application-specific) that will use or have an interest in the end product. Individuals playing these “supporting roles” are typically called in when their expertise or approval is required for the project to progress.
Role-to-role communication: paths and responsibilities
Now that we have our cast of players let’s describe the play. Recalling the old adage “All roads lead to Rome” we propose “All paths go through the Program Manager.” By this we mean that any formal communication should include the Program Manager, whose responsibility is to synthesize and distribute all important information to all project team Leads, as well as to the Sponsor and supporting roles, as appropriate.
Specifically, in formal communication, here’s who should (and shouldn’t) be approaching whom:
1) Sponsor or Client
Communicates primarily with the Program Manager and Product Advocate. May be present on team meetings and status calls, and may request status updates besides regular calls. The Sponsor should not communicate with anyone else on the team without the involvement of the Program Manager or Product Advocate. In most cases such direct communication between line-level or even Lead contributors and Sponsors results in unintended consequences and lost time.
2) Product Advocate
Communicates with the Sponsor, Program Manager, Project Manager and supporting roles like Business Analysts or SMEs. Requests for information or change of orders for the larger team from the Product Advocate should be passed through the Program Manager (or at least CC the PM).
3) Program Manager
The primary contact for the entire team, delivering regular status updates, risk assessments, etc. The Program Manager consolidates and directs communication within the team and should be included in all inter-group communications, both within a single site and across sites. The Program Manager tracks action items, escalates issues for resolution, and ensures that communications involve all needed parties.
4) Project Manager
The primary contact for a specific site (which on smaller projects may be the only site, in which case the Program and Project Manager are the same person). Tracks status and issues within his/her site and forwards these to the Program Manager. Alerts the Program Manager to cross-site issues and alerts the skill set Managers to any personnel issues within his/her site.
5) UX, Development, QA, and Technical Writing Managers
Make staffing decisions regarding who from his/her skill set is on the project team, taking into account the workload, skills, and budget. Managers may change project personnel according to project needs, notifying the appropriate Project Manager who informs the Program Manager. Skill set Managers also help to resolve any personnel issues within their site’s project team.
6) System Architect
Communicates with the Sponsor, the Program Manager, the UX and Development Leads and the Product Advocate. Guides the development team in resolving technical issues as they arise. All communication to and from the System Architect should CC the Program Manager.
7) UX, Development, QA, and Technical Writing Leads
Manage communication within their own team, reporting personnel issues to the skill set Manager and team Project Manager. The Leads communicate work status and schedules to their site’s Project Manager. Communication between Leads across sites or with other Leads should include each site’s Project Manager and the Program Manager. UX Leads often communicate directly with the Product Advocate and supporting roles (Business Analyst, SME) but here again they should include the Program Manager in their communications.
8) UX Designer, Developer, Quality Engineer, Technical Writer
These line-level roles communicate primarily within their own team. Communications with other teams and/or skill sets typically involves the Leads (for questions of larger importance), although informal communication like casual questions or confirmation can flow directly between teams without the involvement of a Lead.
9) Subject Matter Experts (SME), Business Analyst and other supporting roles
Communicate primarily with each other and with the Product Advocate and skill set Leads, especially the UX Lead, copying the Program Manager. It’s then the Program Manager’s responsibility to involve the Sponsor or System Architect when and where appropriate.
Meetings
Meetings provide a crucial means and mode for distributed software development teams, besides “role-to-role”, for receiving and disseminating the information in a project team. Project status meetings, for example, often bring many members of a project team together. These meetings, whether face-to-face or using VoIP services such as Skype or Sococo, provide opportunities for reviewing requirements, UX designs, code, bugs, and so on.
The dynamics of face-to-face encounters are also crucial for maintaining efficient working relationships, especially for geographically dispersed teams.
Example 1: Small Project Team
Small projects usually consist of a few developers with one or two UX designers and QA staff as optional. Typically, the Project Manager (who doubles as the Program Manager) and Lead Developer handle all communication with other interested parties. In small projects especially the participation of the Sponsor is crucial to success.
Core Team:
- Sponsor
- Project Manager
- Lead Developer
- Developer(s)
- Lead QA
Optional adds:
- UX Designer(s)
- Additional QEs (Quality Engineers)
Example 2: Mid-Size Project Team
Mid-size software engineering projects often engage a couple of UX designers (one of whom also functions as a Product Advocate) as well as a System Architect, a larger group of developers and at least one Quality Engineer. Often some supporting roles are involved, e.g. Business Analyst, SME or any other expert. Mid-size projects are usually broader in scope and cost and interface heavily with multiple functions in the Sponsor’s organization.
Core Team:
- Sponsor
- Project Manager
- System Architect
- Lead UX Designer/Product Advocate
- UX Designer(s)
- Lead Developer and Developer(s)
- Lead QA and QE(s)
Optional adds:
- Business Analyst
- SME/Technical Expert
- IT staff from Sponsor’s organization
Example 3: Large Project Team
Large projects demonstrate a distinct separation of Architect, Lead and line-level roles in each skill set and engage development teams of 20 or more and QA teams of five or more, often working across multiple geographic locations with multiple Project Managers reporting to one Program Manager. Similarly to mid-sized projects, large ones also engage some supporting specialists such as Business Analysts, SMEs and other experts. In large projects the Sponsor as an individual rarely takes part in detailed decisions, making the roles of Product Advocate and Program Manager particularly significant.
Core Team:
- Sponsor
- Program Manager
- Product Advocate
- Project Manager(s)
- System Architect
- Business Analyst
- Lead UXs and UX Designers
- Lead Developers and Developers
- Lead QAs and QEs
- IT staff from Sponsor’s organization
Optional adds:
- SME/Technical Expert(s)
- Application-specific Expert(s)
- Technical Writer(s)
Conclusions
In distributed software development teams the communication plan is critical. A clear understanding of team member roles and responsibilities as well as the information flows amongst them helps to ensure that all team members have the data they need to get their work done and are sufficiently informed about the project status, direction, issues and problems.
Within these communication paths there are key figures or “directors”on the project, primarily the Program and Project Managers, who ensure that the right team members are involved in or apprised of any important news or initiative.
The communication paths are not at all intended to restrict the information exchange. They may prevent Sponsor or any other client-side executive from approaching individual team members, but it will only increase the distributed team efficiency in general and in particular. These paths are proposed to direct information flows in such a way as to ensure that every team member is fully informed and that all team members make a maximum effort pursuing the same goal: the project and product success.
