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:
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.
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:
There are other factors as well. See the LinkedIn post, Going Beyond Scrum to Scrum as Example.
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?).
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 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.
Shu Ha Ri as a way of learning based on the martial arts of Akido. Shu Ha Ri proposes three phases of learning:
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.
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 resolves this dilemma by providing:
FLEX does this by taking advantages of patterns of success and challenge. This requires:
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 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.
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.
* 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.