How you define the scope depends on many factors specific to your company. In most tech companies, it’s likely to include product management, design, development, and testing for a product line. It would also include delivery, unless it’s elsewhere in the company; the same goes for operations. If you develop software products for internal purposes, the system is the equivalent in terms of IT and their Business partners. It might also include vendors’ people and contractors.

In most cases, the system comprises multiple teams and individuals. In some cases (usually small companies or internal software development), the system is a single team, but it’s still not only development and testing.

The value delivery system is not the entire company; it is a distinct subset of it. A lot of people may care about the product (or even suffer if it’s poor), but unless they have some influence or authority over it, they are not part of the value delivery system. For example, this is the situation in some companies with respect to marketing and customer support; in others, representatives of these functions have some say over product choices, which makes them part of the system.

It’s often helpful to take the perspective of a stakeholder or someone who benefits from the end product. Unlike you, they don’t care about reporting lines and team structure, people’s specialties, or their processes; to them it’s one organization that “should work.”

If the company makes multiple products, there may be several value delivery systems, which might overlap. Focus on one at a time. Don’t necessarily pick one for which you’re collecting process metrics; the advice in this book works without them.