PRODUCT-LEVEL SCRUM

{productize your organization}

PRODUCT-LEVEL SCRUM IS ...

An approach to creating product-centric organizations that maximize customer-centricity, product thinking, engineering excellence, and wide inter-functional collaboration. collaboration.

Helps to manage software & hardware product development (unlike Scrum, which aims to be generic). It contains specific recommendations for shaping and running a product development organization.

Not suited for managing individuals, individual teams, or projects, but helps to institutionalize product thinking and apply modern product development practices.

A structural product-centric approach where the product teams and business stakeholders focus on creating customer impact and getting better at it over time.

A way to make multiple teams collaborate in an intelligent way without too many extra processes, unnecessary roles, and bureaucracy.

A set of modern patterns, practices, and examples from the industry that help create an organization that displays a high level of business agility, product centricity, and resilience (B2-B3 archetypes as per Org Topologies).

WHY
PRODUCT-LEVEL SCRUM?

... had the Scrum Guides been more explicit on its scalability beyond a single team, been more focused on product development, and avoided calling all team members 'developers' (more clarity!).

... had LeSS been more welcoming to management and more empathetic for intermediate states of transformations.

... had SAFe been removing the unnecessary complexity by using Lean and Agile principles and promoting real change instead of adding extra management layers and processes.

STRUCTURAL CHANGES AS PRE-REQUISITE FOR CULTURAL CHANGES

