This blog post is summary and key content from IT Revolution White Paper (Project to Product Transformation - Practical Guidance from Fourteen Enterprise Journeys by Ross Clanton, Amy Walters) from IT Revolution DevOps Enterprise Forum 2019.
What are different focus areas for Project to Product Transformation?
Transformation Implementation: Guidance to start the transformation, drive it and keep it alive.
Synchronize Business and IT: How to tackle the problems of engagement, alignment and priortization across the organization.
Product Taxonomy: How do you define and classify different products in the organization?
Workforce and Talent: What should be organization structure, team roles etc.?
Funding Model: How to change funding model to support product centric organization?
Architecture: How transformation can be implemented across tools, software and infrastructure components?
Culture & Leadership: How to ignite culture change and engage leadership to ensure you have a successful transformation?
What are different stages of Product Transformation?
Incubate: Early adopters, like minded, in pockets.
Scale: Transformation actually happens in this stage. Entire enterprise is pushed.
Optimize: Continuous refining the transformation through measured learning
What are guidances for each of the Domains and Stages above?
Transformation Implementation:
People must understand why we are doing the transformation, what problems are we solving?
Many transformations fail because strategy doesn't meet with execution or resistance to change.
This strategy helps you to establish the goals, approach and rollout for transformation (in phases, by line of business, by certain portfolios that meet specific criteria, experimentation followed up growth, or by bing bang approach.
Starting small with a team of progressive thinkers and then spread to rest of the organization is the key.
Communication is important
People forget about communication in incubation phase
Frame the why: Because of disruptive factors in the industry or need of speed and agility
Establish communication plan for constant and consistent flow of information
Focus on Transparency
Use Success Stories
Track and measure success: Focus both on process which delivered technology (for e.g. cycle time, lead time etc.) and value and outcomes that were delivered (business outcomes, such as revenue generation, customer acquisition, conversion, cost reduction, and/or customer/employee Net Promoter Scores (NPS). Many enterprises also shifted to an objectives and key results (OKRs) method )
Few of the constraints and challenges are in Transformation Implementation are:
Disconnect from business strategy
Lack of c-level sponsorship or changing leadership
Business and Technology Synchronization:
Frictionless flow from business architecture through product development to valuable outcomes.
Orchestration of integrated value creation as opposed to a relay race of handoffs toward value is needed.
We establish Product Life Cycle whose key outcome is to create an environment in which business and technology leadership fully engage in product development together.
Pivot from a model where they optimize for cost and efficiency to one where they optimize for speed and agility
Prioritization changes in Product Centric Model. In incubation stage team can have separate prioritization model but they need to tie this back to PMO Model. But once you move to Scale Maturity then a leaner quarterly or half yearly prioritization model can be established. Mostly these prioritization models are OKR based.
Network based organization - The product owners are empowered to connect with other product owners to align their product objectives with their value stream priorities and/or dependencies.
In fully transformed state your technology organization is aligned to business organization
Product Team (IT and Business) align on a common set of OKRs
Shift Discovery and Delivery Models from Outputs to Outcomes - Value stream mapping provides visibility into the overall product ecosystem. This also starts to orient teams to focus on the delivery of outcomes, and it provides a great structure to measure and continuously improve your delivery process to achieve those outcomes.
DevOps Practices in Place - This is a critical capability that gives organizations the ability to scale into the product-based model
Build product discovery capabilities into your organization as early in your transformation as possible. Transformed organizations establish routines around discovery and delivery.
Few of the constraints and challenges are in Business and Technology Synchronization are:
Excessive politics and organizational bureaucracy: engineering-centric ways to solve compliance problems that provide better control and efficiency , process as POC, suggest trialing a new approach on an extremely small scale
Product planning exercises with high overhead:
Fake Agile: Tend to lack focus on the Agile Mindset and Values, focus on customer is absent, too much bureaucracy and hand-offs.
Partially allocated or not fully dedicated product team members.
Product Taxonomy:
This domain is the most ambiguous and lacks industry guidance on how to define product taxonomy.
Many a times Product Definition occurs during the scale stage
A product taxonomy provides enterprises a visible, centralized method for defining, managing, and tracking products across the company’s value streams. There are multiple benefits to defining the product taxonomy
The taxonomy helps to show the hierarchy and relationships between the different products and capabilities that exist within your business
visibility across business areas, redundancies, dependencies, value flow
Common language around products, product types, stages (legacy or strategic)
Accountability clearing path for for new features and support incidents
Awareness around workforce needs and skills (specially product owners and product managers)
Organize around customer needs instead of technology or applications.
Product is a software offering that we create to deliver value to our customer. By this definition it is implied that we know who our customers are; we understand what they value; we understand the ecosystem or value stream within which the product fits; and we design, build, and support our product as a cross-functional, long-lived team with the skills needed to own the product end to end.
Products can be differentiated by designating a product classification and product life cycle stage
The Product Taxonomy Structure: Normally Product Portfolio (collection of product groups whose value deliveries share high dependency), Product Group (Related Products whose value deliveries share high degree of dependency), Products (persistent grouping of applications, technology, talent, and data that enable a specific outcome, customer experience or capability.
Most important thing is that when defining the product, focus on the outcome or customer experience it delivers rather than the application or technology that delivers the outcome or experience.
Product Types: Ultimately, everything can be considered a product leveraging modern product management practices delivered by a long-lived product team
How to design a Product Taxonomy? These tactics are intended to provide guidance and to suggest approaches, tools, and techniques to help construct conversations that move the organization to a product-centric operating model
A recommended approach is to start at the application layer and work your way up to products (customer experiences) and product groups
Example of Product Taxonomy Template
A well-defined product taxonomy will serve as a blueprint for how to redesign the organization around the products.
At the heart of the product model is ownership, accountability, and empowerment.
Teams should be small sized (approximately five to ten people) and cross-functional, containing all the skills needed to plan, design, build, and run the product.
To determine the number of teams needed, the scope and scale of the product should be assessed based on historical data, overall demand, complexities, and dependencies
As each portfolio works through the process of mapping their product taxonomy and designing the teams, common themes may begin to emerge across the enterprise
Following constraints surfaced when the product taxonomy was missed or underutilized
A lack of clear product definition and product mapping
Fixation on Agile frameworks without a focus on products
Lack of clear product ownership and accountability
Workforce and Talent:
Frameworks don’t transforms organizations. Building high performing teams and then enabling them transform organiza-tions.
Simplifying the management structures, minimizing control-oriented functions, and investing in growing your talent are critical to achieving this outcome.
Establish modern product roles and team structures, Upskill teams through immersive learning environments (Dojos), reduce management layers.
The product team members must be 100% dedicated to the product and not partially allocated to multiple projects. Partial allocation creates context switching that is detrimental to a team’s predictability and productivity.
Common roles: Product Owner/Product Manager, Designer, Engineers
Other roles: Value Stream Coach, Scrum Master or Agile Team Lead, Enterprise Product Coach
The role of the traditional PMO should also pivot and/or significantly diminish in a product-centric operating model
Transform the PMO to become more focused on enabling continuous improvement for the product-centric operating model
PMO could become an ambassador for change by evolving its responsibilities to support an Agile and product-centric culture
The PMO team members could each be assigned to a product portfolio as a supportive partner to the product portfolio executive and product manager/owner roles
Reporting product metrics, financials, and key product insights at the product portfolio level can become a gap if there isn’t someone in place to aggregate this data at the portfolio level
The PMO could play a partnership role with Finance to ensure funding for the product teams is enacted, moving the enterprise away from funding capital expenditure projects
The PMO can also assist with reporting value, ROI, cost of products, and cross-product portfolio-level cost and value insights. Additionally, they could modernize compliance requirements by providing product teams awareness to compliance needs and guidance on how to best comply (e.g., risk and compliance, audit requests, evidence, etc.).
Drive toward a leaner organizational structure with less bureaucracy by reducing management layers. The frozen middle.
A Dojo is an immersive learning environment where teams are guided toward new ways of working, leveraging Agile, Lean, DevOps, and product-oriented and modern engineering practices
A few activities that are critical to team success as they initially form include
Product Definition: establishing a shared understanding and team alignment to what the product is; why it exists; the business value of the product; the life cycle vision for the product; who the product serves; the product community map depicting stakeholders, customers, and key dependency partners; the product’s problem space; and the product objectives and success measures
Team Working Agreement: establishing team norms and agreements about how the team will work together (e.g., tools, communication practices, routines, the definition of ready and done, values, backlog practices, etc.).
Product Discovery: Establish an approach to quickly test product ideas against business, technology, and user experience to gain a holistic view of an idea, de-risking the idea and gaining immediate customer feedback through hypothesis testing and prototyping. Assume ideas are wrong until proven otherwise.
Foundational Workshops: Establish Agile, product-oriented, and DevOps foundational training or workshops to ensure foundational mindsets are established consistently across the team.
Some of the key constraints that need to be overcome are:
Functional outsourcing
Functional Siloing
PMO Driven Transformation: The outcome tends to be a scaling framework layered on top of a project-centric organization. This minimizes the amount of real change in the organization and is incremental at best. It can even negatively affect team performance, as the team is now being asked to deliver in an Agile model while still being in a broader operating model and organizational structure oriented around waterfall project models.
Inadequate Training
FUNDING MODEL
An indicator of success in product-centric delivery is an increased focus on funding capacity and outcomes instead of blanket funding requirements.
Preconceived notions of how time is kept, how assets and projects are capitalized, and how departments are held accountable may be some of the most difficult structures to overcome.
The phrase “on time, on scope, on budget” has no place in a product organization. Product organizations are held to the standard of delivering value to the customer rather than simply meeting a set of requirements.
A good rule of thumb for the funding model in the incubation stage is to “fight winnable battles.”
Transformation teams used several strategies that became the incubate indicators
Work within the budget and financial constraints:Understand what constraints current model may impose, show value of your transformation and how you can continue to work within constraints
Establish pilot teams as capacity-driven: More forward-thinking finance department, small teams are funded for short time, this is also a Spotify model, it also helps in gaining acceptance at scale stage.
Use quarterly/biannual funding for piloting teams: Make leaders accountable to present the value statements to Finance even before receiving any funds. "Prove my worth" model.
Shift from project to team-based funding for technology investments: Push organization further into product model, use technology budget to scale transformation.
Create a “Strategic Investment Committee”: "Shark Tank" model, business and technology leaders present their epics to the committee. The Shark Tank committee asks the tough questions and, in the end, assigns funds based on the most compelling business cases.
Focus on alignment between business priorities and product funding:To truly measure whether value is being derived directly from priority investments, teams must correlate their capacity and cost of that capacity to the value derived from what the team delivers
Expand funding model to non-technology investments:As the transformation hits the optimization stage, the product funding model must be applied to all aspects of the business
Indicators show the practices that most should follow and look to implement, but the scenarios below are unique to organizations fertile for more aggressive tactics:
Involve Finance from the start:make Finance a key stakeholder in helping define the end-state.
Define end-to-end value and cost metrics:According to Donald Reinertsen, author of The Principles of Product Development Flow, the most important part of product-orientation is that value streams are tracked for life cycle profitability
Some of the constraints that need to be overcome are:
Technology organizations are treated as cost centers:In traditional technology organizations, the CFO and finance group see the technology investment as a pure cost center. In the 2018 DevOps Enterprise Summit London presentation “Project to Product: Practical Realities at a Large-Scale Enterprise” Carmen DeArdo contends that IT is viewed as a cost center with little to no capability to generate profit.4 With this myopic thinking, it is incredibly hard for technology and product leaders to make the value of their teams, their products, and the financial investments visible. This paradigm is a bit easier in a product-centric transformation because product owners tie technology investments directly to customer value. To continue combating this constraint, ensure that the value being delivered is visible.
Business leaders expect to fund features:In project-based organizations, finance and business leaders expect a yearly budgeting exercise where they dream up some grand opportunity and go for a “big bag” of money to fund their supposed great idea that will take all year to deliver. From earlier indicators, we know that project-based funding is not the path to success. The product transformation must make the value stream priorities visible and show business and financial leaders that the capacity funded through the evolving model continues to deliver value. To combat the single annual budgeting exercise, ensure that leaders see how changing priorities equate to positive value for the customer.
Lack of clear model: the lack of a clear model for financing products can be an impediment to true product-centric transformation. Drawing from successful models at other organizations or establishing best practices, like flow metrics in Project to Product,5 can help provide the finance team with a good foundation for change.
ARCHITECTURE
Architectures evolve over time just like most processes and organizational priorities.
Ensure that the transformation evolves the architecture into a catalyst for desirable outcomes instead of the architecture devolving into additional overhead for teams to manage
Architecture is about describing, documenting, and transforming the enterprise’s most fundamental systems
In all organizations, architecture was viewed as an accelerator to the value proposition of the product transformation
Several tenets that value stream architecture should focus on are Software Architecture, Transformation Teams, Risk Assessments, Organizational Structure, Reporting, Training, Tooling
A new role, the value stream architect is responsible for streamlining the delivery of value for each value stream
Establish flexible, low-friction ability for teams to build:The goal at the heart of the product transformation movement is to deliver value to the customer as fast as possible
Introduce architectural patterns that increase speed of delivery:Introducing progressive architectural patterns for delivery, like event-driven programming and API-first development and domain drive design, will help increase the efficiency of the value stream and enable seamless future additions to the value stream.
Engage enterprise and business architecture organizations:By engaging these two architectural disciplines early in the transformation process, the transformation leaders can begin to get buy-in from these groups to plant the seeds of change and to also help the transformation team understand the complexities that shifting to a product-centric enterprise could impose.
Initiate a “toolchain as a product” paradigm:Building a team and competencies to focus on the toolchains related to value stream delivery is key to frictionless value.
Focus on automation:DevOps and product-centric delivery go hand-in-hand and complement each other. In order to build predictability and remove unnecessary work, teams must automate everything from software builds and tests to deployments and feedback loops.
Adopt open-source platforms and tools:Open source is often a leading indicator of a progressive, forward-thinking organization as well.
Create architectural communities:These communities help disseminate information, such as patterns, trends, and organizational strategies, to teams closer to the value streams.
Allow teams to make architectural decisions regarding speed to market:Enabling teams to make the architectural decisions that are best suited to their value stream helps to empower them and drives a much higher velocity of value delivery
Move to cloud and cloud-native computing:Underlying infrastructure should be consumed as a service, as needed, and not be a burden for product teams to manage.Coupling these cloud capabilities with Twelve-Factor software design patterns enables product teams to build applications that are truly cloud native.
Some of the constraints which we have observed are:
Changing operating model without deliberate focus on decoupling systems: To reduce risk and gain efficiencies in the delivery of value to customers the best way to approach the transformation is to first start decoupling the systems into manageable “products.”
Bureaucratic architecture processes impede team velocity:ARBs and other centralized processes take decision-making rights out of the hands of the leaders closest to the value stream.
CULTURE AND LEADERSHIP
As Peter Drucker is widely attributed as saying, “Culture eats strategy for breakfast.” It’s critical that you focus on leadership behaviors and fostering a culture to ensure that the organization can thrive as it moves to this new model.
Two questions can be asked from the organization
What was done to align leadership and orient leadership behaviors?
What actions did enterprises take to drive culture change and upskill their workforce given the changing operating model and expectations?
Simultaneously grow strong communities through a bottom-up transformation while also connecting with a clear, top-down drive to transform the organization.
The key is to find a transformational leader with significant political clout and savvy who is willing to sponsor and drive this transformational movement.
People are more likely to reject change if they perceive too much effort, time, or risk is required for the amount of value that will be returned.
Define new incentives:Incentives focus on outcomes over outputs, but they would also enable cohesion and empowerment, encouraging management to create space for their teams to participate in learning- and community-focused events, encouraging reuse and sharing of code through inner-sourcing versus everyone building their own code from scratch
Accept and acknowledge failure as part of the transformation process:When scaling the transformation, leaders would publicly emphasize “failing fast” and team empowerment.
Teach new leadership behaviors through workshops:some enterprises established leadership immersion workshops to expose the frozen middle and executives to this new way of working.Teams must continually discover and adapt the product they are delivering and increase their understanding of the viability, desirability, and feasibility of their project’s value for their customers.
Organize teaching workshops led personally by management:Success was seen in multiple instances where leaders took on the role of teachers and didn’t simply mandate change.
Organize external DevOps/Product conferences:Many companies modeled these conferences after the public DevOps Days, as these events have proven highly successful at building community.
Host hackathons:They are yet another powerful way to bring people together from across the organization and get them to connect, share, and learn from each other.They are often focused on innovating on a customer or business problem that could be solved.
Utilize Dojos:proven to be a powerful mechanism to change culture in the companies. Space (Create teaming spaces that encourage different groups to come together, demo, and share their learning with each other), Process (You can orient your processes in the Dojo to get teams comfortable making decisions for themselves), Coaches (Dojo coaches are often cultural experts and evangelists, They also become a voice of the teams in the Dojos)
Few of the constraints which need to be overcome are:
Executive behaviors contradict cultural aspirations:Examples of this include executives still making technology decisions without engaging their tech workforce, or overcommitting delivery for their teams
Middle management resists change (the “frozen middle”) and is not addressed:When you’re incubating your transformation, focus on leaders who want to change and help them. As you build momentum, you can pivot more of the later adopters who want to see some success before they jump on board.
Existing talent does not participate in the new processes, leading to attrition:This means people sometimes step out of their comfort zone to learn and contribute in an area of delivering the product that isn’t their primary expertise. Secondly, in this model teams typically are responsible for running and supporting the products that they build and deliver
Hashtags: #DevOps #Product #Transformation #Agile #Leadership
Disclaimer: Neither Agileance Org nor the contributors to this post claim the ownership or validity of the content. All rights reserved by the content owner.