Simplifying SAFe? With FLEX: An Enhanced Approach to Achieving Business Agility

This is the introduction from my upcoming online book Simplifying SAFe? With FLEX: An Enhanced Approach to Achieving Business Agility. FLEX is Net Objectives' Lean-Agile approach to helping organizations improve at all levels. While FLEX stands on its own, this book explains how to use it to enhance while simplifying SAFe. Feedback is requested either here on a user group I've set up for the purpose. If you're interested in attending an online workshop on FLEX please let me know. You can see more on linkedin by going to the Table of Contents.

--------------------------------------------------------------------------------------------?

This book is not about yet another framework. As a forerunner in most popular Agile methods I have somewhat become disillusioned with frameworks. While Agile suggests we need to respect and trust people, all Agile frameworks provide a set starting point and suggest you trust the consultant who is leading you to guide you to a better way. I have long said you should never trust a consultant (including me). Not that you can't trust their intentions. Rather, my experience is that people need to figure things out for themselves. Not because they will resist if they don't, but if they are told what to do and run into challenges they will either persevere when perhaps they shouldn't or will abandon the process figuring the consultant was wrong. 

There is another way - arm people with a knowledge of the patterns of challenge and success that have been discovered over the last 2 decades of Agile and 6 decades of Lean Product development. People may not have as much experience as I have in these topics but most have many years in product development and virtually all have more experience in what's needed in their company than I have. 

This book is about taking your experience and combining it with what is known about how to change by doing more effective product / IT development which can change culture. It will convey an approach to take to make your organization more effective. It is also generally applicable. Most of the time spent in development is wasted time - schedules not kept to, unexpected work that comes up, features that weren't useful and many more challenges. In many ways this is about minimizing the creation of waste that is somewhat inherent in any human endeavor.

But this book won't leave you to reinvent the wheel in what practices to take or how to manage work. I have learned that most people want some degree of structure and an established starting point. How much of this you want is up to you. But the book is designed to help you take a subset of SAFe, supplemented by a more powerful, but simpler, Lean product development approach, as a starting point. It provides you with a way to continuously improve after you've started. However, the book can also be used for you to create you own approaches if you like. 

I like Jerry Sternin's observation - "It is easier to work your way into a new way of thinking than think your way into a new way of working." If you have an Agile mindset already, this book should arm you with doing tools while also helping you to help others shift to a more Agile mindset by providing them insights to "work their way into a new way of thinking."

This book is based on Net Objectives' two decades of experience in helping organizations improve with Agile methods. As Agile has moved to larger organizations we have become convinced that the Agile mindset alone is insufficient to make this leap. This should not be a surprise if one carefully reads the Agile Manifesto and notes that all of the values and principles are about the team with business being barely mentioned and management not being mentioned at all. While we embrace the Agile mindset where it is useful, this book is really about how organizations can become more focused on what they should be doing and how to do it. 

This book is based on Lean - focusing on value delivery and eliminating waste to speed that up. We'll get into Lean in several ways. SAFe is mostly consistent with Lean, of course, building on many Lean principles. But it doesn't go deep enough and doesn't incorporate flow as well as it could. We will. Lean provides us with great insights into what causes challenges in organizations. By taking a systems thinking approach, combined with Lean principles and patterns of challenge and solution we can see our problems in a different light.

In a nutshell, we'll take the core of SAFe that attracts many people to it - Agile Release Trains, the program increment and its associated planning event, the ART inspect and adapt and a few others. But instead of using SAFe's Lean Portfolio and Agile product management system I'll present an approach that is more powerful while being simpler to understand. This is not a new approach - we've been using this since 2006.

In many ways, this book is a compendium of my 48 years of software development ranging from grunt programmer to C-level consultant. My approach as a consultant is always been to provide the insights of my experience so people can solve their own challenges. But I believe this book can help you take your own knowledge and experience and provide you insights to help you solve your challenges on your own.

The Shift from Frameworks to Operating Systems

