User:AgileProjectManagement/Project Teams: Transitioning from Waterfall to a Scrum Environment

Purpose
This article seeks to compare and contrast the roles, structures, and interactions between project teams in a waterfall environment vs. Scrum environments. The purpose of these analysis is to:


 * 1) Serve as a source of information for project management practitioners
 * 2) Provide considerations for those who are considering transitions from the waterfall framework to the Scrum framework.

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:


 * 1) 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).
 * 2) 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.
 * 3) 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:


 * 1) Responsibilities. In a waterfall environment, a project team may work on any of the responsibilities listed above.
 * 2) 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

 * 1) 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.).
 * 2) 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.).

In short, the project team is self-managing in a SCRUM environment where the roles tend to focus responsibilities based on the roles – the project team focuses on the creation of deliverables, vs. Product Owner, who focuses on defining the new product or service and how it relates to each feature.

Suggestions for Teams Transitioning from Waterfall to Scrum

 * 1) Location. Keep the team as closely together as possible; have them all within the same room in such a way that i) they can all hear each other without yelling and ii) they can all see each other. For team members who work outside a primary location, do everything you can to minimize the effect – teleconferencing and facetime technology, cameras by the sprint backlog and burndown chart, etc. It is the experience of SCRUM teams (and their coaches) that co-location encourages collaboration, trust, and consequently, improves productivity. Moreover, make sure the team is far away enough from others outside the team (e.g. operational staff, function mangers, stakeholders, etc.) so that they will be not disturbed or pressured. Distractions cause the team to lose focus, which in turn affects productivity (i.e. velocity – stories completed).
 * 2) Retrospectives. Teams are often reluctant to discuss strengths and weaknesses after a sprint. However, this is a critical opportunity for development and improvement. For example, if the team finds they should’ve been a little more communicative with one another, simply mentioning this during the retrospective will likely address the issue; the team will naturally be more communicative next sprint, especially if the suggestions are posted around the whiteboard and burndown charts; formal changes in processes can be reserved for repeated issues. What’s most important during a retrospective is that the team primarily be the one to identify its performance; the team maintains self-management. However, if the Scrum Master identifies an issue (or if the Product Owner or Scrum Coaches have a suggestion), the Scrum Master may mention it during the retrospective for the team’s consideration.
 * 3) Encourage cross-functionality. Although team members will naturally have areas of specialization, it is important that team members try to learn more about different knowledge areas relevant to the project’s deliverables. Cross-training prevents productivity issues that result from a specific team member being absent. For example, if the team’s primary database administrator is absent, the team may not be able to complete database-related user stories until said team member returns. Cross-training can facilitated in a variety of ways. First, accepting different user stories - suggest that team members work on user stories requiring different knowledge areas. Second, pair programming - pair programing is an XP concept that advocates one person writing so much code, and then another taking over. Although one team member may have more knowledge and expertise regarding a certain subject, the two are expected to view each other as equals. For example, if Jill is a team member that has historically specialized in testing, the Scrum Master could encourage Jill to try working with Tom, who specializes in security. Jill will acquire greater knowledge (and possibly, a mastery) of testing; Tom will do similarly with security. Third, decrease the focus factor during a sprint - if the team and/or Scrum Master feels time needs to be set aside for development, decrease the amount of user stories during a sprint. Although this will temporarily reduce productivity, inform the Product Owner of the expected improvement in long term productivity. Lastly, use lab days - if the team has a few days off before the next sprint, encourage them to research and learn more about topics outside their specialization.
 * 4) Experiment. Scrum provides a framework for agile teams. However, it is not a particularly prescriptive framework. Scrum teams should be encouraged to experiment with different methods, processes, and other tools that enable them to better achieve their objectives. A few examples of things a team might try experimenting. First, sprint lengths - try experimenting with sprint lengths. If the team started with one week iterations, try other lengths and identify what results in optimal performance (while balancing stakeholder needs). One may find that the one week iterations worked best. In that case, nothing prevents the team from returning to one week iterations. In contrast, if the team finds that three week sprints work best, they’ve found a way to improve performance. Note that when experimenting, be sure to allow for several iterations; it will take the team some time to find a new ‘rhythm.’ Second, team size - if you have approximately 30 people assigned to a project – what’s the best way to divide them up? Small teams? Large teams? By specialization? Generally, a few large teams are better than many small teams and it’s best to have some cross-functionality in easy team. However, the SCRUM teams can certainly work together to identify the most optimal, efficient combination. Third, incorporate specific tools from other frameworks - practices found in XP (pair programming, test driven development, etc.) can be successfully applied to SCRUM. Kanban practices can also be implemented into Scrum teams. Similar to sprint lengths, be sure to test the inclusion of new tools/practices by incorporating them into several sprints.
 * 5) 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.