Old Scrum Team

A team (producers and supporters) working closely together to achieve a vision and a guard to protect the team.

… as a Product Owner you have a Vision of a product for your customers. You have started to record the ideas your customers are going to love in your Product Backlog in the Value Stream, and you need to start to make these ideas a reality. You don’t know how to make the product or whether the ideas are correct, what you do know is there will be new ideas as you learn more.

✥ ✥ ✥

The industrial organization is, at best, inefficient at developing complex products where the exact end result of the product is not known at the outset of product development.

Division of labor has been essential to the development of civilization. The efficiency and proficiency of specialists has been a boon to the modern world. The division of labor was instantiated with a great rigor on the 20th century production line with individual stations and people producing or assembling specific components. As organizations grew these divisions became a broad organizational structure with specialist roles (such as sales, production, finance) grouped together in departments. To create a new product in an organization with this divided structure requires coordination across many departments, and may even require a specialist department to manage this coordination. As this coordination can be extremely expensive and time consuming, product development becomes a one-way, one-time push through the organization from idea to customer.

Though the process may be one-way (from organisation to market), the team still learns lessons by developing a product. As development progresses, each department is likely to discover slightly different opportunities to adjust both the product and process, and is likely to react locally in the interest of timeliness. It will only be at a post-mortem that these discoveries may be shared with other departments. Any attempt to turn these local insights into more timely global decisions will add administrative overhead to link together ideas across the institutional and political department boundaries, this may possibly create a new department in the organisation responsible for finding and sharing these insights. Usually, the adjustments and insights remain local, since departments don’t plan outside the boundaries of their responsibility or even realize that a given insight might have more global impact than is under their control.

Local learning can become local optimization, where a group of specialists develop practices and processes that optimize their work. Specialization, local practices and processes can all be sources of efficiency in an organization, but can also create problems at the boundary of the group. To ensure departments can adhere to their internal best practices boundary agreements are developed that become, in essence, contracts to work with the department (e.g. service requests). The contract will specify the nature and detail of the work requests that can be made for the group and expected durations for responses to requests. Anyone needing the group’s specialization will need to use these contracts. This can add significant burden to the product development process which, despite creating greater efficiency for the local department, will slow the development of the product. Again there may need to be additional groups within the organization to manage these boundary contracts, to negotiate exceptions or ensure all parties understand what is required, to make sure the department meets their obligations of these contracts.

Where there are strongly defined departments with well-defined interface contracts the organization may be conceptualized mechanistically, with each department a cog in the machine. Working with this idea can lead to the conclusion that any piece of the machine that is not running efficiently may be replaced with an equally well-defined alternative. Here we may decide to outsource any department and maintain the extant interface. Any lessons learned whilst making a product are now within this external, outsourced department, this is not different to the non-outsourced state. But lessons that may come from the customer are not relevant to this outsourced department because their customer is the organization, so there is little need to integrate anything from the final customer into their work practices.

The organizational machine can become extremely complex with many departments and many products. Within this organization no one can know what is actually going on. When a new product is being developed no one knows what the product looks like but they do know the color of a traffic light image on a report or a revenue number on a spreadsheet. Abstracted information can be extremely valuable in making decisions but a point on a timeline is not a product in your customer’s hand, and only in the latter case do we really know about the product.

No matter how the organization is structured or thought of the customer will only see what they value; the product. We need to restructure the organization to reflect this customer understanding.

New products create a new world for their customers and because you cannot know in advance what this new world will be like you must focus on learning and experimentation as you develop your products. Lessons learned need to come from the product the customers are using rather than from a plan you are following, and must be integrated across the product development process. This may result in sub-optimal local functions though with greater optimization across the entire product development process. Boundaries must be removed between departments and between the organization and the customer. As the team integrates new lessons there will be new product ideas. Change will proceed quickly (and must be allowed to proceed quickly). Change will be the norm rather than the exception. This requires small organizations where everyone knows what is happening: organizations that can embrace change, work across specializations, regularly deliver value and are, for want of another term: agile.

Therefore:

Form a team that has the people who can make the product (Development Team), a Product Owner who guides product direction and a ScrumMaster who facilitates development.

A Development Team has the skill and knowledge to implement products. A Product Owner is the manifestation of the Business within the Scrum Team (connecting it with the customer). A ScrumMaster has the skill and knowledge to coach a Scrum Team, help it continuously improve its development process, and address Impediments.

Usually the Scrum Team is brought into existence by a Product Owner to realize his or her vision to achieve value, and in many contexts the Product Owner will work within an enterprise to create the Scrum Team as a small, autonomous enterprise within the larger entity. The Product Owner will take the role to lead the team in the direction of the Vision. The team adds a small number of Developers that may grow over time but never beyond a Small Team of no more than about seven Developers in any Development Team. The Developers have their own identity as a Development Team that manages itself to its forecasts and commitments. The Product Owner and Developers together make sure the ScrumMaster position is filled; the ScrumMaster takes ownership of the process and supports the team in ongoing improvement.

The Scrum Team is more than a wrapper for including the Product Owner in a team. The Scrum Team is a small business that can work within the context of the organization and make independent decisions to respond to the customer. This change in structure has a significant effect in the development of products when using Scrum.

✥ ✥ ✥

The Scrum Team provides an organizational home for the Product Owner's Vision. Each Scrum Team runs like a small enterprise, as an Autonomous Team. Each team comes together around shared values and is conscious of, and may even articulate, its Norms of Conduct.

A small and interactive Scrum Team creates opportunities for feedback from the development of the product (as a Regular Product Increment) into the Product Backlog. Because the Development Team spends a lot of time with the Product Owner — building a strong working relationship — the Development Team can come to understand the product direction well. The Product Owner will also gain a deeper understanding of the implementation of the product leading to other choices they make to increase ROI or other value.

The Scrum Team creates a structure that supports alignment for the team around the product direction and goals. The team meets regularly to attend to fixed work such as periodic review and planning (Fixed Work), and other central events like Sprint Planning. Teams have a purpose and without the explicit link to the product direction via the Scrum Team the purpose of the team can become fractured, this may be where functional subgroups have their own purpose. The climate for product development can also be established via the Scrum Team. Whether a product needs to be highly secure, or delivered very quickly, or extremely robust is established via the desired market for the product and connecting the Development Team with the Product Owner allows for the appropriate climate to foster. Multiple Scrum Teams align informally as needed, and more formally through the over-arching MetaScrum.

True teams are almost always Collocated Teams. Size the team according to Small Teams, ensure that it is cross-functional and let the team manage the Development Team membership over time according to Stable Teams. This creates the opportunity for the team to become autonomous and self-organizing as well as aligned with the product.

Scrum Teams within a common product development work on the same cadence (Organizational Sprint Pulse, and coordinate freely with each other as required, with a daily opportunity for formal coordination in the Scrum of Scrums, as well as once each Sprint in the Sprint Review and Sprint Retrospective. Great teams work in a rhythm of alternating focus on process improvement and production (Kaizen Pulse).

Emergency situations may cause the team to take exceptional action to break cadence; see Emergency Procedure.

For outsourcing, or other co-development program, consider using Development Partnership to staff the Scrum Team roles, with particular attentiveness to keeping the Product Owner close to the business drivers.

The Scrum Team concept was evolved from the organization of the Toyota Production System work cell, which normally comprises workers and a Chief Engineer. Jeff Sutherland split the Chief Engineer role in two, with the business focus going to the Product Owner and the process focus to the ScrumMaster.

Picture from: Dirk Hansen, https://www.flickr.com/photos/dirkhansen/3235465927/ (license: CC BY 2.0).