FLEX: FLow for Enterprise Transformation

Related Pages


Provide Feedback
How to navigate FLEX. This site has been designed so you can self-navigate to your topics of interest. The top level is this page and the Steps of FLEX to the right. Go through and read each of these pages first, visiting links on a page only when you don’t know a term or when you want to go deeper right then and there. Each page also has Resources on the right that go deeper into related topics but are not needed for an overview of FLEX.

The goal of a company’s transformation to Agile should not be to follow a predefined, one-size-fits-all approach but to improve the company’s business agility. Business agility is the ability to realize value quickly, sustainably, predictably and with high quality while always having the ability to pivot efficiently.

FLEX is based on systems and Lean-thinking as applied to the development of software. It incorporates the knowledge of many leading experts in the Lean and Agile space for the past two decades and continues to evolve as we continue to learn more. FLEX solves the challenge that people want (and need) to be given a concrete, proven method while recognizing no one single framework can work for everybody. By taking advantage of patterns of challenges and success, FLEX enables experienced transformation agents to create a customized path for their organization to improve their business agility.

Figure 1 illustrates a typical development flow.

Figure 1. Typical development flow.

FLEX can be used for any size organization. We call it an ‘enterprise’ transformation because FLEX addresses issues from the beginning of the value stream through deployment. The value stream can be thought of as all of the steps that your work goes through from the initial concept until the value is realized.

FLEX can stand on its own or can be laid on top of methods such as SAFe® (either to enhance it or to use it as a guideline). If you are doing SAFe or considering it, see the FLEX and SAFe® page.

FLEX is based on reality that how to do business development with a software component is reasonably well known now. The challenge is getting people to do what will work. Just saying “do this” doesn’t work. To improve an organization’s methods, one must attend to:

  • Current organizational structure
  • Culture of the company
  • Capacity of the people to absorb change
  • Who is leading the change

FLEX takes what is known and provides a way to make a customized roadmap for a company’s transition. FLEX is not limited to any one approach but incorporates what works from all other methods. FLEX’s power is in how it makes those practices available to the current context in which it is being used.

Using FLEX

One of the key aspects of FLEX that differentiates it from frameworks such as SAFe, LeSS, DAD and Nexus is that it is not a framework but more of a way of thinking and an approach to manifesting improvement.

​FLEX acknowledges that people need something concrete and well-defined in order to start. At the same time, taking an all-in all-the-way approach to a predefined method has the following disadvantages:

  • No one-size-fits-all so you are almost certainly committing yourself to an approach that is not tailored for your organization.
  • The commitment required does not allow for pivoting after a quick start.
  • You typically start by committing to following an approach instead of taking quick advantage of what you learn from a small, initial engagement.

You should undertake an Agile engagement in an Agile manner. That is, do something small, learn, adjust do something more. This eliminates this seeming dilemma by providing people in the organization a straightforward, well-defined improvement step to begin with. Once enough progress has been done, the next step can be defined. While FLEX does require someone with experience to guide you, you can quickly learn how to guide yourself since it is based on principles and laws of software development. Once these are understood, you can determine your own path.

A four-part approach to a roadmap

While avoiding prescribed solutions, FLEX suggests a four part approach to creating a customized roadmap that builds on patterns of success. Here are the parts:

  1. ​​Understand your value stream.
  2. See the challenges to what you are trying to accomplish.
  3. Learn potential solutions to these challenges.
  4. Create a step-by-step road map for solving these challenges.

You will do this in an Agile manner: lay out a roadmap with a few steps, doing them and learn, adjust, and move forward.

First, seeing where you are and understanding your challenges. By being clear about the intentions these challenges are impeding, you select a roadmap for manifesting the improvements you want.

Progress is guided by two types of metrics. The first would be how much value is being manifested. The other is how much waste is the way you are doing your work causing.

FLEX provides us with a method to tell if we are reducing this waste or not. When learning how to drive a car, one of the first things you must learn is “how well are you keeping the car where it should be.” That is, are you in your lane. Yet, most frameworks guide us by how well we follow the framework. Our goal should never be to follow a framework but rather how well are you in adding value to your company and your customers. One aspect of this that you need is an understanding of the resistance you are facing. By lowering this resistance you will get more from your efforts. This is the purpose of the value stream metric.

All resources in FLEX

Achieve Alignment Across the Organization (Article)
Analyzing Capabilities and Challenges (Article)
Continuous Integration / Continuous Deployment (Article)
Create Visibility (Article)
Creating a Roadmap with FLEX (Article)
Define What Represents Value for the Business and Its Customers (Article)
FLEX FAQs (Article)
FLEX Steps for Transformation (Article)
FLEX Updates (Article)
FLEX's Philosophy of Transformation (Article)
FLEX: FLow for Enterprise Transformation (Article)
Go for Understandable, Not Simple (Article)
History of FLEX (Article)
History of FLEX from Insights Learned (Article)
History of FLEX from Quotes and Insights (Article)
How to Start with Acceptance Test-Driven Development (Article)
How to Use Scrum in Mid to Large Scale Organizations (Article)
Improve the Efficiency of the Technology Group (Article)
In Transformations, Attend to Human Psychology (Article)
Introduction to Team Agility (Article)
Iteration Planning Meeting (Article)
Manage Work-in-Process (WIP) (Article)
Minimum Business Increments (MBIs) (Article)
Properly Sequence Work (Article)
Refine the Product Backlog (Article)
Resources for FLEX (Article)
Scale: What It Is, Why It Is Important (Article)
Scrum as Example (Article)
Select the Value to Realize (Article)
Start at the Team or Start With the Value Stream? (Article)
Supporting Information Relating to Change and FLEX (Article)
Systems Thinking Philosophy as it Applies to Frameworks, Methods, and Approaches (Article)
Team Agility Objectives (Article)
Technical Agility Roadmap (Article)
Technical Debt from a Systems-Thinking Point of View (Article)
The Basis for Deciding on First Steps in a Transformation (Article)
The Foundation of FLEX (Article)
The Intention of Iterations, Time-Boxing, and Flow with Cadence (Article)
The Interesting Parallel Between SAFe and the Kanban Method (Article)
The Pickup Sticks Model of Teaching (Article)
The Systems-Thinking View of Simple, Complicated, Chaotic, and Complex (Article)
Understanding the Pull of SAFe (Article)
Use Full DevOps (Article)
Using MBIs in SAFe (Article)
Using the FLEX Mindset and Experience to Determine What Must be Done (Article)
Weighted Shortest Job First (Article)
What Is Lean-Agile? (Article)
What to Say When Someone Just Doesn't Get It (Article)