Seven Papers on Organizational Change

1) Thinking Environments

Evaluating Organizational Models for DevOps to Accelerate Business and Empower Workers

While the traditional IT organization is structured into functional silos, DevOps relies on empowered, cross-functional teams. Is it possible to blend the two approaches and work within the traditional structure? Or do you need to restructure your organization to support DevOps?

The traditional structure offered a way to continuously improve skills in individual practice areas—software development, infrastructure, operations, and security, for example. When you organize around cross-functional teams, do you lose the ability for more skillful infrastructure experts to oversee and coach more junior infrastructure specialists, and do you lose opportunity to build capability and expertise within that technical specialty?

The traditional functional organization can be highly efficient at allocating experts across different projects, reassigning technical experts based on the company’s needs. Must a DevOps organization sacrifice this efficiency?

These are questions that many of us grapple with as we travel along the DevOps transformation journey to improve our organizations. This paper addresses those questions, identifies some of the models that enterprises and organizations are currently using, and proposes four organizational models for leaders.

Download the Full Paper

2) Making Matrixed Orgs Successful

Tactics for Transformation in a Less Than Optimal Organization

In Thinking Environments, the authors described four organizational models, and the benefits and drawbacks of each model with respect to DevOps. They recommend moving away from a matrixed organization to overcome the drawbacks for DevOps teams. In some cases, especially large traditional organizations, there are good reasons for not moving away from a matrixed organization. For example:

• skills development
• career development
• separation of duties
• optimization of resources across products/programs
• potentially more clear ownership of technical debt compared to the product focused model (no one owns technical debt in the product focused model)
• aligns with business funding and/or regulations

In other cases, organizations are structured to reflect customer organizations, or the organization is early in their DevOps transformation and there’s insufficient support for reorganization.

This paper focuses on the problem of organizations that can’t or won’t move away from a matrixed organization. In particular, it focuses on those matrixed organizations in which:

• the functional (vertical) organization is responsible for defining and measuring the process;
• and, the programs/projects (horizontal) are responsible for program execution.

Download the Full Paper

3) Value Stream Architecture

Creating an Architecture to Connect the Dots in DevOps

While traditional architecture principles focus on the “ilities” of software development, such as usability, maintainability, scalability, availability, extensibility, and portability, the value stream architecture model focuses on creating a transparent, repeatable, self-healing model for the delivery of software. The key difference in the two architecture paradigms is that the traditional “ilities” model focuses on the software product while the value stream model focuses on the delivery of the software product.

As organizations continually evolve and rely on cross-functional teams coming together and adopting DevOps practices, the process of delivering software products must also evolve. Value stream architecture is the facilitator of organizational process change and transparency, and should be the primary focus for every organization striving for DevOps greatness.

The adaptability that the value stream architecture gives an organization to optimize its delivery processes is measurable and repeatable through the flow units and flow metrics, as described in this paper. These attributes of the architecture allow for a self-healing capability that drive positive change and value back into the architecture through feedback loops. The value stream architecture approach to DevOps and process improvement will continually add value back into the delivery process as long as the architecture is the key focus of the process improvement journey.

Download the Full Paper

4) Moving from Project to Product

Modernizing Traditional Enterprise Operating Models

Enterprises can no longer rely on long-established business models in which technology was merely applied to drive more efficient business processes. In our current digital economy, technology is now key to all business strategies. The traditional approaches to manage technology planning and delivery are not optimized for this new reality. These models were optimized for cost and segmented responsibilities to drive localized efficiency of the different processes across the technology value stream. These models need to fundamentally change to drive more connectedness between business and IT. This enables businesses to shift focus from optimizing for cost and a false sense of timeline predictability to optimizing for the speed and rate of business value delivery. Those that have embraced this shift or were born in this era are disruptors that are uniquely positioned to capitalize in this new economy.

For the rest of you, being Agile and implementing “code to cloud” DevOps practices are necessary but no longer sufficient to keep competitors from disrupting your business and taking your customers! The differentiation has now shifted left in the value stream and requires a new way of thinking about how work flows, how to make bottlenecks visible, and how to empower product-based teams. Will this journey be easy? No. Is it necessary to start now?

This paper first clarifies what a product-based software delivery model is and then provides some simple guidance on how to start your journey.

Download the Full Paper

5) The Project to Product Transformation

Practical Guidance from Fourteen Enterprise Journeys

Instead of another paper on why you should move from project to product, this paper focuses on on how to make the move. By using the decades of experience from our authors and peers at the DevOps Enterprise Forum to glean as much as we could about the do’s and don’ts of enterprise product transformation, we compiled that knowledge into something digestible and applicable to you and your organizational transformation.

To gather information that is both relevant and that has been proven successful, we interviewed industry thought leaders across fourteen large enterprises who successfully drove product and technology transformations. These leaders had amazing insights from their successes and failures in moving organizations from project to product at scale. We took the enlightening moments from those interviews and broke the learnings and recommendations down into exercisable guidance. Through the interview process, we noticed similarities and themes that formed the main structure of this paper. The interviews conducted intentionally spanned a breadth of industries to demonstrate the applicability of the product operating model in any industry.

The companies assessed span the following industries: retail, banking, airline, telecommunications, apparel, accessories, sports equipment, financial services, insurance, technology, food and beverage, and medical software.

Download the Full Paper

6) Evolving the Funding Process

Update Your Funding Process for Agile, Lean, and DevOps

Traditional IT and project funding models pose a critical business risk and, if not changed, threaten the survival of technology-based organizations. Balancing the high-risk investment of innovation (research and development) with traditional business-as-usual tasks has always been tricky for corporations. Too much risk could, in the event of a sudden failure, lead to a company’s dissolution; too little innovation and the company may eventually be overtaken and lose market share to competitors and new upstarts.

Understanding the criticality of funding both innovation and business-as-usual efforts means organizations also need to use the right investment selection process, establish guardrails to avoid misuse, and meet fiduciary responsibility requirements. Organizations must fund the right investments with the right allocations under uncertain conditions, while fulfilling internal and external financial reporting responsibilities.

This paper outlines the conflict between how traditional funding processes handle fiduciary risks and what Agile and DevOps teams need to perform well. It provides three case studies to illustrate new ways of funding that avoid such conflicts.

Download the Full Paper

7) Full Stack Teams, Not Engineers

This paper discusses the myth of the full-stack developer and describes a more sustainable paradigm called the full-stack team, also known as a balanced team or a cross-functional team.

A full-stack team is a balanced team. It has many people, each with a core set of skills plus different specialties. As a whole, the team’s knowledge covers the entire stack. Team members are always seeking to educate and empower their coworkers to help them improve their skills. This creates a division of labor and a healthy system of specialization, and also encourages learning and growth for the entire team.

Download the Full Paper

- About The Authors

IT Revolution

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.

Follow IT Revolution on Social Media

• 
• 
•