Table of Contents The strategies of adoption of current methods The adoption philosophy of Scrum The adoption philosophy of SAFe® What Scrum and SAFe have in common The adoption philosophy of the Kanban Method The adoption philosophy of Shu Ha Ri The dilemma that must be solved FLEX’s philosophy of adoption FLEX’s philosophy aplied to other methods FLEX’s philosophy of learning

The strategies of adoption of current popular methods

There are several approaches to undertaking an Agile transformation. While each approach has its own practices and principles, the strategies of adoption tend to fall into one of two camps:

1. Take a canned solution and apply it. The rationale here is that people need a set, well-defined start. Scrum and SAFe® follow this approach.
2. Start where you are. Create visibility on the current situation, set forth some key principles (e.g., explicit workflow, kaizen-small improvements, managing work in process).

The challenges with the first approach is that you are somewhat teaching people to follow an approach instead of thinking for themselves. The larger the organization, particularly when SAFe is used, the greater this effect. The result is that the adoption starts well but tends to stagnate.

To avoid this, Net Objectives attempted a third approach 3-5 years ago which was based on the idea that people could be provided choices for each major decision that needed to be made. This method had mixed results and has since been abandoned, but what we learned from this and the challenges of the popular methods has led to FLEX’s approach.

The adoption philosophy of Scrum

Scrum is based on the philosophy that it represents a framework that, if followed, will work. Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (Product Owner, team, ScrumMaster) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.

This is reflected in Ken Schwaber’s words, “Scrum is simple, just follow it as is.” This implies that one must start with Scrum as a whole, since a partial implementation will be an impediment in and of itself. The challenge with this is three fold:

1. There is no universal one-size-fits-all. This is true in general, but for Scrum in particular. It is often ignored that the article on which Scrum is based – The New New Product Development Game – was discussing product development by an individual team. Nowadays this represents a tiny percentage of where Scrum is being used.
2. The practices of Scrum are not necessarily the best practices to be being used. Having to follow them often leads to bad Agile. This is why we use Team Agility and think of Scrum as an Example of what is possible.
3. People may not be ready to change as much as Scrum insists. Also, they may like their titles and HR may not have a growth path ready for the new roles Scrum insists you use.

There are other factors as well. See the LinkedIn post, Going Beyond Scrum to Scrum as Example.

The adoption philosophy of SAFe®

SAFe® is based on the “all-in, all-the way” philosophy. Train managers, train the teams, get going. Have a predefined method for everyone to follow and everyone will know what to do. Many times this is the only way to move forward. And in these cases starting with SAFe is perhaps the best option. This would be for very large organizations (1000+ in technology) in our experience. The challenge with this approach, however, even when it works, is that people tend to follow SAFe because that’s how they started. SAFe doesn’t prescribe this, and even recommends against it, but it typically what happens in any event.

SAFe has different levels: Essential, Portfolio, Large Solution and Full. Each of these build on top of each other. SAFe Essentials starts at the program level and the others build up. This has SAFe provide a somewhat complete solution for each level being worked on.

Another challenge is that SAFe is so big that people tend to focus on its components with the assumption that getting all the pieces working will create an effective system. But this, unfortunately, is not the case (see What if Russ Ackoff had given a TED Talk?).

What Scrum and SAFe have in common

Both Scrum and SAFe have the philosophy that you need to start with a set, prescribed start. That only have you understand things can you change the practices. The biggest difference between Scrum and SAFe in this philosophy is that Scrum is a framework defined by its practices, artifacts and roles. Changing them has you no longer doing Scrum. SAFe is a framework defined by the components it has. Plugging and playing new ones is part of the framework.

One concept that tends to be ignored by many in the Scrum and SAFe world is that when you teach people to start by following, it’s not always easy to shift them into learning. The challenge is, that at some point, people will run into challenges with these starting points. Sometimes the starting points were not optimal. Sometimes they are, but removing the impediments is difficult. The challenge is to understand when another practice should be used or when the impediments to the current one should be overcome. The challenge is that neither Scrum nor SAFe provide a mechanism for making this determination. In fact, Scrum discourages this; see the LinkedIn posting, Going Beyond Scrum to Scrum as Example.

