… you have a product Vision and are creating a Product Backlog in the Value Stream. You would like to have an Autonomous, Self-Organizing Development Team to create value from the Product Backlog .

✥      ✥      ✥

A Development Team cannot operate in a vacuum. But Developers’ attention and skills focus on actual development, not on the necessities of managing development or deciding what to create.

Transforming Product Backlog Items into a product takes skill and dedication. In software development we have treated the people who carry out this work as fungible resources with an infinite capacity to change focus, maintain productivity and learn new products. There are many reasons for this, such as: intra-organizational charging, availability of staff, Developers convinced they can work like this, or lack of effective prioritization on endeavors. The root cause will vary with context, but all have the same result; a changing group of people working on development without context of the product.

Treating development staff as commodities leads to a regular change in staff (see Stable Teams) and when the Developers change the focus of their work regularly there is task switching cost. We know task switching degrades performance and we may control the moment to moment impact of this by having Developers work on a product part time, or for a short project. But the knowledge required to be effective in a product domain takes a long time to learn and for complex products it also takes focus. Switching people and teams of people in and out of products leads to lower effectiveness of staff, as the need to understand the direction and history for a product to be the most effective at creating value.

Product development is a nonlinear and non-deterministic process. We acknowledge this is Scrum by having an emergent product backlog. Feedback from the development of the product influences the emergence of the product backlog. When feedback from development is not available the product can inherit risk for long term viability (technical debt being a prime example of this). Or when the feedback is inconsistent, or the flow value or irregular, due to constant change in the Developers, the product incurs others risks and the process becomes wasteful.

The temptation to create a development group that works like a black box, taking in requirements and spewing out product, can be strong. As not all Developers are interested in product or market analysis, it can be tempting to keep these folks away from this information. There may be excellent financial reasons for making this choice of structure (such as partitioning capital spending). We know that just “throwing requirements over the wall” is a tried and true recipe for failure. Developers need guidance on what to develop and this guidance needs to be more than a specification or wireframes.

Therefore:

Create a team consisting of the Developers (Development Team), a ScrumMaster who facilitates development, and a Product Owner, who guides product direction.

✥      ✥      ✥

Scrum uses two teams: a Development Team, and the Scrum Team. The Development Team is responsible for doing the actual work to build, refine, and extend the product. The Scrum Team encapsulates the Development Team and adds the Product Owner. As a team exists in a larger social context that influences the team creating a Scrum Team that includes the Product Owner creates part of this context. This small change in structure has a significant effect in the development of products when using Scrum.

As the Development Team is small, cross-functional and stable, many of the common problems that come in product development are obviated. This creates the opportunity for the team to become autonomous and self-organizing as well as aligned with the product. Self-organization 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.

A small and interactive Scrum Team creates more opportunities for feedback from the development of the product into the Product Backlog. As the development team has more time with the Product Owner and can develop a stronger working relationship where the development can understand the product direction. The Product Owner will also gain a deeper understanding of the implementation of the product leading to other choices they make to gain ROI.

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. (Anecdote - one major 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.)

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.