… 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 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 producing complex products where the exact end result of the product is not known when product development has begun.
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, lessons are still learned through developing a new product. What is learned through this process is kept locally, within each department, and what may finally be learned from the customer will need to work its way through the process again to become part of the product. 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. 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 being 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, each department is 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 organization, this is no difference to the non-outsourced state. But lessons that may come from the customer are not relevant to this department as their customer is organization, so there is only a minor requirement 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 may know what is actually going on. For the development of a new product it may be that 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 significantly different from 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 the product. We need to restructure the organization to reflect this customer understanding.
Development of new products requires a significant amount of learning and experimentation. Lessons learned need to come from the product rather than a plan and need to be integrated across the product development process. This may result in local functions working sub-optimally as this leads to greater optimization across the entire product development process. To achieve this boundaries must be removed between departments and between the organization and the customer. As lessons are integrated there will be new ideas for the product and there will need to rapid changes made, this requires processes of managing change where change is considered the norm rather than the exception. This requires small organizations where everyone knows what is happening, that can embrace change, work across specializations, regularly deliver value and are, for want of another term: agile.
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 to 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 (PO) to realize his or her vision to achieve value, and in many contexts the PO will work within an enterprise to create the Scrum Team as a small, autonomous enterprise within the larger entity. The PO 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. 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 to go forward. Each Scrum Team runs like a small enterprise, each as an Autonomous Team. As such, 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 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 gain ROI or other value.
Anecdote: one major telephone company (telco) had outsourced development to a large supplier — black box style. When the telco needed change made to system that would save the company millions of dollars per day, their supplier demonstrated a complete lack of alignment with a lackluster turnaround time of 10 months. This complete disconnect between ROI opportunity and development is what the Scrum Team is designed to avoid.
Because the Development Team is small, cross-functional, and stable, many of the common problems that come in product development can be avoided. This creates the opportunity for the team to become autonomous and self-organizing as well as aligned with the product. Self-Organizing Teams form with local interaction, the Scrum Team creates context for these local interactions helping to align the goals of the team with the direction of the product.
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; see 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, and let the team manage the Development membership over time according to Stable Teams. Scrum Teams within a common product development work on the same cadence (Organizational Sprint Pulse), and coordinate with each other daily 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 a development partnership, 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.