top of page

PRODUCT-LEVEL SCRUM

{productize your organization}

PRODUCT-LEVEL SCRUM IS ...

... Scrum used at a product level for maximizing customer-centricity and other global concerns.

More prescriptive than Scrum, as it is suited for digital & hardware product development only.

Not suited for managing individuals, individual teams, or projects.

A product-centric approach where multiple 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 patterns, practices, and examples from the industry that help create an organization that displays a high level of business agility, customer centricity and resilience (B2-B3 archetypes as per Org Topologies).

THERE SHOULD HAVE NEVER BEEN ANOTHER AGILE FRAMEWORK... 

9023668_number_circle_one_fill_icon.png
9023576_number_circle_two_fill_icon.png
9023759_number_circle_three_fill_icon.png

... 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.

TOWARD A PRODUCTIZED ORGANIZATION
{DESIGNING & PREPARING}

Kaikaku - a radical, one-time change:

  1. LOOK FROM THE OUTSIDE IN AND BROADEN OUT

  2. MERGE BUSINESS & IT

  3. CREATE STRONG INTER-TEAM COHESION WITH PRODUCT TEAMS

  4.  BRING MANAGEMENT TO GEMBA

  5. AGREE ON IMMEDIATE AND FUTURE ORG STATES

  6. COMMIT TO CONTINUOUS SYSTEMIC IMPROVEMENTS

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 FROM THE OUTSIDE IN AND BROADEN OUT

The shift to productization starts by meeting the customers and their needs, uncovering the impacts and outcomes the organization is to create for them. This outward view needs to be broadened to consolidate separate user needs and customer journeys into a cohesive, broad understanding of the long-term customer value. Together with the responsible business stakeholders, their long-term business goals, and their profit/loss expectations, this understanding of broad customer needs defines the scope of a business value area.

 

An organization should strive to minimize the number of business value areas by broadening them over time.

MERGE BUSINESS & IT

These broad customer-centric business value areas become a home for multiple product teams to work hand in hand with business and other org functions. These business value areas should strive for autonomy from the budgeting and decision-making point of view. But not everything and everyone needs to be within an area: some commodity-like organizational-wide functions can be shared by business value areas.

CREATE STRONG INTER-TEAM COHESION WITH PRODUCT TEAMS

The goals of the business value area are to be shared by a group of product teams: full-functional, customer-oriented, and technically autonomous teams. This means 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 agility of the organization - an ability to easily change its direction based on newly discovered customer needs and business goals. 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 (not too small and not too big) area should enable this inter-team collaboration.

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 limit code reuse or break the laws of the software economy in any other manner. Private code ownership must be discouraged and used only in exceptional conditions with the goal to be eliminated long-term.

 

Product teams must be a prevalent team type within the business value area and long-term for the entire organization as they optimize for discovering and delivering customer value. Other team types can co-exist in the ecosystem to support the product teams but must not stand in the way of value discovery, value creation, and value delivery.

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 stay close with and within the product teams - at Gemba. Cross-functional management should be encouraged at the business value area level. On the other hand, team-level management must be avoided as it gets in the way of teams' ability to self-manage, learn and improve. The coaching function (with agile coaches, scrum masters, flow managers, etc.) should be organized holistically for the entire business value area.

AGREE ON IMMEDIATE AND FUTURE ORG STATES

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

 

But not everything can be changed at the start. Some organizational legacy will prevail for the moment. To avoid getting stuck in mediocrity, there should be an explicit commitment to work to move the immediate (not perfect, but workable) starting state towards an improved (perfect, future) one.

COMMIT TO CONTINUOUS SYSTEMIC IMPROVEMENTS

This difference between what is currently possible and what is envisioned creates the force to pull the organization forward to a better state -- continuously. 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:

  1. DEFINE, PRIORITIZE, AND SHARE BUSINESS GOALS

  2. MINIMIZE THE DISTANCE TO CUSTOMERS

  3. ENABLE PRODUCT TEAMS TO DESIGN AND RUN EXPERIMENTS

  4. PRODUCT TEAMS OWN THE PROCESS

  5. SHORTEN FEEDBACK CYCLES

  6. INSPECT & ADAPT AT THE PRODUCT LEVEL

  7. OPTIMIZE FOR CONSTANT LEARNING WITH REAL DATA

  8. BUILD ORGANIZATIONAL CAPABILITIES

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

Shared, clear, and prioritized business goals (in any form or format) are the best way to guide the business value domain. Defining, prioritizing, and communicating these goals is the primary function of management. 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. 

MINIMIZE THE DISTANCE TO CUSTOMERS

Once the goals are set, further refinement with detailing and slicing them into the work to be done is the primary responsibility of the product teams. In order to be able to do that, they ought to work daily 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.

ENABLE PRODUCT TEAMS TO DESIGN AND RUN EXPERIMENTS

By empathizing with the customers and their needs, 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 drive a multiphased process with hand-offs must be avoided long-term.

PRODUCT TEAMS OWN THE PROCESS

Interdependent, autonomous, self-managing product teams are the empowered intelligent agents of such a system - they understand the high-level goals, have access to the customers, and thus must be able to define the work (design and run product experiments and changes) by themselves. The self-managing aspect of the product teams allows them to choose any work mode (individually and collectively) and experiment with it. Fixed-scope commitments by the teams need to be avoided at all costs. The forecasted set of experiments and product changes that the product teams identify 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 work queue can be modified at any time to maximize the outcome and minimize the output. Team members, experts, specialists, and managers are encouraged to travel between and join the teams to foster learning and spread good practices.

SHORTEN FEEDBACK CYCLES

The rate of team-level product experimentation should not be bound to and limited to the global 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 (in the spirit of continuous delivery). This is the secondary function of the product teams - do small constant improvements to the hypothesis testing pipelines. This drives 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 enables holistic product-level learning. Regular product-level inspect & adapt cycles 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 drives down the switching costs of product development, enabling business agility (another aspect of organizational adaptability).

OPTIMIZE FOR CONSTANT LEARNING WITH REAL DATA

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

BUILD ORGANIZATIONAL CAPABILITIES

With such a high level of self-management of the product teams to work on the business goals, what is the role of middle management? Not to control the work or manage people but to build organizational capabilities for building great products. This is the tertiary function of management.

TOWARDS A PRODUCTIZED ORGANIZATION,
{SUMMARY}

THE SPLIT OF FUNCTIONS

The management functions:

  1. Share clear and prioritized business goals.

  2. Adapt product strategy and business goal based on empirical data.

  3. Build organizational capabilities for building great products.

The product teams' functions:

  1. Engage in hypothesize - build - measure - learn cycles.

  2. Shorten the feedback cycles, and make them cheap and safe.

  3. 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 is much slower than a "top-down agile transformation" but is the only way to ensure real long-lasting deep change.

bottom of page