LLMs and Generative AI in the enterprise.
Inspire, develop, and guide a winning organization.
Understand the unique values and behaviors of a successful organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how to enhance collaboration and performance in large-scale organizations through Flow Engineering
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Exploring the impact of GenAI in our organizations & creating business impact through technology leadership.
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
The debate over in-office versus remote work misses a fundamental truth: high-performing teams succeed based on how they’re organized, not where they sit.
Leaders can help their organizations move from the danger zone to the winning zone by changing how they wire their organization’s social circuitry.
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
April 8, 2021
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.
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.
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.
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.
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.
In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail.
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.
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.
No comments found
Your email address will not be published.
First Name Last Name
Δ
Moving beyond mutual understanding, true business-IT partnership requires shared ownership of outcomes. This means…
The foundation of any effective business-IT partnership is shared understanding and mutual trust. Without…
As you know, I’ve been working with Steve Yegge (famous for his 20+ years…
The divide between business and IT has been a persistent challenge in organizations for…