Step 0: Broaden value definition (define value with customers' eyes)

Step 1: Enrich teams with customers (more empathy & learning)

Step 2: Upgrade management (must practice Go & See)

Step 3: Elevate Scrum (inspect & adapt at a holistic level)

EXPECTED CULTURAL CHANGES IN ORGANIZATIONS APPLYING PRODUCT-LEVEL SCRUM

Organized in business value areas where groups of product teams work together.
Those teams share business goals, stakeholders, and customers and join forces to deliver value.
Most of those teams are end-to-end capable & customer-oriented, and others are serving.
The teams know the customers and business stakeholders and engage with them.
Everyone talks and behaves like a product person.
The teams measure what they do and act on it.
Technical excellence is constantly being worked on.
People are proactive, collaborate and teach each other.
People manage work and experiment a lot; management provides structure and facilitates this.
There are problems and challenges, but people are fulfilled because they see the bigger picture.

SIMILARITIES WITH AND DEVIATIONS FROM SCRUM

Product-Level Scrum uses the ideas of Scrum applied to the product level. So, any Scrum practitioner shall be able to recognize these Scrum elements:

Product Backlog
There is no Scrum without a Product Backlog and its ordered items. In Product-Level Scrum, the work is defined as business goals and product changes that represent the product strategy of the business value area. During the Product Backlog Refinement process, these goals and changes are hypothesized, detailed, and split into smaller chunks of work - atomic product changes, ideally in the form of product experiments with expected outcomes and impact metrics. Recognizing the nature of the product work, Product-Level Scrum defines the Product Backlog as this entire information space: goals, product changes, hypotheses, experiments, and metrics. On a very practical level, the entire product board used by all the teams and managers is the Product Backlog, where the ordered business goals are the source of the priorities and focus.
Product Increment
Product-Level Scrum promotes continuous delivery and other modern engineering practices. They speed up and cheapen development, turning the organization into a hypothesis-testing machine and increasing business agility. Thus, a Product Increment in Product-Level Scrum is the sum of all the product changes done within the product-level Sprint plus all the learning acquired by the organization (business, product, and technical). The Definition of Done is shared by all the product teams within the business value area and represents the current level of abilities, processes, and quality control that the teams agree to comply with. Working towards expanding the Definition of Done beyond what is currently possible is essential for improving the organizational capabilities of the business value area.
Sprint
In Product-Level Scrum, Sprint is a learning cadence at the level of a business value area. Sprints in Product-Level Scrum are not the time-boxes to align software integration and feature releases, as the product teams learn to deliver continuously. Sprints in Product-Level Scrum are containers of regular events run at the business value area level. Recognizing the nature of product development as a complex activity with high variability, Sprints in Product-Level Scrum don't assume a fixed scope of work. Instead, the scope of a Sprint is a set of selected business goals that the product teams commit to focusing on within a Sprint.
Sprint Planning, Sprint Review and Sprint Retrospective
Because a Sprint in Product-Level Scrum is run at the business value area level, these three key events of Scrum are also run at that level by the product teams in collaboration with the business value area management, business stakeholders, and customers (whenever possible). These events are regular and open - they welcome guests, experts, and contributors. Team-level improvement mechanisms (e.g. with regular team-level retrospectives) are out of the scope of Product-Level Scrum for the reason of giving more space for the product teams to self-manage. Product-Level Scrum appreciates the search for practices at the team level that work within a given context.
Sprint Planning
As a result of Sprint Planning at the business value area level, there should be a clear agreement 1) between the product teams and the management on the scope of selected goals; and 2) among the product teams on how they divide and share the work.
Product Backlog Refinement
Refinements of the goals must be a regular process run at the level of the business value area. It must start with all the product teams and management representatives involved. Such a process will ensure transparency of the goals at the level of the business value area, welcome adjustments and improvements, and therefore increase overall organizational adaptability. The product teams decide how to go about refining them - when to merge and work together and when to diverge and work in subgroups. During the refinement workshops, where selected goals will be sliced to form concrete work items, team members collaborate and learn from domain experts, customers, and end-users.
Daily Scrum and Sprint Plans
Team-level events and artifacts (such as Daily Scrums and Sprint Plans) are neither prescribed nor discouraged by the Product-Level Scrum. If the product teams see the value in running these events and using those artifacts, they are free to do so. They might as well look for other practices that work better in their context. Mob programming or similar modern practices for intensifying collaboration shall be explored, as they might minimize the need for team-level events and artifacts. For inter-team and cross-team collaboration, decentralized and lightweight events and artifacts must be preferred to manager-led heavyweight ones. Despite the ways this is handled, at any given moment, there must be clarity: 1) on which selected business goals the teams are working on and 2) which teams are currently working on what.
Product Owner
Product-Level Scrum puts focus on the outcomes of the role of Product Owner in Scrum, not on the implementation of this role. Having a clear product strategy with transparent, clear, prioritized business goals is sufficient to guide product development. Defining, prioritizing, and communicating these goals is the primary function of management, whether this is done by a single individual (e.g. business stakeholder or a senior product manager) or collectively by the management and the product teams. This depends on the maturity of the organization and the context. Collective product ownership, where everyone contributes to the business and product success, shall be the objective of productization. Although a specific product manager can fulfill the accountability of a Product Owner, being a product manager doesn't automatically make you a Product Owner (i.e. the one deciding on the goals and defining the strategy). Therefore, these terms are separated here. Product-Level Scrum recognizes and appreciates the power of product managers in shaping the product along its full lifecycle. If such a position exists within a business value area, product managers can decide to work as a dedicated group or, preferably, inside the product teams. The fluidity in relationships between the product managers and the product teams is recommended. Modern approaches like Lean UX shall be explored and exploited to put more focus on whole-team interactions and learning rather than deliverables and waiting.
Scrum Master
Product-Level Scrum recognized the value of coaching & mentoring product teams, managers, and stakeholders. To avoid local optimizations and narrow focus, this function must be fulfilled holistically for the entire business value area. Whether this is done by a specific role (e.g. scrum masters, flow masters, agile coaches) or by the managers is up to the organization to decide.
Scrum Team
Over the years, Scrum has moved from a concept of a Development Team to a Scrum Team with Developers. Although such evolution is understood, these ideas become somewhat vague at scale (beyond a single team), and surprisingly, not everyone is happy to be called a developer. To avoid any related confusion, Product-Level Scrum introduces the concept of a business value area as a home for everyone involved. It also serves as a container for all the information and its exchange. A business value area can be seen as a scaled Scrum Team that also includes management, business stakeholders, and involved customers. A business value area is a home ground for a number of teams that work on the goals. In Product-Level Scrum, such teams are called product teams because this is what they do - together, they build a product. People within the product teams can be referred to as team members, product team members, or even product developers if they feel like it. Beyond the product teams, Product-Level Scrum recognizes a potential organizational need to have other team types (e.g. platform, service, or temporary teams). And although the presence of those teams might indicate certain organizational dysfunctions, they have a right to exist, provided an organization keeps addressing the root causes, improving and simplifying its org design over time.

