This chapter is being edited by participants in the Adopting FLEX workshop online. Go there for the latest – and to contribute and ask questions.
Albert Einstein- We cannot solve our problems with the same thinking we used when we created them.
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 what I consider to be a 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 is based on what I call “laws of product development” that are often described in terms of Flow and Lean-Thinking. This enables it to stand on its own, incorporate ideas from other frameworks as well as supporting other frameworks. It can be thought of as an explicit statement of what the best way to do product development is. Given its scientific underpinnings, it consistently evolves as we learn.
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 itself is an hypothesis of the best way for an organization to have a customer realize value. As an hypothesis, it should be continuously tested, validated and improved.
- How people react to FLEX must be considered to be part of FLEX (this is a basic tenet of systems thinking, albeit often ignored by most frameworks)
- FLEX must both attend to how to provide a well-defined start and how to extend the start
- It must be based on the value stream so that it doesn’t inadvertently do sub-optimization
- Technical skills must be included in the system and should be considered when deciding on a starting point
- Although users will extend FLEX you never transcend it in the sense that what it’s based on is always valid. People will just come up with more innovative methods to use known principles
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 of FLEX
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:
- they don’t require a deep understanding of the principles underneath the practices they espouse for people to do them
- a well defined starting point, especially valuable for those who want to know what to do
- well defined terminology
- the ability to be certified and often teach components of the framework
- a sense of safety in deciding on the framework because so many others have as well
- 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:
- create a focus on the framework instead of the actual work
- 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.
The Checklist for a Good Framework
Frameworks should have the following characteristics:
- Create a customized roadmap that attends to the needs and culture of the organization adopting it. This includes a customized starting point. Together these avoid a “one-size fits-all” mentality
- Provide a support system used by practitioners to help them solve their challenges
- Is geared towards practitioners becoming self-sufficient
- Is based around the value stream, making it easier to see how well the organization is doing and what they have to do to improve
- Provides a measure of improvement not based on how well the framework is being followed
- Doesn’t require a change in values in order to start. While the framework should help improve the culture of the organization, values change slowly. Remember, it’s easier to work your way into a new way of thinking than think your way into a new way of working.
- Makes explicit how its practices manifest Flow and Lean principles
- Has meaningful certification. Merely taking a class and passing a test just means they learned some information. Courses should include how to train and enroll people in new ideas. 0->60 in 3.5 days is meaningless.
- Does not get more complicated as it evolves. It must be organized in a way that both scope and depth can be added without adding complexity.
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.
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.
Two online FLEX courses are now being offered – FLEX for SAFe, and Adopting FLEX (the first course in becoming a FLEX trainer).
If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.