I have compiled Net Objectives approach into what we call FLEX - FLow for Enterprise Transformation. It is not a framework in the normal sense. It is actually more of an operating model in that it provides insights into seeing where you are, what options you have for improvement and how to tell if an improvement was achieved. But it also includes set practices so that people can know what to do at any point in time. It can be thought of as an expert system - one which can incorporate anything that is of value. FLEX is really the distillation and explicit statement of what I've learned by doing things myself and by watching other do. In this sense FLEX has no boundaries. But it not overwhelming because it is structure to be learned in layers as it is needed.

FLEX is based on a different mindset than current frameworks. Most frameworks have a set structure within which you can add practices. People want to know what to do and frameworks provide this. But the pervading idea is that at the beginning people must just adopt the framework. This has two bad side-effects which I believe are the causes of much of the bad Agile we see out there. The first is that the framework rarely fits the organization perfectly. A slight variance is not bad, but the disparity between the framework's starting point and what would fit them better creates a dissonance. This not only hurts effectiveness but often creates resistance because the dissonance will create extra work for people who are already overloaded. The second side effect is that you are subtly teaching people to follow.

The way to solve these two challenges is not difficult but takes experience. The first is that some method of tailoring the framework or starting point must be used. The second is that you always emphasize the why of any practice and provide a method for improving or substituting it when challenges occur. Both of these can draw from the deep experience 20 years of Agile now provides - giving us patterns of challenge and success.

How FLEX Can Simplify While Enhancing

I have long considered elegance as "enhancing something while making it simpler." While SAFe has many proponents and antagonists I don't think anyone would consider SAFe elegant. As SAFe has added new insights, practices, roles, events and more, it has done so in an organic fashion. SAFe in 2012 was mostly about the program level with a little on the portfolio. As it has grown it has added new concepts, new levels and more. But SAFe has been designed by attaching these to the level in the organization. This somewhat requires it to become more complex as things are added. SAFe attempts to simplify things by having levels. But this ends up just leaving things out that are actually needed.

This approach is common in the Agile space. I believe it is an ineffective approach that revolves around the team or even uses the team as building blocks. Yes, teams are critical and sustained agility is not possible unless teams are effective and Agile. But Lean provides us with a key insight of systems-thinking. Teams are part of the system. There are many ways teams are adversely affected by what is outside of them. But this also means that it is possible for these outside factors to positively impact them.

One of the reasons SAFe can work is that it limits the amount of work hitting teams. The program increment planning event acts as a gating factor enabling programs to pull when they have capacity and to avoid having too much work in process (WIP). This provides us with a clue to a better way of defining SAFe - one that this book will focus on. This is to attend to the entire value stream (using Lean's meaning here and not the way SAFe has subtly re-defined it). In other words, we need to attend to how we identify, decompose and sequence the work before it hits the teams. Regardless of your scale, this is important.

FLEX is designed around shortening the time from concept to realization for work being done by an organization. It focuses on flow of the work. It has a much simpler model for doing this that is more effective because of its simplicity. It is better to have an approach from end-to-end that you fill in as needed than to just take subsets of concepts and jam them together.

This book will take what is good about SAFe (mostly at the program level) and substitute our proven Lean Portfolio and Lean-Agile Product Management approach on top of that. The result is both simpler and more effective because simplicity, while still being complete, creates better opportunity for alignment.

Chapter Contents

• Who This Book Is For
• Different Levels of Scale
• My History With SAFe and Why I Wrote This Book
• Common Challenges Organizations Have When Adopting SAFe
• The belief system on which we are working
• What Parts of SAFe I Will Build On
• Improving SAFe With FLEX
• Why FLEX Can Improve SAFe Adoptions

Who This Book Is For

In a nutshell, this book is for people who people who like to solve their own problems while using the knowledge of others. This book is intended for people who are considering SAFe in one form or another or who find it attractive in some manner. These include:

• whose organization is currently use SAFe and are having some challenges with it, particularly in the area of Lean portfolio and product management (regardless of the SAFe level being used)
• who are considering using SAFe but are not sure if it suits them
• who are in a small to mid-scale organization and see some things that are attractive about SAFe but are looking for a lighter weight approach

This book is not about SAFe but rather how SAFe's adoption can be guided by Lean-Agile methods using Net Objectives' FLow for Enterprise Transformation (FLEX). I am not trying to sell you on SAFe. In fact, my own preference is to use FLEX directly as it can incorporate any of SAFe's (or LeSS's) practices in it. 

