FLow for Enterprise Transformation

What Is FLEX?

FLEX stands for FLow for Enterprise Transformation. FLEX is the culmination of Net Objectives 20 years of experience in the Agile and Lean space. It incorporates what we’ve learned by working with individuals, small teams, ops, shared services, small to large organizations and the C-suite. It can be thought of as an expert system that also provides concrete examples of what to do.

FLEX is fully described in the companion book Achieving Business Agility at All Scales where it is described as a stand-alone approach.  Since this book discusses how FLEX can support SAFe, aspects of FLEX will be introduced as they are needed.

FLEX is an Operating Model

FLEX is an operating model used to help an organization achieve business agility which is the quick realization of business value predictably, sustainable and with high quality. It includes:

  • How the vision, mission and strategy of an organization ties to technology
  • The workflows used to realize value by the organization
  • The values of the organization
  • Leadership and management methods used by the organization
  • Lean-principles to guide decisions made on who the organization can improve its operating model
  • Metrics used to guide decision making
  • The methods for continuous improvement of the people and the systems within which they work
  • The tools used by the organization
  • The Guardrails system: agreements made within the organization among each other
  • A starting point that fits the organization using it

What Is an Operating Model?

An organization is a complex system for delivering value. An operating model breaks this system into components, showing how it works. It can help different participants understand the whole. It can help those making changes check that they have thought through all elements and that the whole will still work. It can help those transforming an operation coordinate all the different changes that need to happen.

An operating model is like the blueprint for a building. It is more dynamic than a building blueprint, with changes occurring regularly. Also, an operating model is not usually just one blueprint. There are likely to be blueprints for each element: processes, organization structure, decision making, software applications, locations and so on. There are also likely to be some integrating blueprints.

An operating model can describe the way an organization does business today – the as is. It can also communicate the vision of how an operation will work in the future – the to be. In this context it is often referred to as the target operating model, which is a viewpoint of the operating at a future state point in time. Most typically, an operating model is a living set of documents that are continually changing, like an organization chart or the capability model or functional model.

An operating model describes how an organization delivers value, as such it is a subset of the larger concept ‘business model’. A business model describes how an organization creates, delivers and captures value and sustains itself in the process. An operating model focuses on the delivery element of the business model.

An operating model is a representation of how an organization works and is defined and used in order to help make decisions throughout the business development process. A framework is a set of roles, events, artifacts, and the rules that bind them. While frameworks are intended to have practices added to them, the frameworks themselves are mostly immutable. Operating models, on the other hand, are designed to help organizations create their own roles, events, artifacts and the rules that bind them and have these evolve over time as the organization evolves.Operating models should have the following:

  • a “to be” state to provide guidance
  • a method to determine if the operating model is achieving its intended result
  • a support structure to help coaches navigate the challenges that are likely to occur
  • a set of terminology to use
  • a set of agreements on how people should work together (e.g., the Guardrails)

Improving Frameworks with Operating Models

Operating models can incorporate the advantages of frameworks without their inherent disadvantages. There is no question frameworks are very valuable. Their benefits include:

  • they present well-defined starting points so people understand what they are supposed to do
  • if well-established in the industry, they have training available for them and a common vernacular
  • they include proven practices

However, there are also inherent disadvantages. The first is that by definition, since frameworks have a structure that you work from, and since there is no one-size fits all, for many organizations adopting a framework there is a dissonance between this structure and what would best suit the company applying it. The bigger this dissonance, the greater the inefficiency of the framework.  For example, Scrum is intended for when cross-functional teams are both possible and advisable.  If applied in a situation where this is not true this dissonance will cause problems. It will also cause resistance if forced upon teams since it won’t make their jobs easier.

The second challenge with framework is more subtle. When adopting frameworks, people are told to follow the framework until they understand what to do. The challenge with this is that they are not encouraged to think on their own. Instead, while encouraged to improve how they use the framework, they are actually being guided. If the framework does not fit their situation it is even worse because at some point they will discover this, abandon some key practices of the framework but not know what to do.

