The best way to learn something new often is to contrast it with something known. This page describes the foundation of FLEX by focusing on those concepts and activities that are mostly not in Scrum, SAFe®, and Kanban. While reading, ask yourself if you agree with them.
FLEX is based on the principle that no one-size fits all yet people need an explicit, well defined start. FLEX provides this by taking a four step approach:
FLEX is based on reality that how to do business development with a software component is reasonably well known now. The challenge is getting people to do what will work. Just saying “do this” doesn’t work. To improve an organization’s methods, one must attend to:
FLEX also suggests starting across an entire value stream instead of just part of it. While this may seem ambitious, it affords a greater opportunity for alignment and truly solving some of the key issues involved. Starting at the team level can often be unproductive (Successful Pilots Can Sometimes Harm Agile Organizations). If one can’t start at the front of the value stream it is important to keep influence those deciding on what and how much to work on to enable a broader adoption of Lean-Agile methods upstream.
FLEX is about the objective and how the organization can work together to achieve it. This requires agreements of behavior. FLEX is based on the guardrail system of six agreements that everyone must agree to:
While FLEX provide starting practices, the practices are always placed within the context of the objective. In other words, this practice is being done to meet these larger objectives. So both a bigger picture objective (business agility) and a local objective for each practice, is provided. This enables the substitution of other practices that still meet the objective of the practice being substituted for. This also enables consistency of intention across an organization while allowing people to implement the objective in their own manner.
Although we start with a fixed approach, as organizations adopt new methods, new challenges will occur. In addition, starting practices may not work as well as hoped and there may be other practices that become better over time. It is therefore important to have a method for adopting different practices when it makes sense to do so.
Shu Ha Ri comes from the martial arts and means to follow, break with and then transcend. The challenge with starting with a prescribed set of practices is that people think they are the right practices. They should just be viewed as the starting, or example practices. The framework must encourage substituting other practices that fit the principle above ‘Work to objectives, not focused on specific practices.’ This is done by presenting the alternatives only after people have tried the practices and met with challenge. This requires that the people adopting the practices have been given the objective of the practice. Something that they should be given in any event. At this point, the simple set of tools we gave people can be revealed to be only the top shelf of a much larger tool box.
When we understand the practice’s objective, we can use the following questions to improve our methods:
FLEX is an approach which creates a step-wise adoption approach to achieving business agility – the quick realization of business value, predictably, sustainably and with high-quality. FLEX is designed and continuously improved totally around this objective. It is a cohesive integration of what works. It is not the spawn of one individual and therefore there is no attachment to existing concepts when better ones come along. It is designed to help its adopters think and solve their problems while providing tangible actions to take throughout the adoption process.
Systems thinking means to consider your system as a whole, not a combination of components (see If Russ Ackoff had Given a TED Talk (12 min). Affecting aspect of the system will affect others. In addition, most of the challenges we encounter are due to the system – so our focus needs to be more on the system. Since we respect and trust our people we don’t need to micro-manage them, we just need to create a system within which they can work effectively. Systems thinking also means to consider the entire value stream (PUT IN LINK). If we can’t do the entire value stream recognize then we should attempt to influence that part we cannot directly work upon. Scrum, SAFe and Kanban are partial implementations of systems-thinking.
The scientific method and double-loop learning are the basis for improvement. The attitude is “is this working or not?” “If not, how can I improve it?” In addition to trying to improve our value realization metrics, FLEX provides the value stream impedance scorecard, a way of telling if we’ve improved our system or not. Many improvements require rethinking our assumptions. Double-loop learning has us question the assumptions on which our practices are based. The ubiquitous “inspect and adapt” which is more about seeing how we can do our practices better. On can describe the difference as “inspect and adapt” is how do we get better at what we are doing while double-loop learning has us challenge if what we are trying to do is even correct. impedes double loop learning.
Some of these have already been mentioned (systems thinking, role of leadership and management). FLEX explicitly focuses on removing delays in workflow, feedback, and the time between getting and using information via managing work-in-process and other methods. Visibility of work, workflow, blockages, workload and capacity is another key principle. Building quality in through the use of Acceptance Test-Driven Development, Sustainable Test-Driven Development and automated testing is yet another.
The Agile community has somewhat ignored and/or vilified management. Management is never directly mentioned in the Agile Manifesto, although presumably it is management that is supposed to “give them [development teams] the environment and support they need, and trust them to get the job done.” But management’s job is not just to be servant leaders to the development teams. They have many other duties in conveying the direction of upper management to those doing the work. This is called Middle-Up-Down Management. It has been ironically ignored since the author, Ikujiro Nonaka, is one of the co-authors of The New New Product Development Game on which Scrum is based.
The role of both leadership and management is critical. Leaders need to set direction and management needs to help create the proper environment and tools that align the entire organization. Of course management is working towards the betterment of the entire organization, but no more or less than everyone else in the organization should also be doing.
One of the key tenets of Lean is to make the workflow you follow visible. This does not mean excessive documentation that people have to refer to. This means you make what you are working on and how you are doing the work clear. When how you do your work is visible, it becomes a statement of “this is the best way we know how to do this work at the moment, so we’re letting people know.” This requires making what is tacit be explicit. If you find better ways you just have a new conversation or update your workflow.
This is the opposite of having a process that we try to follow. Following processes are typically an inefficient method of getting things done and carry the risk of not being followed at all. Explicit workflow both facilitates collaboration within a team and is especially essential across teams and silos. It’s actually one of the best ways to break down silos.
If you agree with these principles but realize that the framework/method you are following does not include them you do not need to abandon anything. Just adopt these principles and extend and/or break with the framework/method you are currently using. You don’t need to adhere to someone else’s definition of what you should be doing. This concept is nicely described in Ivar Jacobson’s Kill All Methods, Free The Practices.