In the first two parts of this series, I examined two of the three roles of Scrum-the ScrumMaster and the Product Owner-and how they each interact with the framework's other two roles to generate increased productivity. To conclude this discussion, I will turn to the remaining role: the team. Unlike the previous roles, which have both been individuals, the team is, of course, made up of a group of people. As such, it's unique in that responsibilities are distributed among multiple parties in order to successfully deliver a product increment. Just as the entire Scrum team (i.e. the ScrumMaster, Product Owner, and team) must depend upon one another to complete projects, so, too, the development team's members must trust each other to self-organize their way to success. The development team's tight-knit dynamic builds shared accountability and, with every successful project, confidence in one another that culminates when it transforms into ownership. That degree of collaboration is the single most important ingredient in Scrum's ability to boost productivity.
In Scrum, the team is responsible for completing or burning through work, expressed as product backlog items (PBIs). Where the Product Owner determines vision and negotiates sprint goals and the ScrumMaster enforces the rules of the framework and often acts as the point person for resolving team-based and organizational impediment, the team is tasked with the difficult job of not only getting the work completed, but also figuring out how to do so.
Ideally, teams consist of seven cross-functional members, plus or minus two individuals. Although, recently there have been a few arguments for even smaller teams.
For software projects, a typical team may include a mix of software engineers, business analysts, quality assurance, technical writers and UI designers. What is most important about the team composition is the range of required skills is collectively represented by the team to accomplish whatever tasks the Product Owner may present to them.
Each sprint, after negotiating the PBIs that will be moved into the sprint backlog, the team must determine how it will accomplish the work. In Scrum, this process of the team creating its own plan to complete work is known as "self-organization" and marks a significant departure from traditional project management. It grants teams a great deal of autonomy, but that freedom is accompanied by increased responsibility to meet the goals of the sprint. Thus teams are at liberty to choose how they tackle PBIs, but they must deliver what the Product Owner has asked for, when it is due (POs will inspect what the team has done during the sprint review meetings).
The Team and the ScrumMaster
As discussed in part one, the ScrumMaster's role in relation to the team can be succinctly summarized: He or she usually acts as the point person who tracks impediments that obstruct the team's progress. In addition, he or she ensures that the rules and meetings of Scrum are observed. However, great teams require a great ScrumMaster and the best ones provide much more proactive support for the team than the above description would suggest. The most effective ScrumMasters understand the team is one part of a larger system and, in order to maximize the team's potential for productivity, all of those parts must align. Thus, the ScrumMaster's focus on team impediments and leading the team to follow Scrum is only the tip of the iceberg. Other questions ScrumMasters may want to consider to help their team include:
- How is the Product Owner doing? Is the Product Owner adequately informed about the team's progress and successes, or the impediments and dependencies that obstruct its