TOWARD A PRODUCTIZED ORGANIZATION
{DESIGNING & PREPARING}

Kaikaku - a radical, one-time change:

What do these principles highlight? Is the change revolutionary or evolutionary? It is both. And the move to productization requires key radical structural changes to happen at the start.

LOOK OUTWARD AND BROADEN OUT

The shift to productization starts by looking outward - understanding the customers and their needs, uncovering the impacts and outcomes the organization is to create for them. This outward view needs to be broadened by consolidating separate user personas and isolated customer journeys into a cohesive, broad understanding of the long-term customer value.

Structurally, this implies re-organizing into broad business value areas. Each business value area needs to have long-term relevancy to the organization. To avoid introducing more silos and fragmentation, it is vital to avoid creating small business value areas by broadening their boundaries and value definition.

DESCALE with well-defined business value areas:

Distinguishable business model and product strategy
Engagement of business stakeholders
Serves one or many holistic customer journeys
Clear purpose of existence that is being validated regularly
Autonomous product teams collaborating on the broadly defined customer value
Life cycle of the business value area encapsulates the product lifecycle
Economical accountability with profit & loss ownership

To avoid local optimization of business value areas existing only for their own purpose and to maximize structural flexibility, an organization should have a process in place to spawn, expand, shrink, and shut down business value areas based on global concerns.

MERGE BUSINESS & IT

These broad customer-centric business value areas operate as business within a business and become a home for multiple product teams to work hand in hand with business and other org functions.

But not everything and everyone needs to be within the business value areas: some commodity-like organizational-wide functions can be shared with the business value areas as services and platforms.

CREATE INTER-TEAM COHESION WITH PRODUCT TEAMS

The goals of the business value are owned by a group of product teams. Each product team is full-functional, end-to-end, customer-oriented, and technically autonomous. This is an ideal state to strive for at the formation of the business value areas. Deviations need to be questioned, managed, and worked on continuously.

Within a business value area, the product teams don't work isolated on a predefined feature set or architectural components. They avoid narrow specialization that would inevitably lead to process bottlenecks and minimize the overall organizational agility - be faster and able to change direction easily. Instead, product teams learn to collaborate within the goals of the entire business value area and also learn to work jointly as a team of teams. The right size of a business value area (not too small and not too big) should enable this inter-team collaboration.

Product teams must be a prevalent team type within the business value area. Other team types can co-exist in the ecosystem to support the product teams in value discovery, creation, and delivery.

Following the modern engineering paradigms, product teams must learn to work in a shared code environment across the entire organization and beyond. The business value areas are containers of domain knowledge and business objectives, but their boundaries should not break the laws of the software economy (i.e. code reuse). Private code ownership must be discouraged and used only in exceptional conditions with the goal of being eliminated long-term.

BRING MANAGEMENT TO GEMBA

The role of middle management shifts from controlling the work to growing organizational capabilities. And to avoid illusionary 'management-by-powerpoint', managers must stay close with and within the product teams - at Gemba.

Together, the managers (business stakeholders, product managers, engineering managers) and coaches (if such a role exists as a dedicated function: scrum masters, flow masters, agile coaches) form a cross-disciplinary management group that works holistically at the business value area level. This ensures the creation of a coherent strategy for growing product development capabilities of the business value area and its product development strategy.

Any form of micromanagement at the team level must be discouraged, as it creates a mere illusion of control; such negative behaviors spawn various organizational dysfunctions and will become a significant blocker in the journey toward productization. In-team management roles (e.g. team lead, tech lead) must not exist. Those highly skilled individuals who had been performing these duties before the change can now be promoted to join the product teams as team members or join the cross-disciplinary management group (e.g. as engineering managers to help grow the engineering capabilities of the teams).

Managers are encouraged to travel between the product teams and join them to learn how the work is being done, share skills, and coach improvements.

COMMIT TO LAUNCH AND KEEP IMPROVING

