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