FLEX: FLow for Enterprise Transformation

This is an excerpt from Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book). If you are looking for an alternative to SAFe, this is it. To those who'd like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book. See prior chapter on linkedin. See next chapter on linkedin.

Many companies have decided to "go Agile", but what does that really mean? And what is "Agile at scale"? So before describing FLEX, I want to get clear about what I mean by Agile at scale.

What Is Agile at Scale?

 We first need to be clear what we mean by Agile at scale. We hear it used somewhat interchangeably with scaling Agile, but they are not the same. There are at least three different ways to think of "scaling Agile":

1. Taking Agile at the team and rolling it out across the enterprise.
2. Starting with Agile at the team and moving Agile upstream to our portfolio and product managing area as well as down through ops. That is spreading Agile across the value stream.
3. Taking existing projects & adding more people to them. That is scaling projects by making them larger

Scaling across the enterprise may help at the team level but doesn't address product management or ops issues.

Scaling across the value stream requires new concepts for Lean Portfolio and Product Management as well as organizational development since team dynamics are not the same as organization dynamics.

Scaling projects should be done with caution as most projects are too big as it is. This should only be done after it is understood after Agile can be scaled across the value stream.

Why Agile at Scale

The purpose of Agile at scale should be to increase a company's business agility - the ability to quickly realize business value predictably, sustainable and with high quality. We intentionally say "business" instead of "customer" because who we deliver value to is a business decision. Once we've decided which customers to deliver to we will, of course, focus on them.

 This requires scaling both across the organization and up and down the value stream. We need to go across so we can coordinate teams in different areas that are part of the value stream. And we need to go up and down the value stream so we can remove all impediments to slowing down the realization of value.

 Scaling Agile across the organization is not just repeating what was learned in one area and moving it to others. It also has the challenge of being able to contextualize whatever practices you are suggesting to different types of teams. Scrum was designed for new product development - not something everyone is doing. Kanban can apply everywhere, but it ignores the way people are organized. FLEX is therefore designed to help you contextualize your team approach to the different types of teams you have.

 What Is FLEX?

FLEX (FLow for Enterprise Transformation) is an operating model based on the principles of product development flow (which I'll call Flow-thinking) and Lean-Thinking. Its intention is to help guide organizations in achieving business agility - the quick realization of value predictably, sustainably and with high quality.

It accomplishes this in a guided process that enables us to create an approach contextualized for an organization, while taking advantage of existing process patterns so that no one needs to reinvent the wheel. FLEX can create a set starting point on its own or use an existing framework (tailored to an organization's needs) as a starting point. This starting point can then be adjusted as skills increase, understanding of challenges deepen and as the organization changes. FLEX provides a way to create an emerging framework that evolves at the pace that best suits the organization adopting it.

FLEX takes advantage of other frameworks and methods by considering them as tools to be used as applicable. One can therefore start with a pre-defined framework (such as Scrum or SAFe). This starting point can later be modified based on an analysis of where the organization is and what would be most appropriate for it to use. FLEX is intended to be tailored to any organization. How to improve from where you are is accomplished by attending to established Flow and Lean principles to guide next steps for improvement. This also means that organizations never outgrow FLEX because it incorporates new ideas as they become available.

A Quick Overview of FLEX

“If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen

FLEX guides us in achieving business agility by focusing on reducing the cost of delay in delivering value. "Cost of delay” is what it costs an organization in lost revenue, lost opportunity, increased risks, customer respect, etc., due to a delay in realization of value. Cost of delay can be reduced by focusing the enterprise's capacity on what will achieve the greatest value in the shortest amount of time. It can do this by allocating the organization's capacity to these items of greatest value. This is the effectiveness aspect of the equation. It can also become more efficient by attending to, among other things, the workflow being used, the structure of the teams involved, the size of the items being worked on, the number of the items being worked on, the visibility of the work and the agreements among the people in the organization. How changes are introduced and the roles of leadership and management is also critical.

Before starting a transformation it is important to become clear on the goal we want to achieve - that is, be clear what an effective organization looks like. This enables us you to see what challenges you'll need to overcome to achieve that.  The steps to this are surprisingly similar for different organizations. Although all organizations have differences in culture, objectives, people, and dynamics, we have found that all organizations need to accomplish the following in order to be effective:

1. make agreements across the organization on how to work together
2. create strategies with clear objectives and key results that can be seen across the organization
3. identify the most important business increments to build and to realize value from
4. Organize the development groups around the products, services and internal operating needs of the organization and have the teams work with the Agile approach appropriate for them
5. have a well defined intake process that has clearly defined requirements with acceptance criteria
6. Plan your work in a time frame and manner that enables the greatest amount of value to be realized
7. Add any missing roles necessary to the creation of flow.

The figure below shows these as part of a typical workflow.

The bottom row is an exploded view of a group of teams working together (often referred to as a program). The four, smaller copies of this in the center of the figure represent other programs that are present.

In a nutshell, one discovers what is most important, organizes their people appropriately and allocates the capacity to the most important work. How each of the above actions are accomplished needs to be tailored to the company adopting the transformation. This tailoring does not require re-inventing the wheel as patterns for all of these exist and can be readily applied to the organization as applicable.

FLEX provides us with a mechanism to select what the appropriate methods are for each of these. In some cases, FLEX uses solutions to these challenges that Net Objectives has pioneered that are not common elsewhere. But FLEX also includes solutions from other popular methods such as SAFe, LeSS, Scrum and Kanban.

We must contextualize the solutions provided to the organization while providing a concrete starting point. This tailoring has two steps. An initial phase to get you started and a continuing phase for ongoing improvement. The path to success is guided by attending to your objectives, specific agreements you make with each other, and the practices you follow. These are built on a foundation of Flow, Lean-Agile principles, FLEX's transformation philosophy and natural laws of product development.

It is also important to have people make agreements that are organized around working together, not merely following an approach. These are laid out in our guardrails system.

These steps are illustrated in the figure, "The Components of FLEX."

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 Part VI: Using FLEX to both enhance and simplify SAFe.

FLEX is based on the reality that how to do business development with a software component is now reasonably well known. The challenge is getting people to do what will work. Just saying "follow 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 just 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.
• It is difficult to pivot after starting because of the strong focus on starting with the framework.
• The start by committing to following an approach instead of taking quick advantage of what you learn from a small, initial engagement often drives you down the wrong path.

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 may initially 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. See How FLEX is different from Agile approaches for more.

A six-part approach to a roadmap

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

1. understand the workflow and structure of an effective organization
2. see where you are compared to that
3. understand the challenges you are having
4. identify the potential solutions to these challenges
5. create a roadmap for solving these challenges in the order that will be most effective
6. begin and continuously improve

Progress is guided by two types of metrics. The first is how much value is being manifested. The second is how well you are improving your development methods.