The structural changes described above need to happen at once - at the launch of a productized business value area and [as a recommendation] within 90 days. This timebox raises the sense of urgency and filters out superficial adoptions. You either do it or you don't.

Not everything can probably be changed at the start. Some organizational legacy will prevail for the moment. There should be an agreement on the immediate and future organizational blueprints. This difference between what is currently possible and what is envisioned creates the force to pull the organization forward to a better state.

To avoid getting stuck in mediocrity, there should be an explicit commitment to continuous improvements by evolving the imperfect current state towards an improved one. This is a shared responsibility of everyone within the business value area.

So, once the initial organizational structure is put in place with a radical change [Kaikaku], it is time to start continuously improving both: the product and the product development system [Kaizen].

TOWARDS A PRODUCTIZED ORGANIZATION
{LAUNCHING AND IMPROVING}

Kaizen - continuous, never-ending change:

In the spirit of empirical process control, an organization needs to create powerful feedback loops. They will increase transparency and, therefore, the ability to inspect and adapt based on real facts.

DEFINE, PRIORITIZE, AND SHARE BUSINESS GOALS

Communicating clear, prioritized business goals (in any form or format) is the best way known in the industry to guide product development. Defining, prioritizing, and communicating these goals is the primary function of management.

Midterm sub-goals for individual teams or groups of teams can exist. Still, they must be selected by the teams themselves from the global goals at the business value area level and be regularly adjusted (e.g. bi-weekly).

How exactly the goals emerge and get prioritized is to be defined by the management of the business value area. But despite the chosen tactics, the culture of collective product ownership for all the people working within the business value area is the ideal state to strive for. When people contribute to the strategy, know that they are heard, and understand the reasoning -- they display a sense of great commitment to the goals and will self-manage to reach them.

MINIMIZE THE DISTANCE TO CUSTOMERS

Once the goals are clear, further refinement with detailing and slicing is done by the product teams. In order to be able to do that, they ought to work directly and regularly with the customers. Thus, all the intermediaries and proxies between the product teams and the customers need to be eliminated. The possible experts, who had previously fulfilled the role of intermediaries and have the right skills, need to consider joining the product teams and/or becoming facilitators of team-to-customer collaboration.

Refinements of the goals must be a regular process run at the level of the business value area. It must start with all the product teams and management representatives involved. Such a process will ensure transparency of the goals at the level of the business value area, welcome adjustments and improvements, and therefore increase overall organizational adaptability.

The product teams decide how to go about refining them - when to merge and work together and when to diverge and work in subgroups. During the refinement workshops, where selected goals will be sliced to form concrete work items, team members collaborate and learn from domain experts, customers, and end-users.

ENABLE PRODUCT TEAMS TO DESIGN AND RUN EXPERIMENTS

By empathizing with the end-users and their needs (by collaborating with them), product teams design and run product experiments. They constantly engage in short "hypothesize - build - measure & learn" cycles. This is the primary function of the product teams.

The possible experts, who had previously done the so-called "discovery" only to hand out "specifications" to the "delivery teams", should consider joining the product teams and keep contributing with their skills. In general, any special single-function groups (that contribute to creating negative dynamics of the multiphased process with hand-offs) must be eliminated structurally. Work on the organizational (i.e. HR) policies to create a welcoming environment for those specialists to join the product teams.

PRODUCT TEAMS OWN THE PROCESS AND QUEUE

Interdependent, autonomous, self-managing product teams are the empowered intelligent agents of the product development ecosystem - they understand the business goals, have access to the customers, and define the work by themselves.

The self-managing aspect of the product teams allows them to choose any work mode and experiment with it. The business value area must not prescribe to the product teams how to manage the work (be it iterative-based, flow-based or other methods).

There are no fixed-scope commitments by the product teams. There is only a set of selected business goals that the product teams are committed to focusing on.

A list of forecasted experiments and product changes should be managed as an ordered queue rather than a fixed plan. As a result of a day-to-day collaboration within the business value area, that queue can be modified at any time to incorporate learning, maximize the outcome and minimize the output.

In the spirit of self-management, the team members (as well as the experts, specialists, and managers) are free to travel between the product teams to foster learning, spread good practices, and increase value flow. Long-term acquisition of skills within product teams to increase their autonomy is a long-term goal, so the product teams must strive to make themselves independent of any non-team specialists by insourcing those skills or making those skills redundant.

