Preface to Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book)

This is an excerpt from Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book). If you are looking for an alternative to SAFe, this is it. To those who'd like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book. Go to prior chapter on linkedin. Go to next chapter on linkedin.

-------------------------------------------------------------------------------------------------------

Albert Einstein- We cannot solve our problems with the same thinking we used when we created them.

This is not yet another book on yet another framework. It is both about an approach to help improve organizations and about what I consider to be a necessary shift in paradigms to compete in today's world of disruption. FLEX (FLow for Enterprise Transformation) is not a framework but rather an approach that can both stand on its own, incorporate practices from frameworks or be used to improve frameworks.

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 thinking about how to improve an organization’ ability to innovate and deliver value. It’s actually a double shift. First, it 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 all of the time in the same way that "culture eats strategy for breakfast, lunch and dinner." Lean provides a way of changing the ecosystems within which people work. This provides the means to change culture. It is worth knowing.

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

Shifting From Frameworks to the Work Itself

The second shift I am referring to is shifting our focus from 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 (yes, 20 years in today's world is old) 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.

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 are rarely discussed and attempts to do so are 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 to 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.

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.

And Yet a Third 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. Or at least they have. I think there time has come and gone. But before we look at how to transcend them, it is important to understand why they have been so popular. Their advantages include:

1. they don't require a deep understanding of the principles underneath the practices they espouse for people to do them
2. a well defined starting point, especially valuable for those who want to know what to do
3. well defined terminology
4. the ability to be certified and often teach components of the framework
5. a sense of safety in deciding on the framework because so many others have as well
6. the availability of an army of consultants eager to help

With all of these advantages the dangers of frameworks are easy to overlook. The problems are many. Frameworks:

1. create a focus on the framework instead of the actual work
2. specify some practices that must be followed to be considered to doing the framework. This seems natural but it limits the potential set of practices to pull from. It also has a subtle influence that limits practitioners to think within the mindset of the framework. Frameworks, when presented this way influence people not to go beyond the mindset of the framework. Proponents of these frameworks sometimes recognize this as a shortcoming. Some even acknowledge that the framework is not the end point. But none provide any mechanism for going beyond the framework and therefore the framework becomes an end point in practice.

Using Frameworks

Frameworks should be considered to be a starting recipe for the adoption at hand. But it is important to use the right recipe. Unfortunately, there is not a single recipe (or even a few) that cover all organizations. But there are a few, that when tailored for the organization at hand, can be quite effective. 

Recipes are set combinations of a cooking method. A good cook may use a recipe as a base, but will tailor it for the situation at hand. An immutable recipe creates danger when someone is allergic to some of the ingredients. Frameworks have this same risk - some organizations may be metaphorically allergic to some practices in the framework. 

In this way frameworks can be used as starting that is consistent with the principles of product development. We will transcend this starting point but not violate the laws of software development we discover. We understand that we're applying practices as best we know to fit our situation. We adjust our practices and challenge our understanding of what's beneath them to improve. We don't get attached to what should be transcendent.

This is the big shift from Scrum and SAFe to FLEX. Can you imagine Scrum without sprints? SAFe without big-room planning? FLEX may use those as practices but not as definitions. As we learn, FLEX's practices will adjust and new principles will be discovered. FLEX becomes a body of knowledge that grows as we grow. 

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. 

Where to Go for further conversation

I invite anyone who is interested in continuing this conversation to join the True North Consortium Group where you will find a few like minded folks.

Reflective Quotes

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.

Acknowledgements

This is just the beginning of the acknowledgements. I owe a great deal to many people. However, unlike Isaac Newton's statement "If I have seen further it is by standing on ye shoulders of Giants.” I often feel like I am standing on their ankles. I know I have left much of their knowledge out. Many people read acknowledgements as a means of identifying people who have had an affect on writers and therefore use this as a method for identifying further reading. This set of acknowledgements is not intended for that. Many of those people who helped me on my way I disagree with their work. But I am still thankful for their contribution to me. I will have a resource for further investigation by the reader later in the book.

I want to first acknowledge those who have had the greatest impact on my writing this book. They are:

• my clients
• Guy Beaver
• Luniel de Beer
• Robert Charette
• Alan Chedalawada
• Edwards Deming
• Luke Hohmann
• Corey Ladas
• Don Reinertsen
• Jim Trott

And acknowledgement to many others:

• David Anderson
• Kent Beck
• Jim Benson
• Stephen Bungay
• Ward Cunningham
• Steve Denning
• Fernando Flores
• Martin Fowler
• Israel Gat
• Ron Jeffries
• Daniel Jones
• Joshua Kerievsky
• Mik Kersten
• Dean Leffingwell
• Jeff Liker
• David Marquet
• Robert ("Uncle Bob") Martin
• Kevin Mireles
• Ikujiro Nonaka
• Frode Odegard
• Taiichi Ohno
• Mary and Tom Poppendieck
• Ken Schwaber
• Karl Scotland
• Jeff Sutherland
• Marshall Thurber
• Dan Vacanti
• Mike Vizdos
• David Womack
• another 20-40 coming :) apologies for those who didn't pop into my mind first