Team-based web/mobile development is challenging. Everyone brings his or her own personal experiences to how software should be built and how projects should be managed. Throw in company-specific processes, different organizational makeups, and a variety of industry methodologies, and software development can get pretty confusing.
It’s not uncommon for teams to take elements from different methodologies (Scrum, TDD, Waterfall, Lean, Kanban, etc.) to build software. When software projects struggle or fail, many blame the methodology or the unorthodox mixing of multiple methodologies. This can be a factor, but the source of issues is more often directly related to critical roles being missed or misunderstood. Success is tied to how well the project team works together, so roles need to be clearly defined and followed throughout the project.
The right processes will vary depending on the structure of the organization. At the end of the day, what matters is that you build a product that is of high value to your users. At AIM Consulting, we understand all the methodologies and adapt an approach that meets the needs of the business. We make sure all the necessary roles are understood and covered, key responsibilities are not overlooked and team members are not spreading themselves too thin. The result is contributing teams, quality software, and project success.
The role of a project manager is to keep the budget, schedule and scope of the project on track and communicated to all stakeholders. Project managers collect status and communicate it with the entire team and external stakeholders. They organize and drive meetings with external stakeholders to ensure dependencies are understood. They ensure the team is hitting their goals and remain on track for project delivery. If anything arises that will impact the budget, schedule or scope, the project manager will work with the team and external stakeholders to ensure the proper adjustments are made (request more budget, schedule slide, decrease scope, work weekends, etc.).
In Scrum methodology, the person who coordinates and facilitates the daily activities of the team is called the scrum master. On many software projects, the project manager performs this role, but though one person may be used for both roles, the role of scrum master is distinctly different from the role of the project manager. By separating the two, there is be a better, unbiased perspective of truly how well a project is doing. This is because the project manager has to deal with external pressures placed on the team, which can impact how the person in this role interacts with the team. By having a role dedicated to the daily interactions of the team, the project manager can focus his/her role of managing the overall project.
On a daily basis, the scrum master ensures the team is working on the correct tasks and has everything they need to complete their work. This includes connecting different resources to talk to each other to solve an issue, bringing the product owner into a meeting to get their opinion, contacting facilities to get a new monitor for a developer, etc. The list goes on, but the key is that they ensure the team is producing.
The scrum master role is tightly coupled with the project manager role to ensure accurate project health and status is known and communicated. The internal team vs. external team emphasis described here is truly the benefit of separating the responsibilities normally assigned to a project manager.
The product owner (sometimes the product manager depending on the structure of the organization) owns the vision and requirements for the project, thus controlling what the team works on. Nothing is worked on unless it is approved or provided by the product owner. The product owner protects the project team from external stakeholders that want their requirements implemented. In turn, the product owner works with the external stakeholders to consolidate or compromise on
requirements to make the determination on which ones make it into the product.
The product owner is responsible for documenting requirements and their priority. This allows the team to know what is being asked of them and what items to work on first. They provide support to the team by answering questions and providing information to help the team move forward.
Much like the project manager role, the analyst role varies wildly depending on the needs of the organization. At the end of the day, the analyst serves as the conduit between the product owner and the dev / QA teams. This can include helping the product owner write requirements to creating specs for the dev / QA teams to work from. The analyst helps the team understand what the product owner is asking for. Conversely, the analyst can help the product owner understand limitations, such as why certain requirements will cost too much to do versus an alternative.
The dev lead is in charge of the dev team and provides direction on the architecture of the project, coding standards and what tasks each developer works on. The dev lead establishes the development processes for the entire team, from development tools to peer code review to how and when code can be checked in. The dev lead needs to coordinate with the scrum master to ensure the team is on the right track. The larger the team, the tighter the coordination needs to be.
The QA lead is in charge of the QA team and provides direction on the activities related to testing the product. The QA lead establishes the processes for the entire team, from testing approach (automated vs. manual, etc.), tools to use, or devices / operating systems to focus on. The QA lead needs to coordinate with the scrum master to ensure the team is working on the correct items. The larger the team, the tighter the coordination needs to be.
The design lead is in charge of the design team and provides direction and vision for the look and feel of the product. The design lead should be in lock step with the product owner when the requirements are created. The design lead needs to coordinate with the scrum master to ensure the team is working on the correct items. The more design artifacts for a project, the tighter the coordination needs to be.
The dev team is the group of people responsible for developing the product. They get their direction from the dev lead on what tasks to work on and how they should be done. They interact and coordinate with all other team members, but their direction should ultimately come from the dev lead.
The QA team is the group of people responsible for testing the product. They get their direction from the QA lead on what tasks to work on and how they should be done. They interact and coordinate with all other team members, but their direction should ultimately come from the QA lead.
The design team is the group of people responsible for providing design direction and design artifacts to the dev team to put into the product. They get their direction from the design lead on what tasks to work on and how they should be done. They commonly interact with the dev lead to ensure designs are followed. They interact and coordinate with all other team members, but their direction should ultimately come from the design lead.
3RD PARTY TEAM
Rarely are projects self-contained, meaning there are no 3rd party dependencies. Whether it’s source data, enterprise architecture, an SDK or internal API, or a team that manages the release of the product, a project team will need to work with people outside of their immediate team. The role of the 3rd Party Team is to provide the tools that the team needs and whatever documentation or support is necessary to correctly build and implement the product. The key for the software team is the communication between them and the 3rd party. This falls into the role description of both the project manager and the scrum master. It is the project manager’s role to ensure the two teams are aligned and it is the scrum master’s role to ensure that the project team has everything they need to do their work.