This post is an excerpt from The Project to Product Transformation white paper, written by Ross Clanton, Amy Walters, Jason Zubrick, Pat Birkeland, Mik Kersten, Alan Nance, and Anders Wallgren. You can download and read the white paper in its entirety here.
This study focuses on a Fortune 100 retail enterprise that demonstrated sustained progression through the three stages of enterprise product transformation.
Their journey began with grassroots experimentation in a small number of technology teams within the digital and API platform organizations. As initial success was seen in this experimentation, they also spanned their new practices across a few mainframe and monolithic applications.
The initial focus of the incubation stage was on DevOps and Agile. A Dojo was established to demonstrate and accelerate the full-stack product model. Coaches supported immersive learning experiences within the Dojo and quickly educated workers on the new product team roles (e.g., product owner, scrum master, full-stack product team operating with an Agile mindset while practicing DevOps principles).
The success and learnings from the incubation stage quickly led to a “big bang” implementation during their scaling stage. This shift was directed by the CIO, who had previous product experience that crystallized his vision of a transformed organization. The CIO and various other leaders held frequent informal town halls to transparently communicate vision, intent, and approach as the model was being developed.
The transformation implementation was led by internal technology leaders. This organization shift was implemented in waves over a nine- to twelve-month period. The number of projects this company worked on during any given time reduced from more than 800 to fewer than twenty.
The full organization was transformed during the late scaling stage and optimization stage. As the product model matured within the IT organization, the business realized that the formerly slow “black box” IT was no more. IT was now moving faster than the business, increasing their engagement with the public and igniting interest in adopting Agile and product-oriented methods across the business.
The Dojo, which once served only IT workers, became the learning and acceleration environment for business teams to rapidly adopt Agile, Lean, and product-oriented concepts. The Dojo engagements were leveraged as opportunities to bring IT and business to the table together, further bridging the gap between business and IT. It was at this point that full enterprise or business agility became a real possibility.
Business and Technology Synchronicity
Product leadership roles were established within both IT and the business to encourage continuous alignment to products. As the product model scaled across IT and the business, the need to implement shorter planning cycles surfaced.
Quarterly product planning (QPP) was implemented as a method to synchronize cadence, OKRs, and roadmaps of product teams. QPP was intentionally designed to counteract heavy bureaucratic governance.
Product teams were educated on OKRs and provided guidance on how to form product networks in a self-organized way.
Product owners were encouraged to connect with other product owners who were aligned to a common value stream, customer experience, or shared objective.
Coaches provided facilitation support to help form product networks and establish product owner routines that focused less on the current sprint and more on removing escalated blockers, synchronizing OKRs, and managing dependencies.
The principles of QPP were based on empowerment, collaboration, and Lean processes. As the transformation evolved into the optimize stage, the product networks became less dependent on coach support and more self-sufficient.
Operations was also redistributed to imbue support skillsets within each product team. This further underscored the full-stack product team concept of having full ownership of all design, build, and run of their products and scaling DevOps across the IT organization. This shift ultimately leaned out the support organization to include a technology operations center, which functioned as first-level support for call centers, routing incidents, and problems to the proper product teams.
Technology leaders from each portfolio drafted the product taxonomy and mapped the entire organization to the product taxonomy structure. The taxonomy continued to evolve quarterly with official updates published biannually.
Once the taxonomy was drafted, the organization aligned products and their supporting technology/application accountabilities to full-stack product teams. As product transformation matured into the optimization stage, the product mapping process also matured by leveraging the Dojo to host coach-facilitated product definition and discovery workshops. The workshops offered product teams the opportunity to more crisply define their products through product chartering and value stream mapping.
It was important for the product teams to understand the larger ecosystem within which their product would sit. This helped prevent the product model from becoming bloated over time.
Workforce and Talent
Product owners were initially identified from within the IT organization then later transitioned into the business. Traditional project management roles (e.g., project managers, business analysts, process analysts, testers, and functional analysts) were replaced by product owners, scrum masters, and full-stack engineers.
This shift also triggered a large-scale effort to delayer the organization, leaning out the hierarchical structure that had previously supported more traditional bureaucracy. The delayering reduced the management structure from ten layers of management to four.
Prior to the product model transformation, the IT side of the business was primarily outsourced and offshore, with a mix of 70% contractors and 30% employees. Within the first year of the product transformation, this ratio flipped to 70% employees and 30% contractors. This was largely achieved by removing thousands of contractors from the workforce, driving the total technology workforce from over 10,000 people to approximately 6,000.
Keeping the intellectual property in-house, created by employed engineers rather than outsourced to third parties, also preserved the enterprise’s competitive edge. The organization was able to perform better on speed, quality, and cost due to improved prioritization and technology practices across the organization.
The experiential learning approach of the Dojos had proven to be very effective at “leveling up” people through the transformation. Thus, Dojos were scaled out to support the scaling stage and ultimately supported over twenty-five teams at any given time. This approach was coupled with Agile training and boot camps to help train teams as they were moving to the new product-based model.
Another critical enabler of the product model transformation was a “big bang” implementation of how work was funded. The funding model shifted from funding projects to funding persistent product teams. Funding evolved into a biannual process focused on value-based outcomes in the form of OKRs. Other aspects of the funding request would support any necessary software, hardware, and product team personnel. Leaders would need to determine how many product teams would be needed to support a product and build the team needs into the funding request. Funds would be released to teams quarterly (as needed) based on outcomes achieved, product roadmaps, and projected OKRs.
Additional engineer empowerment was manifested by a quarterly CIO workshop, which gave the lead engineers a voice in architectural vision and decisions. Culturally, there was a principle shift to valuing guidance over governance regarding preferred technology strategies. Monolithic applications were no longer the norm. Priority was put on descaling monolithic, internally focused systems into smaller pieces that could be run by small, self-managing, customer-focused teams. Enterprise-class APIs and microservice strategies were leveraged to build common services and decoupled systems. Automation-first principles were of highest priority for all teams for all aspects of their product delivery end to end. Other critical functions were also automated into delivery processes, including Information Technology Infrastructure Library (ITIL) processes, audit evidence, and security controls.
Culture and Leadership
Significant focus was put on building an engineering culture that stressed the importance of internal intellectual property and inner-sourcing. To accomplish this cultural transformation, internal events such as hackathons, DevOps days, product and engineering inner-conferences, and demo days were implemented, which provided the employed engineers venues in which they could network, share knowledge, and learn best practices.
Additionally, Dojos began to serve as a powerful cultural hub within the organization, enabling teams to start learning and practicing new behaviors in a safe environment. Previously, engineers did not have a voice or autonomy to creatively solve customer problems; rather, full solution requirements were dictated to them via waterfall projects.
Leaders were put through Agile mindset classes and immersive workshops on team functionality in the new model. This helped them adapt their leadership styles to enable and empower their engineers in this new model. A DevOps summit was run within the company with all technology executives and middle management invited. Speakers from the DevOps Enterprise Summit who were recognized for leading transformation within their own companies were invited to share their stories at this event.
Overal Reception to Transformation
While the product model implementation was viewed as a success in short order, it wasn’t free of challenges or fail points. Some of the challenges included resistance to change from the frozen middle, or middle management. Agile and product-oriented methods were often viewed as a phase that would pass. Shifting people into new roles (e.g., project managers becoming scrum masters, business analysts becoming product owners, configuration analysts becoming engineers) presented failure points as people weren’t provided adequate training to shift successfully. This gap led to attrition and frustration within teams.
These constraints were managed and addressed as the company continued to optimize their product transformation. Over time, they have been able to hire high-caliber talent who came from digital-native companies such as Netflix and have been able to continue driving toward a more Lean, highly efficient organization.
It’s safe to say that the typical success rate for a “big bang” transformation of this scale is likely in the low single-digit percentages. However, this company was extremely successful. Why? Upon deeper inspection, we uncovered the following characteristics that were likely significant contributors to their unlikely success.
- They had a burning platform, and everyone knew they had to change. Their industry was going through significant disruption. New threats emerged from Amazon, as they had a more digitally oriented business model and were quickly taking market share from other players in the industry.
- They already had a highly collaborative culture, making it easier to get their technology workforce to share and learn across the organization.
- They had fostered a strong bottom-up cultural movement as part of their DevOps transformation prior to kicking off their product transformation.
- Their entire C-suite turned over in about a twelve- to eighteen-month timeframe. New executives were looking to champion change initiatives. Within IT this enabled bottom-up initiatives to meet top-down initiatives, which accelerated the overall rate of transformation.
- Their new CIO had previous success with driving DevOps and Agile transformation in a previous enterprise.
- They had strong leaders driving their transformation who understood the internal environment and how to influence change across the organization.
- Their people were all colocated versus being geographically spread across many locations. This allowed them to drive more cohesion and connectedness as they formed product teams across the organization.
- Their business and security executives were willing to embrace a new model of working with IT to get work done.
In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail.
- Seven Domains of Transformation
- Transformation Implementation
- Business and Technology Synchronicity
- Product Taxonomy
- Workforce and Talent
- Funding Model
- Culture and Leadership
In the full white paper, The Project to Product Transformation, you will find not only the guidance indicators to create, increase, and sustain velocity, but also the negative force learnings that should help you avoid pitfalls in your transformational journey.