Several years ago, after having done successful transformations of many different companies we discovered that the target state of each company was surprisingly similar. The exceptions to this rule were when external factors (such as FDA or insurance regulation) or concurrent hardware development were present. But even in these cases, those with similar factors had the same conceptual optimal end state.

This is not too surprising after one considers that systems-thinking tells us the system we are in has a strong influence on our behavior. If that the case, and we’re going after a certain behavior (business agility) then it makes sense companies should implement similar systems. This does not mean one-size-fits-all. Rather it means that the objectives across different organizations are similar. How they implement them, and more importantly, how do they go through the stages of implementing them is very much based on the company involved.

The pragmatic view that FLEX is based is a set of explicit beliefs and awareness of certain laws pertaining to software development. These beliefs are not unexamined assumptions, but rather are attitudes that have proven to be useful to have.

What to attend to

Here are some foundational beliefs of FLEX that must be attended to.

1. People must be given a well-defined set of practices when learning something new.
2. No one set of practices works everywhere.
3. Most organizations must implement similar steps before the transformation is accomplished.
4. How to get to this more effective state requires:
   1. Knowing where you are now
   2. Taking advantage of what you are doing well
   3. An awareness of what you are doing less well
   4. An awareness of what you should be doing but are not doing at all
   5. The creation of a tailored road-map that takes you from where you are to where you want to be
5. While a detailed road-map is not possible at the start, the first steps of the roadmap to follow are. Creating and following the road-map is therefore done in an iterative manner, learning from each step before taking the next one.
6. Techniques exist for each of the steps required but which one to use must be selected on the application of Lean-Agile principles to your situation.

What you want to achieve

Where you want to end up looks something like the diagram below. Those steps that have questions marks in them are steps that require the most customization for an organization. Fortunately, FLEX has several options for each step which usually means that after a few conversations which way to go is clear. When that is not the case, the use of Lean-Agile principles can be used to create solutions. The workflow required is shown below:

The steps to achieve this

The path to achieve this, of course, are dependent upon the factors mentioned in Creating a roadmap with FLEX. However, we’ll provide a common example and road map. Most companies having achieved some degree of Agile at the team level are missing three of the steps required for business agility:

1. Clarity across the organization as to what it is investing in. While this is usually clear to executives, this clarity rarely extends down to the team, shared services or ops
2. The definition and sequencing of Minimum Business Increments
3. Using Kanban at the shared services level

These pieces missing from what is normally seen are shown here:

While there is no right set transition in FLEX, the following four phase approach represents an average of past experience. It is also to be clear that these are not distinct phases but typically overlap some as parts of the value stream become ready to adopt new practices. Also, different value streams will transition faster than others.

Phase 1: Defining MBIs

This usually entails learning how to define Minimum Business Increments based on the strategies the company likely already has. Defining and sequencing MBIs (Minimum Business Increments) is essential to be able to allocate your capacity, create line of sight to what is being worked on and to achieve alignment across the organization. Unfortunately, most companies do not use the concept of the MBI. MVPs are useful in entrepreneurial organizations where what value to be delivered is not known, but not of as much value as in established organizations. A blend of the two (discover a new product and enhance existing products) is required. This is shown in this figure.

Phase 2: Defining product manager/owner roles and decomposing MBIs

Going from MBIs to features and stories follows a reasonably well-defined path. But the roles required to do it are not only very company specific, but even value stream specific. At small scale a product owner can handle this. At large scale both product management, product ownership and even business analysts are required. How to define this workflow and roles requires an analysis of where the company is and what a more effective state would be. Defining product manager and product owner roles are required are shown in this figure.

Phase 3: Improving the Ecosystem

A main tenet of systems-thinking is that the organization is responsible for most of the challenges present. This requires a bigger picture view. Management must not only help create a better environment within which people can work, they are responsible for setting the high-level guidelines that people can self-organize within.

Phase 4: Technical Improvement

We don’t mean to belittle the importance of technical proficiency by putting it off to phase 4. Unfortunately, the reality of the situation is that until teams can work on small pieces (that is, do Agile reasonably well) improving technical proficiency will be a high-cost low-return investment. Of course, this phase can be implemented by teams as soon as they are ready – no need to wait for everyone.

The real problem

How to manifest the above is reasonably well know. The issue isn’t what to do, but rather:

1. How to provide an organization with a step-by-step road map to achieve it
2. How to get people within the organization to work towards it

This is based on the experience of working with hundreds of companies and seeing that virtually all of them needed to achieve conceptually the same workflow to be successful. We say “conceptually” because the workflow needed to be tailored for each company. This customization is due to differences in organizational dynamics.

• Culture
• Current adoption of Lean and/or Agile methods
• Understanding of Lean and Agile methods
• Who is driving the adoption
• Clarity on what the company wants to invest in (and what this is)
• The involvement of hardware/firmware in the development process
• The presence of external regulations (e.g., FDA, insurance regulations)

Solving the problem

FLEX is designed to create tailored solutions for particular companies. By acknowledging that culture and factors unique to an organization must be attended to, it is possible to create a step-by-step roadmap for adoption that can manifested reasonably efficient. By being a collection of patterns and thought processes there is no need to re-invent the wheel.

What if you cannot do the right thing

The above example assumed that you could start with the business stakeholders. Unfortunately, this is often not the case. More often, people start at the CIO/CTO level or one below him. In that case, you probably have to start at Phase 3 above. Then do Phase 4 and work up doing Phase 2 then Phase 1.