The adoption philosophy of the Kanban Method

The Kanban Method was created by David Anderson as an offshoot of the initial Kanban of which he was one of five co-creators. Kanban itself can be used with many different philosophies of learning. But the Kanban Method specifically prescribes starting where you are, creating visibility, making your workflow explicit, managing with a pull approach and managing your work in process. It believes in continuous improvement through small changes (kaizen). It also does not attend to how people are organized but expects people to attend to that if it is of value. The philosophy is one of change management – starting where you are, not causing disruption and continuous improvement.

The power of this philosophy is that it can be used anywhere. The disadvantage is that sometimes the change necessary for improvement requires a bigger view than what a kaizen approach will entail.

The adoption philosophy of Shu Ha Ri

Shu Ha Ri as a way of learning based on the martial arts of Akido. Shu Ha Ri proposes three phases of learning:

1. Shu. One of following, without variation, the practices a master sets forth.
2. Ha. Only after competency in these basic practices can one vary them based on principles learned
3. Ri. Go beyond the practices entirely and use one’s own judgment.

This is a very popular idea in the Agile community. However, few people describe how to go from Shu to Ha and even use it as an excuse to provide less guidance than what is needed; see Why Shu Ha Ri and Scrum can make for a dangerous combination and Going Beyond Scrum to Scrum as Example.

The dilemma that must be solved

It is clear that people need to be given a well-defined starting point. The larger the organization the greater the need. But it is also clear that there is on one-size fits-all. In addition, the greater change you demand, the greater the chance of overwhelming the people undertaking the adoption.

FLEX’s philosophy of adoption

FLEX resolves this dilemma by providing:

1. A well defined starting point based on the organization undertaking the adoption. It only requires as much change as the organization can absorb.
2. Options for different practices if the initial set of practices are problematic.
3. Options for next steps after the initial start has been sufficiently accomplished.

FLEX does this by taking advantages of patterns of success and challenge. This requires:

• Understanding your Value Stream.
• See the challenges to what you are trying to accomplish.
• Learn potential solutions to these challenges.
• Create a step-by-step roadmap for solving these challenges.

Net Objectives suggests not taking canned solutions unless they are the only possibility for movement forward. Some companies are so big that it is easier to take what people are doing now and tie it together with SAFe than it is to see if there is a better way to do things. In these situations an “all-in-all-the-way” approach makes sense.

FLEX’s philosophy applied to other methods

FLEX’s philosophy of adoption can be applied to Scrum, SAFe and the Kanban Method as follows.

Applying FLEX to Scrum. FLEX considers different frameworks, methods and approaches as tools in its toolbox. Think of FLEX’s starting point as the top shelf of a toolbox. That’s its starting point. One can apply this same thinking to Scrum. That is, we can start with Scrum’s practices, roles, and artifacts, but recognize that there are other options if need. See Scrum as Example for more.

Applying FLEX to SAFe. FLEX can be used to tailor SAFe prior to its implementation so that a company can start off with an instance of SAFe more tailored to them. See FLEX and SAFe for more.

FLEX’s philosophy of learning

We built FLEX on the basis that people learn best by being given well defined starting points that have been tailored to them. At some point, people will run into challenges with these starting points. Sometimes the starting points were not optimal. Sometimes they are, but removing the impediments is difficult. The challenge is to understand when another practice should be used or when the impediments to the current one should be overcome. FLEX provides insights into answering these questions and the provides guidance in how to either use a different practice or how to overcome a current practice’s impediments.

Footnote

* The Kanban Method is Lean Kanban University’s approach to Kanban. LKU was formed by Al Shalloway and David Anderson. Al left LKU because the Kanban Method was not consistent with Net Objectives’ approach yet became the main offering of LKU. For more information on the types of Kanban, see De-Mystifying Kanban.