A note about this book. This book was about 80% complete when the PMI acquired Net Objectives. We are currently integrating FLEX, Disciplined Agile and Brightline Initiative. These three approaches attend to different issues in improving organizations and were developed independently. However, the underlying philosophies of the approaches are quite compatible and incredibly synergistic. Most of this book still exists in its original form. It is being rewritten in sequence. It is a community effort in that people can read while it is being updated as well as contribute to it with their comments about what they like and don’t like.
This book is for professional consultants and internal change agents who understand that effective transformation takes more than having a set framework to implement.
FLEX, FLow for Enterprise Transformation, is a platform which lays out the steps required for improving the way a company adds value to its customers, both external and internal. It can be used with Disciplined Agile to create a cohesive package that explains the theory, options and specific actions required to improve and organization. It can also be used to improve other popular methods such as Scrum or SAFe, or even to create a totally customized set of practices.
Note: This book is being converted over to the Disciplined Agile Value Stream Consultant. To navigate you should to go the table of contents, view a page and return to it to get to the next one.
Albert Einstein- We cannot solve our problems with the same thinking we used when we created them.
FLEX is designed to work at the organization level, regardless of the size of the organization involved or if only part of the organization is involved. It is designed around Flow-thinking, Lean-Thinking, the Theory of Constraints, and organizational development integrated with how people learn and change habits. It is not an extension of Agile, but does incorporate it at the team level, which is what Agile was designed for.
FLEX is designed to be used as a guide for organizations to achieve business agility – the quick realization of value predictably, sustainably and with high quality. It does this by codifying the author’s 20+ years of experience in Lean, theory of flow, theory of constraints, Agile, Scrum, Kanban, technical agility, organizational development and more in improving organizations.
This book is organized to first present the science and philosophy underneath FLEX. Then it describes what an effective organization looks like and how to achieve what it must do. The book closes with a collection of practices that are useful as well as how to use FLEX to improve Scrum and SAFe. This structure reflects our belief that leaders of a transformation must understand more than just the mechanics, but why the mechanics work. No one size fits all, which to us implies we need to find the right size. All too many frameworks take the simple approach of preset starts. Even implementing a framework in stages, where each stage is pre-defined, is a preset start.
The “why the mechanics work” is investigated from a scientific approach. It is not just posited and then never explored. Nor is it a mere collection of other approaches collected together in the hope of achieving a whole.
FLEX is not a better framework, it is a different kind of framework. It is both about an approach to help improve organizations and about the necessary shift in paradigms to compete in today’s world of disruption. FLEX (FLow for Enterprise Transformation) is a framework composed of groups of patterns that solve recurring problems within particular contexts. It includes “natural laws of product development” that are often described in terms of Flow and Lean-Thinking. Natural laws are laws that exist independent of our thinking. They affect us whether we attend to them or not. There are natural laws that are more about how work is done and others that relate to people. For example, in general, working beyond capacity slows things down.
The Foundations of FLEX
When I started writing up Net Objectives’ 14 years of experience in Agile at scale that has now become FLEX I came from a foundation of the following:
FLEX has been designed to grow and evolve. It attempts to be as explicit about its methods as possible so that we can examine the tenets on which it is founded. Its foundations enable adding more information and insights without adding complexity.
The Four Shifts From Agile of FLEX From
By ‘shifts from Agile’ I’m speaking generically.
FLEX incorporates four shifts in thinking. These are systems-thinking, shifting from frameworks to the work itself, focusing on flow, and attending to organizational development with Lean.
The First Shift: Taking a Scientific, Systems-Thinking Approach
While FLEX can be used within your current way of thinking, it is intended to open a way of thinking that goes beyond Agile and even Lean. It presents a different paradigm for solving problems and how to improve an organization’ ability to innovate and deliver value. The first shift goes beyond Agile’s focus on people and the team to Lean. Lean is a systems-based thinking approach to improve workflows and deliver more value to your organization’s customers. It uses a set of principles that are based on what could be called laws of product development in that they are always worth paying attention to.
A key tenet of Lean is that systems affect behavior and that, since we trust and respect our people, our focus should be on improving our systems. Bad systems defeat good people virtually all of the time in the same way that “culture eats strategy for breakfast, lunch and dinner.” Lean provides guidance on changing the ecosystems within which people work.
Lean, unfortunately, has been viewed as an approach tied to Toyota. This view limits its value since most of us are not only not building cars, but are in software development or IT which is considerably different from the physical world, let alone manufacturing. In my keynote at the 2009 Lean-Kanban conference I spoke about “Lean beyond Toyota” to illustrate how Lean-Thinking now stands on its own in the same way physics has gone beyond Newton. Those who take a direct translation from manufacturing to Lean miss many opportunities in applying Lean. They also create many red-herrings – things that are worth attending to in the physical world, but not so much in the virtual world. Ironically, most of those who best understand Lean have gone beyond it now as I have. We still use Lean, but more as a method to achieve what we’re really going after, which is the second shift.
The Second Shift: From Frameworks to the Work Itself
The second shift is shifting our focus from pre-set solutions to the problems that stand in the way of what we are trying to achieve. While values and practices are good, we must attend directly to what we are trying to accomplish. The focus on practices has gone so far that promoters of frameworks often have their clients measure themselves on how well they are doing them (e.g., Nokia test). Instead, they should be providing evaluations on how well their clients are increasing the amount of value their customers are able to consume from them.
Today requires a different approach to agility than 20 years ago. In many ways the “Agile community” has not been very Agile. It’s changed relatively little in both its curriculum and teaching methods to assist organizations in becoming Agile. Its certification focus has established competing schools of thought where the needed exploration of what must be done or known has been mostly ignored.
Popular frameworks, such as Scrum and SAFe, focus on values and practices with principles being mentioned but given second shrift to the frameworks themselves. Scrum takes a simple approach while SAFe attempts to define most all of the roles, practices and artifacts one would need. This reflects our common “this” or “that” attitude in the community and has resulted in the “Agile wars” which obscure our real needs.
Another reason this second shift is important is because 20 years ago we mostly had early adopters trying to solve the problem of product development at the team. Now we have almost everyone attempting to solve Agile at scale. This is a different set of people with different skills and different mindsets. The Agile of old (20 years in today’s world is ancient) is insufficient for the needs of today and tomorrow. To compound this error, the focus on frameworks, which made sense 10+ years ago, has relegated many skills that should be taught up front now to being presented after the frameworks are taught. This leaves many organizations adopting Agile without the requisite skills needed. But this challenge also provides a new opportunity – there are now thousands of very competent consultants that did not exist five years ago.
Agile is purportedly about teaching people how to self-organize but it usually starts with a preset collection of practices that are immutable. This has been justified by telling people they should start with these rules and then transcend them. But why these are the right set of rules for everybody to start with and how to transcend them is rarely discussed and attempts to do so is viewed as heretical by many.
This focus on telling people what they need to do instead of helping them understand the principles underneath the practices (and in many cases even denying these exist) has led to what many call “Dark Agile”. Unfortunately, many consultants blame their clients with comments such as “what’d you expect, they didn’t do what I told them” or complaining that management and business stakeholders are not properly involved. This has always seemed very un-Agile to me. The issue for me has always been not just what people were supposed to do but how to get people to see why doing that would be in their best interest.
It’s not that I don’t believe in Agile, it’s just that it’s a start. And a 20 year old one at that. The certification craze has caused blind spots that solves some problems while creating others. As I discovered in the work which led to my book on design patterns (Design Patterns Explained: A New Perspective on Object-Oriented Design) the patterns were not truly important. Rather, they taught us to perceive what is real. It’s the same way with Agile, the practices aren’t important, they are merely paths that help illuminate what we are going after.
The same is true for Lean. While I am obviously a huge proponent of Lean, having co-authored Lean-Agile Software Development: Achieving Enterprise Agility, Lean is still a method to achieve results. Our second shift focuses on Flow by using Lean, Agile, organizational development and anything else that helps us get there.
The Third Shift – Achieve Flow
What we are going after is business agility – the ability to quickly realize value for our business and customers in a predictable and sustainable manner. This requires the entire organization to be involved and requires the systems-thinking approach that Lean provides. One important aspect of systems-thinking that has long been ignored by the Agile community is that a system is not its components. Rather, it must be recognized that these interact in a way that creates the behavior we see.
But the nature of these interactions is very complex – meaning that they can’t be predicted. Unforeseen events occur along with unexpected interactions occur. These are sometimes small, even obscure, but cause huge side effects. This is a reflection that product development (creating the unknown) by a group of human beings (by nature unknowable) comprise what is known as a complex system.
Many people have gotten caught up in the theory of complexity going further than what I think is necessary for pragmatic effect. While it is true that complex systems can’t be predicted, there are many patterns of behavior exhibited by them. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath the methods used, it is possible to adjust the behavior of complex systems without understanding the full nature of the principles involved.
We mostly need to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big, undesirable affects (the essence of Chaos Theory). However, instead of giving up and saying we can’t predict things, we can move forward with knowing our understanding is always incomplete. We do, of course, need quick feedback, both of our actions in our work and in any actions we take towards its improvement. Both agility of development and improvement of our methods is required.
Don Reinertsen’s book The Principles of Product Development Flow: 2nd Generation Lean Product Development has ‘Flow’ in the title, with Lean in the subtitle. There’s a reason for this – our goal is flow. Lean is being used to achieve it. When we look at organizations through the eyes of flow we see things that we can’t see through the eyes of values and practices only. Flow is both a goal and a bell-weather of how we’re doing.
The Fourth Shift – Organizational Development
Agile has gone well beyond the team. We need to now move forward with the acknowledgement that we’re working on organizations, not teams. This is not new, of course. Lean management has been working on the entire organization for decades. This shift is partially included in the shift to Flow and Lean. But it is worth pointing out the human aspect of improvements and that we now must tend to both organizational development and culture.
Culture has ironically been difficult because much of the Agile community has been focused on “being” Agile. But what does that mean? No one can really say except that it means being consistent with the Agile Manifesto. But what does that mean.
Behavior reflects beliefs so I think it best to look at how does “being” Agile reflects in the workplace.
“It is easier to act yourself into a new way of thinking, than it is to think yourself into a new way of acting.” Millard Fuller
The Need For and Danger of Frameworks
Frameworks definitely fill an important role in learning. Their advantages include:
With all of these advantages the dangers of frameworks are easy to overlook. The problems are many. Frameworks:
The Checklist for a Good Framework
Frameworks should have the following characteristics:
A Summary of the Shifts from Agile to FLEX
From a focus on individuals to improving the ecosystem within which they work so that their skills can be better utilized and that they enjoy their work better.
From a focus on frameworks to the actual work methods we need to be using that the practices of frameworks are trying to accomplish.
From a focus on “being” to what working together looks like.
From a focus on teams to a focus on the value stream.
From a focus on productivity to a focus on realized value.
From efficiency to removing delays and unplanned work.
From an empirical process to a model that explains what’s happening and provides insights into how we can improve.
From a focus on learning the framework to learning the skills that we need to actually deliver value.
We always need to be learning. Here are some of my favorite quotes that might put you in the mood for reflection while reading.
Buckminster Fuller – I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Our brains deal exclusively with special-case experiences. Only our minds are able to discover the generalized principles operating without exception in each and every special-experience case which if detected and mastered will give knowledgeable advantage in all instances. Because our spontaneous initiative has been frustrated, too often inadvertently, in earliest childhood we do not tend, customarily, to dare to think competently regarding our potentials. We find it socially easier to go on with our narrow, shortsighted specialization’s and leave it to others primarily to the politicians to find some way of resolving our common dilemmas.
Arthur Schopenhauer – The task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about what everybody sees.
Arthur Schopenhauer – All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.
George Santayana – Those who cannot remember the past are condemned to repeat it.
Sinclair Lewis – It is difficult to get a man to understand something, when his salary depends upon his not understanding it.
Albert Einstein – Insanity: doing the same thing over and over again expecting a different result.
Albert Einstein – In theory, theory and practice are the same. But in practice they are different.
Marshall Thurber (paraphrased)- It’s not getting Agile that takes the time, it’s the not getting it that takes the time.
Who this book is for
This book is for people who want to be involved in deciding what they should be doing. If you are looking for a cookie cutter approach with a preset solution, this book is not for you. However, if you want to be given a model in which to understand your challenges and how to solve them, you will find value here. You won’t have to reinvent the wheel – most of the challenges organizations now have are not new and have been solved in one or more ways already.
While useful for anyone who wants to learn about how to improve the capabilities of their organization, FLEX has been specifically designed for the following personas:
FLEX stands on its own but builds all of the popular Lean and Agile methods available today. If you are using SAFe I’ve added a section on how to use FLEX to both enhance and simplify SAFe.
The heart of our approach is using Flow and 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 small to large-scale adoption by Net Objectives consultants (since 2005).
Organization and how to use this book
After a brief overview of FLEX, the book is divided into 13 parts. It is suggested that the book be read in order. However, the reader can skip part 1 if they want to get more into the doing of FLEX. However, the philosophy on which an approach is based is probably the most important thing to learn.
Part I: The Theory Underneath FLEX. FLEX is based on science and a philosophy that people are generally good and that if you provide them with an effective environment they will perform well and get meaning from their work. Part of the philosophy is that you must understand your problem before attempting to apply a solution.
Part II: The Goal Is Business Agility (with exercises). FLEX is designed for an organization, not just a team. While Agile is about getting teams to be effective, FLEX is about achieving business agility across an organization. Business agility is the quick realization of value predictably, sustainably and with high quality.
Part III: The Goal Is Business Agility: What’s in Your Way? Now that we know what we want to achieve, what’s in our way of achieving it. Understanding the inherent problems everyone faces as well as our particular problems is essential.
Part IV: FLEX as a Patterns Framework. Although every organization is unique and requires a unique approach to solving its problems, this does not mean we have to start from the ground up. FLEX takes advantage of patterns of challenge and solution that, after 20+ years of Agile, are fairly well know.
Part V: Using FLEX to transform your organization (with exercises). In this section we create a roadmap and approach specific to your organization.
Part VI: New Roles Needed Some roles above the team level are also needed. I’ll present them here.
Part VII: Agreements We Make With Each Other: The Guardrails The guardrails are agreements made across the team on how to work together.
Part VIII: Topics In Depth – Value Stream Wide These are topics that run across the entire value stream and are presented to deepen what was presented in the first two parts. They are presented in a separate section to allow for quicker coverage of FLEX in the earlier parts.
Part IX: Topics in Depth – Practices These are practices that are useful and are presented to deepen what was presented in the first two parts. They are presented in a separate section to allow for quicker coverage of FLEX in earlier parts of the book.
Part X: Topics in Depth – Teaching and Adoption These are topics that relate to both internally teaching concepts and about how to adopt new methods. They are presented to deepen what was presented in the first two parts. They are presented in a separate section to allow for quicker coverage of FLEX in earlier parts of the book.
Part XI: Using FLEX to Both Enhance and Simplify Scrum. There is a lot of Dark Scrum out there. The reasons for this are actually inherent in Scrum itself – the theory underneath Scrum. This does not mean that Scrum must be abandoned, but that by taking a different attitude about what Scrum is and how we can extend our efforts and have our Scrum teams be more effective.
Part XII: Using FLEX to both enhance and simplify SAFe. SAFe has provided value to many organizations. But many experience a stagnation after an initial productive start. Applying FLEX to SAFe helps you take SAFe to the next level that is surprisingly simpler while being more effective.
Part XIII: Additional Resources on the Net Objectives Portal The Next Objectives Portal has a huge amount of information on it. This Part is an entry point for those reading this book.
The book is laid out this way to enable a quick read through FLEX and using it. The reader can go to the in depth topics when they want to learn more.
There are several different ways to read this book: