We are uncovering better ways of developing software by doing it and helping others do it.
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.
In a nutshell, this book is for people who like to solve their own problems while using the knowledge of others and who are considering SAFe in one form or another or who find it attractive in some manner. These include:
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 using 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 approach.
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 value in 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.
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.
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:
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 was lacking in the following areas:
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:
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).
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
Listed in order they take place in the value stream
These are my observations:
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.
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:
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:
It is important to note that most frameworks’ practices work on these items indirectly. Consider the impact of time-boxing and 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 and 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.
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
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 adopt 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:
FLEX can improve SAFe adoptions for several reasons:
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.