Operating models work in a different manner – primarily in that they provide insights on how to move forward and make improvements. Using Lean-Agile principles as an operating model for Scrum, for instance as we do with Team-Agility, enables you to start with Scrum’s practices, but change them with confidence you’re making an improvement. It’s not Scrum any more, but that’s not really important.

FLEX can be used to improve frameworks by viewing them as the current point and use FLEX’s methods of improvement to improve how the framework is being used. This book does this with SAFe. Another book in this series (still a WIP) is Lean-Agile at the Team: A Lean Approach to Scrum and Kanban (about 60% complete).  The value of using an operating model on a framework is that it gives you a disciplined way to go beyond the limits of the framework.

Operating models do not require immutable aspects

Frameworks typically require or suggest an all-in-all the way. For example, the Scrum Guide says “Scrum’s roles, events, artifacts, and rules are immutable.” SAFe, while having different levels pre-defines the levels and requirements many of its practices in order to be considered to be SAFe. Both FLEX and Scrum focus on intents of practices. If a practice is not ideal, both FLEX and Scrum provide alternatives to it. The focus is on the outcome, not prescription.

Operating models provide a transition from “As-Is” to “To-Be”

Operating models provide both a “to be” state and a method of getting there. A method for navigating  from “as is” to “to be” is part of the operating model. This requires a method of telling if improvement is being made. The Value Stream Impedance Scorecard was created to provide such a method.

Operating models should provide starting points that fit the organization using them.

An attraction of frameworks is that they provide well-defined starting points. At scale, however, this can be problematic because the number of levels in an organization may not match the number of levels in the framework. At the team level, a single framework will not work for all contexts.

However, the need for a simple starting point does exist. Operating models accommodate this need without requiring immutable component by providing a starting point that can be tailored to the organization adopting it.  An example of such a starting point for Scrum is Scrum as ExampleFLEX also can provide a pre-defined start of roles, events, artifacts and the rules that bind them. This means there is no advantage for a framework over FLEX.

 What operating models add to frameworks

  • A well-defined start that is provided as an example of the next step of “to be”
  • This start can be tailored to the existing organization as needed or desired
  • A well-defined path for improvement that takes less experience than a framework
  • Principles underneath this transition path that provides guidance if the organization should come to a situation where a known solution to their challenge does not exist.
  • They enable a framework to be used anywhere, even if some of the framework’s immutable aspects are broken.
  • There is less likelihood of dogma as people are clear they are working towards improvement, not in following the framework

FLEX Provides Guidance

Although FLEX is not a set approach, it does encompass the needed requirements to achieve business agility. It also provides options for each of these aspects and gives guidance on the proper order in which to implement changes. FLEX is neither a top-down nor a bottom-up approach. It recognizes that work needs to be aligned with the strategy of the organization and that teams need to be able to self-organize. This requires a different kind of management, one where middle management attends to the direction set by leadership and sets up an ecosystem where development can manifest the value desired.

How This Part of the Book Is Laid Out

This part of the book goes through each segment of the value stream. This is not to imply each part is separate or phase gated. But each part does have an intention. The one exception in this format is “the role of the business architect” which ties together product management and implementation. In addition, each chapter will include how the Guardrails are to be used at each segment or role.

  1. Creating Alignment With Lean Portfolio and Product Management
  2. Strategic Planning and Lean Portfolio Management. This is where strategies and initiatives are covered
  3. Enhancing and Simplifying SAFe with Lean Product Management
  4. The role of the business architect
  5. Planning, Collaboration, and Dependency Management. Now that work has been selected to be worked on, this discusses how to plan for its implementation.
  6. Implementation and Integration. How do different teams work together on the implementation
  7. Release and Realization. What do we have to do to release the software we’ve created.