… as a Product Owner you have a Vision or 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 organisation 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 civilisation. The efficiency and proficiency of specialists has been a boon to the modern world. The division of labor was instantiated with a great rigour on the 20th century production line with individual stations and people producing or assembling specific components. As organisations grew these divisions became a broad organisational structure with specialist roles (such as sales, production, finance) grouped together in departments. To create a new product in an organisation 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 organisation 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 the 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 optimisation, where a group of specialists develop practices and processes that optimise their work. Specialisation, local practices and processes can all be sources of efficiency in an organisation, 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 specialisation 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 organisation 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 organisation may be conceptualised 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 define 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 organisation, 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 organisation, so there is a only a minor requirement to integrate anything from the final customer into their work practices.
The organisational machine can become extremely complex with many departments and many products. Within this organisation 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 colour 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 the a dot 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 organisation is structured or thought of the customer will only see the product. We need to restructure the organisation 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 optimisation across the entire product development process. To achieve this boundaries must be removed between departments and between the organisation 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 organisations where everyone knows what is happening, that can embrace change, work across specialisations, 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 realise 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 which 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 which 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 organisation 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.
✥ ✥ ✥
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 when implemented their supplier demonstrated a complete lack of alignment by offering a fast turnaround of the change; 10 months. This complete disconnection 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-organising as well as aligned with the product. Self-organisation occurs 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. Teams have a purpose and without the explicit link to the product direction via the Scrum Team the 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.
Size the team according to Small Teams, and let the team manage the Development membership over time according to Stable Teams. Enhance development flexibility and locality of decision-making with Cross-Functional Teams. These additional patterns make it possible for each Scrum Team to run almost like a small enterprise, each as an Autonomous Team.
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 split the Chief Engineer role in two, with the business focus going to the Product Owner and the process focus to the ScrumMaster.