The heart of our approach is using Lean principles to guide business stakeholders, product managers, product owners, teams, ops, support and marketing (and anyone else who is needed) in how to make better decisions to achieve business agility – the quick realization of value predictably, sustainably and with high quality.

FLEX is the accumulation of years of large scale adoption by Net Objectives consultants (since '05). The combination of SAFe and FLEX allows for tailoring SAFe to a company's needs without losing any of the guidance provided by SAFe. It also allows for better training since small to mid-scale companies don't need to learn all of SAFe yet need concepts from all of the levels.

How To Read This Book Based on What You Are Trying to Learn

If your organization is currently use SAFe I suggest you pay particular attention to FLEX’s Lean portfolio and product management approach. We have been using this for over 10 years and it is very mature, while being much simpler than SAFe’s.

If you are considering using SAFe consider how to take what’s attracting you to SAFe but to use it in a more Lean-Agile method.

If you are  in a small to mid-scale organization you probably shouldn’t be using SAFe as it was designed for larger organizations. But there is an advantage to taking advantage of many of SAFe’s terminology and practices since it is becoming somewhat of a standard in the industry. Therefore you should see what you want to take and what you want to add to it and what you want to discard.

Different Levels of Scale

Scale is not really defined by the size of a company but more by the relationship of business stakeholders to the teams involved in building what they want. We view scale as occurring at the group level in a company. Many companies with thousands of developers in technology are not really large scale if they are comprised of independent sub-groups.A company may have one development organization or several. We think of scale as being at one of five levels:

No-scale.  This is when a group of developers comprise just a handful of teams and are driven by one product owner. They are small enough to collaborate with each other and don’t need to use any services from other teams. In other words, they are fully cross-functional and can take business requests and release and support them on their own. Typical development group size of less than 30.

Small-scale.  This is when the group is driven by a handful of product owners and many of the teams require some help from others. It is likely that some degree of shared services (e.g., business intelligence) and ops is used in common across the teams. The product owners are able to coordinate amongst themselves to provide a shared backlog for the teams to pull from. Typical development group size of 25 to 125.

Mid-scale. Several business stakeholders are driving initiatives. A handful of product managers are needed to coordinate with these stakeholders and act as their agents. Product owners act as liaisons between product management and the teams. Shared services are almost certainly present and teams are likely organized into mostly independent programs. Typical development group size of 100 to 1000.

Large-Scale. Multiple mid-scale organizations with common shared services and ops. Each mid-scale organization has its own shared services and requires shared services for the entire organization besides. Each program competes for funding from one main budget. These may represent a division in a very large company. Typical development group size of 600 to 2000.

Very Large Scale. A technology group that has multiple large-scale divisions that share some needed capacity.

What This Means

Clearly there is a transition from no scale to very large-scale. There are two things to attend to here. When looking at what it takes to go from concept to consumption, about the same concepts are required – regardless of scale. As scale increases the number of steps to manifest these concepts and the number of people involved goes up. But in all cases there is the need to take a concept, identify it as important, determine what part of it should be built and how we should build it (new products, extensions of existing ones and replacing products have different ways of being built), allocating our capacity, managing conflicts for capacity when more than one item is being worked on, and so on, are needed.

The bottom line is that even though the scales of the company have great variance that all companies have the issue of portfolio management. In particular, how do you decide what to work on and apply limited capacities to it.

My History With SAFe and Why I Wrote This Book

The year was 2012. I had been on the forefront of Scrum, XP, Kanban and our own Lean-Agile methods for scale. As far as I knew, Dean Leffingwell and Net Objectives had done more successful large scale Agile transformations than most other consultants combined. I had set up a meeting with Dean to discuss a partnership in using Lean-Agile methods for large organizations. It became very clear to me that Dean was a much better marketer than I and his book was more recent than mine (Lean-Agile Software Development: Achieving Enterprise Agility). I decided to join forces with Dean instead of having our two companies compete with each other.

There were several things I found attractive with SAFe:

• it discussed Lean principles
• it took an holistic view
• it discussed the role of management
• its program increment planning event
• its well documented use of cadence and synchronization during the program increment
• it at least mentioning architecture
• it had methods of training large groups together (I knew this increased collaboration)
• it was open to Kanban
• it had a lot of supporting documents available on their website

virtually no one else at the time had many of these (or even any of these).

We had a more refined approach at the time but we had never written it up. Our Lean-Agile Software Development: Achieving Enterprise Agility had come out a few years earlier, but wasn’t up to date with our thinking (although probably still ahead of the current time).

My thoughts at the time was that SAFe at the time was lacking in the following areas:

• Lean portfolio management
• Lean-Agile product management
• how to work with shared services
• architecture
• not understanding value streams
• an all-in all-the-way approach that wasn’t always the right way to go
• incomplete management and change agent support

But it was far ahead of anything else in the Agile world. I figured putting our energies together would help both us and software development in general. Net Objectives became contributors to SAFe and I was the first non-SAI SPCT (instructor for the SPC class, or Implementing SAFe as it is now called).

Looking back I see an over optimism at the start. While some of the improvements I had hoped would be made to SAFe (e.g., Kanban) the significant ones were not. The lack of tuning to culture, a creation of levels somewhat tied to organizational structure and size, and most importantly, a fairly inadequate portfolio and product management approach has left me somewhat disillusioned. After years of attempting to improve SAFe from within I have come to the conclusion our paths are too divergent (and continuing to diverge) because of an underlying philosophical difference on how frameworks need to be defined. This is why we recently broke off our partnership with SAFe. While it still has much to offer, it has become more complex than needed and still lacks a top quality portfolio and product management approach.

What’s also happened is that companies for which SAFe was not designed, are now using SAFe as a basis for their approach. This has led many small to mid-scale organizations to both consider and adopt SAFe. Unfortunately, SAFe has tied many of their product management concepts (e.g., solutions, MVPs) to the top levels of a large organization. That is, full SAFe, which contains many concepts all organizations need, is designed assuming a large organization is using it.

But small organizations have a need for these concepts – they are just not as complex at the small scale. We take an approach where all of the concepts are present, but perhaps not with as many players involved. As an organization grows the concepts can expand without having to shift to a new level.

Net Objectives is particularly suited to write a book about SAFe by someone not doing standard SAFe training. As contributors to SAFe, former gold partners, our CEO having been the first non-SAI SPCT and having had a framework as advanced as SAFe’s for over 6 years when SAFe came out, we understand SAFe and what it needs to do as well as anybody. However, we are not attached to it, so can provide unbiased advice.

While we do provide workshops and consulting to companies doing SAFe we have abandoned using SAFe out of the box or their training materials for several reasons:

• SAFe has gotten very complex and is using standard industry terms in overloaded and ambiguous ways
• Many small- to mid-scale organizations (technology <1000 ppl) are looking to Essential SAFe even though it is not a good solution for them
• Many orgs are looking to take “SAFe out of the box” which has never been our approach and we do not think it is a good idea
• SAFe training is not tailored to the size of the organization that will use it

While I was taking Implementing SAFe 4.6 in December of 2018, I realized that SAFe and Net Objectives are on divergent paths. Many organizations, particularly in the small to mid-scale, do not realize there are other options to adopting SAFe than those espoused by SAI. This book is our way of providing these options (along with our services and workshops, of course).

Common Challenges Organizations Have When Adopting SAFe

This section lists the challenges the book provides insights into solving. We’ve presented them as statements we’ve heard SAFe practitioners tell us.

General areas of challenge

• “We don’t believe we’ve got our Agile Release Trains formed properly.”
• “Essential SAFe helps with some of our problems but we can’t figure out how to do Lean Portfolio management and we don’t want to go to Portfolio or Full SAFe.”
• “How exactly is management supposed to work?”
• “We don’t have clarity of what’s more important for our shared services team to make decisions on what they are supposed to do when different people make demands.”

Listed in order they take place in the value stream

• “Stakeholders don’t agree on what’s most important. Each sets a different business value that the others disagree with.”
• “We aren’t building new products for early adopters and if we were I wouldn’t want to wait 3 months to pivot but don’t know how I’d change a plan mid-program increment.”
• “The use of MVPs, MMFs, solutions, capabilities, value streams and more is confusing. The terms seem to be overloaded, used differently in different context and more complex than necessary.”
• “SAFe still seems to miss the role of the business architect. Who is responsible for attending to the cost one new feature may have on another?”
• “We still can’t get clear requirements.”
• “We’re only 100 people in technology. We don’t want to plan 3 months out. We also don’t feel we need to plan together before every increment. Can you teach us a way to plan once, and then plan on a continuous basis?”
• “How do we run Kanban for shared services or for individuals who have to support more than one team?”

Technical Agility

• “Can you give us more information on how to implement intentional architecture and the architectural runway”

Training

These are my observations:

• For small to mid-scale training on all the levels while leaving things out needed at the Essential SAFe level is wasteful
• Lacking a test-first attitude in initial team-level training (discovery and specification levels) contributes to poor requirements

The Belief System On Which We Are Working

When undertaking any improvement endeavor, it is important to understand the belief system underneath it. These belief systems are, unfortunately, not clearly laid out by their proponents. But they are very important. For example, waterfall is based on the belief that one can plan ahead, that phase gates increase quality, that focusing on people’s utilization is a way of creating productivity amongst others. Scrum, while based on Agile values and principles also is based on the belief that if you adopt Scrum’s roles, artifacts, rules and practices that this will have you learn how to become Agile. This, of course, hides the belief that it works most everywhere and that learning by doing a set of practices will get you what you need.

Our belief is that these unexplored belief systems are not always correct or appropriate for where the frameworks are being applied. Our approach, FLow for Enterprise Transformation (FLEX) is based on several beliefs. It is worth taking a few moments to see if you agree with them or not.

First, FLEX is based on Lean-Thinking, which incorporates systems-thinking, as it is currently the best body of knowledge that assists in organizations achieving business agility – the quick realization of value predictably, sustainably and with high quality. However, FLEX is not limited to Lean. Here are most of the belief systems on which FLEX is based.

Frameworks must:

• be clear about the goal of what people using the framework is for
• not exclude anything of value, nor should it mandate particular practices as not all apply everywhere.
• provide a method to define a good starting point for organizations when they start an improvement program
• provide a method to improve the practices, roles, events and artifacts from this starting point that can be used by the practitioners as needed
• provide a set of agreements that people make that are directly aligned with the goal of the organization than to just agree to follow a framework that has been settled up
• The lessons of complexity and chaos theory is that no matter how well we think we understand a problem we cannot be sure of the outcome. This implies that we must always get feedback and course correct as soon as we can. This does not mean that we can’t make reasonably accurate predictions about whether something will be an improvement or not since we can take advantage of the patterns of challenge and solutions that are known regarding developing value with a software development component to it.
• There are sets of practices that relate more to how people interact (e.g., daily retrospections) and sets of practices that relate more how the work needs to be done (e.g., use small batches). When deciding on practices of the first type, one must be very careful to attend to the organization involved. However, practices of the second type are fairly universal.
• We can create a model that tells us if changing practices will improve our methods (and again, these must be verified).
• Take advantage of what people know – acknowledge that even if they haven’t been doing Lean or Agile the work they’ve done can provide them insights on what is needed
• Practices should either be defined to be about our real intentions or at least be clarified as indirectly working on something of value. For example, cross-functional teams, in and of themselves are not Agile, but contribute to lowering delays in workflow, increasing collaboration and many other things that are Agile.

Delving Deeper

The last bullet above requires going deeper.

It’s important to understand what really needs to be worked on. Experience has shown that virtually all workflow problems can be distilled down to delays in:

• workflow
• feedback after a decision or activity
• value realization
• knowledge transfer

These all not only delay value delivered but they literally increase the amount of work to be done. Lowering them is critical and can be done by:

• Managing queues
• Having small batches
• Creating visibility
• Automating testing
• Having a test-first attitude at acceptance and unit level

It is important to note that most frameworks’ practices work on these items indirectly. Consider the impact of time-boxing & retrospectives.

There is no reason not to work on these directly. One, of course, can add this to most any frameworks, but be forewarned, doing so will likely lead to activities inconsistent with the framework.

My belief is that frameworks should be designed by working on these issues directly & giving practices that support them as a starting point. Then as people learn more they can refine their practices. That way we can use the framework but not be limited to its practices while still being clear whether what we’re doing is good or not.

What Parts of SAFe I Will Build On

SAFe has many good aspects to it. I wouldn’t have become a contributor, SPC, and gold partner if there weren’t. We’ll take advantage of these. Many of these, however, are not fleshed out enough, in which case I’ll provide additional information. Here are concepts we’ll be building on with references to SAFe’s site for more information if you are not familiar with them. I repeat them here, along with how I’ll elaborate on them

• Lean-Agile Principles.  SAFe takes a subset of Don Reinertsen’s The Principles of Product Development Flow: Second Generation Lean Product Development. With the exception of principle #3 Assume Variability; Preserve Options, SAFe’s description of Mr. Reinertsen’s principles are reasonably accurate. See SAFe Principles for more.
• The program increment planning event. While I still consider this to be the best part of SAFe, there are several ways to run these – based on the organizational structure of the company, what software is being built and the culture of the organization. This is an area that you don’t need to be familiar with as we’ll go through this later in the book.
• Cadence and synchronization during the program increment. Again, while awesome, there are different options that are particularly well-suited to small to mid-scale. See Principle #7 – Apply cadence, synchronize with cross-domain planning.
• Roles of the product manager and the release train engineer.

Improving SAFe With FLEX

Over the last 10+ years, Net Objectives has created a framework called FLEX (FLow for Enterprise Transformation). Unlike other frameworks, FLEX is based on objectives and how to meet them with Lean-Agile principles. FLEX uses Scrum, XP, SAFe, Kanban and other frameworks as tools in its toolbox. It also has a well-defined method for determining if a change will be an improvement or not. This enables users of FLEX to start with pretty much any prescriptive framework desired but then adjust it as needed.

While FLEX can stand on its own, it can also be used to improve other frameworks, SAFe in particular. Besides providing a deeper understanding of why SAFe works, FLEX also provides a much simpler, yet more effective, Agile Product Management system than SAFe.

FLEX will be introduced later in this book when it’s concepts will be helpful. This book starts by discussing inherent challenges in developing products and/or services with a software component. It will then describe how to tailor SAFe for small to mid-scale organizations. In particular, these sections are designed for people considering adopting Essential SAFe as their full or partial SAFe adoption. The book will then build on this to show how to adtop SAFe for large-scale organizations.

If you decide that directly using FLEX as an approach, you can read Achieving Business Agility at Small to Mid-Scale (Book in work).

There are several ways FLEX will help with these issues by providing:

• a simpler, yet more effective Lean Portfolio and Product Management approach
• guidelines on how to adjust training to people
• deeper understanding of how to apply lean principles
• test-first thinking (not unit TDD) which is essential for clear requirements
• scorecards to help you make improvements
• Lean management
• Agile architecture

Why FLEX Can Improve SAFe Adoptions

FLEX can improve SAFe adoptions for several reasons:

1. it’s mindset (described above) provides a better basis for companies to use than taking a framework as is
2. it’s designed around the value stream and therefore can be used at all scales
3. it has a more advanced and refined Lean Portfolio and Product Management system that works at all scales
4. the above reasons enable FLEX to grow as the organization grows without having to change adoption levels

SAFe is designed for getting masses of organizations up on Agile. If that’s your goal, you should consider it. But if you are wanting to take a more Lean-Agile approach and see how you can adapt SAFe to fit your needs, then FLEX can help.

FLEX focuses more on the actual work to be done than on the framework itself. This enables a simpler, more flexible framework.

I will be leading an online course on FLEX beginning in mid-January. It will cover all of FLEX, including the content regarding SAFe in this book. It's the equivalent of a 4-day course for only $795. Message me if interested