Scrum and Other Product Team Practices

Team collaboration is one of the key values of Agile. The Agile Alliance states that: “A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis.”

Teams are multi-skilled, share accountability, and individuals on the team may play multiple roles [Agile Alliance 2015]:

Face-to-face interactions, usually enabled by giving the team its own space, are essential for collaboration. While there are various approaches to Agile, all concur that tight-knit, collaborative teams deliver the highest value outcomes. However, collaboration does not happen just because people are fed pizzas and work in a room together. Google has established that the most significant predictor of team performance is a sense of psychological safety. Research by Anita Woolley and colleagues [Woolley et al. 2015] suggests that three factors driving team performance are:

Other research shows that diverse teams and organizations are more innovative and deliver better results; such teams may tend to focus more on facts (as opposed to groupthink) [Rock 2016]. Certainly, a sense of psychological safety is critical to the success of diverse teams, who may come from different cultures and backgrounds that do not inherently trust each other.

Two current schools of thought with much to say about collaboration are Lean UX and Scrum.

Lean UX is a term coined by author and consultant Jeff Gothelf and Josh Seiden [Gothelf & Seiden 2013], which draws on three major influences:

We briefly discussed Lean Startup in Digital Value, and the history and motivations for Agile software development in Application Delivery. We will look in more depth at product discovery techniques, and design and design thinking subsequently. However, Lean UX has much to say about forming the product team, suggesting (among others) the following principles for forming and sustaining teams:

(Other Lean UX principles such as small batch sizes and visualizing work will be discussed elsewhere; there is significant overlap between Lean UX and other schools of thought covered in this document).

Lean UX is an influential work among digital firms and summarizes modern development practices well, especially for small, team-based organizations with minimal external dependencies. It is a broad and conceptual, principles-based framework open for interpretation in multiple ways. We continue with more “prescriptive” methods and techniques, such as Scrum.

One of the first prescriptive Agile methodologies you are likely to encounter as a practitioner is Scrum. There are many books, classes, and websites where you can learn more about this framework; Sims & Johnson 2012 is a good brief introduction, and Rubin 2012 is well suited for more in-depth study.

Scrum is appropriate to this Competency Area, as it is product-focused. It calls for the roles of:

and avoids further elaboration of roles.

The Scrum product owner is responsible for holding the product vision and seeing that the team executes the highest value work. As such, the potential features of the product are maintained in a “backlog” that can be re-prioritized as necessary (rather than a large, fixed-scope project). The product owner also defines acceptance criteria for the backlog items. The Scrum master, on the other hand, acts as a team coach, “guiding the team to ever-higher levels of cohesiveness, self-organization, and performance” [Sims & Johnson 2012]. As Roman Pichler notes: “The product owner and Scrum master roles complement each other: The product owner is primarily responsible for the “what” – creating the right product. The Scrum master is primarily responsible for the “how” – using Scrum the right way” [Pichler 2010].

Scrum uses specific practices and artifacts such as sprints, standups, reviews, the above-mentioned concept of backlog, burndown charts, and so forth. We will discuss some of these further in [Work Management] and [Coordination and Process ] along with Kanban, another popular approach for executing work.

In Scrum, there are three roles:

There are seven activities:

There are a number of artifacts:

Scrum is well grounded in various theories (process control, human factors), although Scrum team members do not need to understand theory to succeed with it. Like Lean UX, Scrum emphasizes high-bandwidth collaboration, dedicated multi-skilled teams, a product focus, and so forth.

The concept of having an empowered product owner readily available to the team is attractive, especially for Digital Practitioners who may have worked on teams where the direction was unclear. Roman Pichler identifies a number of common mistakes, however, that diminish the value of this approach [Pichler 2010]:

Scrum and Shu-Ha-Ri

In the Japanese martial art of aikido, there is the concept of shu-ha-ri, a form of learning progression.

Scrum at its most prescriptive can be seen as a shu-level practice; it gives detailed guidance that has been shown to work; see Fowler 2014a and Cockburn 2006.

Marty Cagan suggests that the product team has three primary concerns, requiring three critical roles [Cagan 2018]:

Jeff Patton represents these concepts as a Venn diagram (see The Three Views of the Product Team, similar to Patton 2014).

Finally, a word on the product manager. Scrum is prescriptive around the product owner role, but does not identify a role for product manager. This can lead to two people performing product management: a marketing-aligned “manager” responsible for high-level requirements, with the Scrum “product owner” attempting to translate them for the team. Marty Cagan warns against this approach, recommending instead that the product manager and owner be the same person, separate from marketing (Cagan 2018).

In a subsequent section, we will consider the challenge of product discovery – at a product level, what practices do we follow to generate the creative insights that will result in customer value?

Evidence of Notability

Product team structure and practices are widely debated and discussed in the industry, particularly in the Agile community. Notable conferences include Agile Alliance and Global Scrum Gathering. Many books are published on Scrum and related product team organization topics; e.g., Rubin 2012, Gothelf & Seiden 2013, Sutherland & Sutherland 2014.

Limitations

Product team structure and practices are only relevant when there is a concept of product. Some digital work may be framed as projects, where structures are temporary and objectives are more constrained.

Related Topics