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.
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:
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:
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.
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.