Transitioning from a Waterfall to a Scrum Environment: Project Teams

Purpose
This article seeks to provide considerations for project management practitioners who seek to transition from waterfall frameworks to agile frameworks.
What is a project team?
A project team can be described as a group of people working towards achieving a project’s deliverables (i.e. a new product or service). These responsibilities can range in nature. A few broad examples include:
# Business case and scope. These team members articulate the need or business justification of a project. In other words, what is the business value in undertaking the project - increased revenue, decreases costs, improved productivity? These members may also be involved in defining the project’s scope (i.e. a description of the new product or service to be created).
# Project planning and reporting. These teams members create and analyze baselines related to costs, schedules, and comparing said baselines against the project’s progress (sometimes called ‘actuals’). They may also analyze and report other assessments of a project’s health, such as quality and risk.
# Working on the project’s deliverables. These team members work directly on achieving the project’s deliverables; the team members in the above examples focus on project support. By way of example, if a project team member was working on the creation of a new video game, he/she would be creating components (or sub-components) of the video game.
Project Teams in a Waterfall Environment
The following characteristics are typical of a project team in a waterfall framework:
# Responsibilities. In a waterfall environment, a project team may work on any of the responsibilities listed above.
# Structure. First, management - the project team is typically led by a project manager. The project manager typically has the authority to apply resources, delegate tasks, and make other day-to-day decisions regarding the project. Second, stakeholder interaction - the project team may or may not interact with the project’s stakeholders, depending on their responsibilities. In some organizations, stakeholder management is directly handled by the project manager. Finally, multiple projects - the project manager and team may work on multiple projects; managing very similar projects closely together may result in improved efficiency.
In summary, the project manager typically has explicit authority to manage the team - how work is performed, progress tracked, etc.
Project Teams in a Scrum Environment
# Responsibilities. The team focuses solely on the project’s deliverables. Responsibilities related to progress tracking and reporting, scope definition, resource allocation, etc., are primarily assigned to the Product Owner. The Scrum Master may assist with some of the aforementioned responsibilities reporting (e.g. burndown charts, release plans, etc.).
# Structure. First, management - the team manages themselves, with the Scrum Master serving as a servant-style leader to remove impediments affecting the team's progress. The best performing, motivated teams tends to be self-managed. Second, work estimation - frequently (but not always), the project team works on complex software and system related endeavors. Given the complexity and specialized knowledge required, the team is often in a better position to decide how to accomplish its work (i.e. task duration, work style, how much work can be committed to at once, etc.). Consequently, the project estimates its work and commits to how much work they can accept in advance. Unlike the Project Manager, the Product Owner will instead focus on articulating, decomposing (i.e. breaking down), and prioritizing the end goal or product. Third, stakeholder interactions - in many waterfall frameworks, customer requirements are verified towards the conclusion of a project. In the SCRUM framework, smaller components are created and frequently demonstrated to the project stakeholders, ensuring the product meets expectations. Lastly, multiple projects -- project teams(including the Product Owner and Scrum Master) will focus on one project, rather than multiple projects. If there are multiple, similar projects, each project has a separate team, Product Owner, and Scrum Master. The program is instead managed by a program-level Scrum Master, Project Team, and Product Owner. This avoids inefficiencies that may be introduced by multitasking and other conflicts (e.g. focus, resources, etc.).
# Training. The entire team (project team, Product Owner, and the Scrum Master) should all be thoroughly trained in their roles before proceeding with the transition; the stakeholders may potentially benefit from training as well, if feasible. Doing this will prevent many issues during the transition’s execution; it will also help the team understand the underlying rationale behind agile methods (i.e. why such methods may be more effective than similar waterfall methods). The team could start by reading The Agile Manifesto to gain a basic understanding of agile frameworks. Scrum workshops (and certifications) are also available from the Scrum Alliance; the Project Management Institute (PMI) similarly offers a certification in agile project management.

Main Menu

See Also

Main Menu