SHORTEN FEEDBACK CYCLES

The rate of team-level experiments and product changes should not be bound to the cadence of the product-level Sprint cycle at the level of the business value area. The product teams should strive to shorten the feedback cycles, making them fast, cheap, and safe. And in the spirit of continuous delivery, they should deliver as fast as possible and in the most controlled and safe manner.

Such intentions will require constant attention to engineering excellence. This is the secondary function of the product teams - to apply small, constant improvements to the delivery pipelines. This will drive down the transactional costs of product development, enabling technical agility (an aspect of organizational adaptability).

INSPECT & ADAPT AT THE PRODUCT LEVEL

The sum of the learning happening at the team level will enable holistic product-level learning. Regular (e.g. bi-weekly) product-level inspect & adapt cycles (aka "product-level sprints") are required to sustain alignment and enable adaptability. This is the secondary function of the management - adapt the product strategy and business goals based on empirical data. This will drive down the switching costs of product development, enabling business agility (another aspect of organizational adaptability).

OPTIMIZE FOR CONSTANT LEARNING WITH REAL DATA

Rich, real just-in-time product data that measures customers' behavior and product impact is the oil to the engine of productization. This is the tertiary function of the product teams - collect and act on the data.

The product teams need to find ways to embed the data-driven approach into their design, development, and delivery processes. The responsibility to constantly monitor the product metrics and adjust the product accordingly is the teams' responsibility. Product, marketing, and other skills are required for these activities and hence need to be acquired by the product teams.

BUILD ORGANIZATIONAL CAPABILITIES

With such a high level of self-management of the product teams who focus on the prioritized business goals and own the work, what is the role of management? Not to monitor work execution or manage individuals or individual teams... But to build organizational capabilities for building great products. This is the tertiary function of management.

Management is responsible for improving the productivity of the product teams and all individuals working in the business value area. That means they should be questioning, challenging, and redesigning organizational policies that maximize productivity and long-term thinking (i.e. HR, Financial, IT, and Management Policies). By doing so, they should strive to create a simpler organizational design.

In general, such an organizational design will require much fewer management positions than other organizations. Smaller hierarchies, less bureaucracy, fewer roles, increased transparency, and higher adaptability are the indications of organizational productization.

TOWARDS A PRODUCTIZED ORGANIZATION,
{SUMMARY}

REVOLUTIONARY AND EVOLUTIONARY

Adopting Product-Level Scrum requires structural changes that will drive the emergence of a new culture - a culture of user-centricity, product thinking, engineering excellence, and wide inter-functional collaboration.

Without those changes, successful adoption is not possible. Yet, those changes are not organization-wide; they are limited to selected business value areas and therefore are limited in their scope. Reorganization into business value areas is advised to be performed incrementally - one area at a time. This will minimize the risks, improve the quality of the change, and help acquire the learning needed to launch the next business value area better.

The transformation is not over once a certain business value area is launched. This will only mark the beginning of a new era. Thoughtful and diligent constant systemic improvements will be necessary since then to sustain the change and bring it to the next level.

It will take time for people within a newly created business value area to develop new behavior patterns and adapt to the newly created environment. So personal coaching and mentorship will be a great help. As well as patience, empathy, and forward-looking thinking.

THE SPLIT OF FUNCTIONS

The management functions:

Share clear and prioritized business goals.
Adapt product strategy and business goal based on empirical data.
Build organizational capabilities for building great products.

The product teams' functions:

Engage in hypothesize - build - measure - learn cycles.
Shorten the feedback cycles, and make them cheap and safe.
Collect and act upon product data.

MAKE EVERYBODY IN THE ORGANIZATION CO-OWN THIS TRANSFORMATION JOURNEY

This is the key prerequisite to a successful, long-lasting deep change described above.

Educating everyone, learning to listen, appreciating concerns, and co-creating solutions -- all of this is much slower than a "top-down agile transformation". Yet, this is the only way that the industry knows that ensures real, long-lasting deep change.

PRODUCT-LEVEL SCRUM