I am close to finishing “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale.” We take our own FLEX approach (FLow for Enterprise Transformation) and apply it to SAFe to help solve virtually all of the challenges we’ve seen small to mid-scale organizations have when trying to adopt SAFe. The result is using the core of SAFe while fleshing it out with Lean-Agile principles and patterns of adoption to create a simpler framework, albeit perhaps no longer SAFe, to use.
The list of these challenges is at https://goo.gl/Zcx7cu
Please take a look at let me know about any others.
Here are two serious questions:
1) As a provider of a framework whose intent to increase the ability of an organization to deliver value more quickly, why would you put limits on what could be in your framework? This means limits on both what could be added to the framework or what could be substituted for any of the frameworks rules, roles, practices and events? If you do, you are limiting the effectiveness of the framework.
2) As an adopter of a framework with the intent to increase your organization’s ability to deliver value more quickly, why would you accept limits by the framework you wanted to use? In other words, if something was more effective than what was in the framework, you’d have to stop using the framework to adopt the practice, … Why wouldn’t you find a framework that didn’t require this?
As far as I can tell, the only real acceptable answers are:
1) I don’t know how to do otherwise
2) I don’t know of a framework that doesn’t do that
Let me know if you have other answers.
Framework proponents suggest starting with framework training & later adding what else is needed (e.g., prod management, test-first). We believe this leads to a significantly higher cost of training
Companies with more than a few teams need a blend of Scrum & Kanban. Few companies need all of SAFe. The most important aspect of a workshop should be how to work together with your associates
Training should be oriented around
- the context of the people being trained
- increasing collaboration
- learning by doing actual work
- needed essential skills
Training in frameworks is important. But when people are given the skills they need from the start, less knowledge of the framework is needed to move forward. This is especially true when these essential skills are learned together. Not having these essential skills leaves them unprepared & often causes resistance to the framework, which, by itself, is not helping.
Unfortunately, this type of training cannot be done with certification, since certification requires a focus on the framework. Less framework, more how to do is required. Fortunately, there are many qualified, non-certified trainers out there who are more concerned with you getting what you need
One must address the culture of the organization when attempting to improve it. Culture affects Lean-Agile adoptions in several ways. These include:
- How attached people are to their roles. Scrum and SAFe require new roles for people.
- The rate that people want to move forward. If slow, Scrum and SAFe may pose a problem.
- The amount of discipline needed. If high, Kanban may pose a problem.
- How much people will resist a specified approach. If high, Scrum and SAFe may pose a problem
- How much do people already know. If high, standard training may pose a problem.
- How much more do people think they know than they do. Must engage in a discourse with people more than a training mode.
These factors should be included in deciding how one will proceed with any adoption.
I have long believed that frameworks should meet the following requirements:
- provide an explicit method to start that can be tailored to the organization adopting it
- provide a method to improve the practices being used based on the situation of the people using it
- be able to incorporate new ideas as they become available
These are difficult to achieve and are not met by any of the popular frameworks. This difficulty is not because such a framework needs to be massive, but rather because it needs to be based on a clear, workable model of how software development works. Not having this model has led to both incomplete and/or complex frameworks.
FLEX is a framework that does meet these requirements. It considers other frameworks as tools to use and uses them to provide recognizable starting points to virtually any company. But by including a method to adopt new practices, etc., as needed, it adjusts to what’s needed without having to re-invent the wheel.
FLEX accomplishes this by having a set of intentions to achieve collectively that will increase an organization’s business agility – the quick realization of value predictably, sustainably and with high quality.
Proponents of Scrum often put the responsibility for failed adoptions of Scrum at the feet of management who don’t want to change. While I believe this is true some of the time, I believe the challenge is that Agile adoptions based on Scrum often don’t attend to management’s needs.
I believe management concerns regarding Agile adoptions are focused on reducing risk, making sure it fits their needs, and to be able to adapt when needed. It’s tempting to say “let’s just adopt Scrum.” But this ignores that we live in a complex world where you reduce uncertainty not by having a preset list of things you must do, but rather by learning to adjust to the situation at hand. These are things beyond our control.
What is in our control is our actions. 15 years ago we didn’t have a solid understanding of the “task work” so to speak of Agile. Why working on small batches were good, why visibility was essential, why managing queues is critical, … Now we do. This enables us to go beyond Scrum effectively.
Adopting Scrum is very often the best place to start. It provides structure & discipline. But get training from someone who knows how to go beyond it when that’s the right thing to do.
Addressing the issue of how to adjust Scrum while not worrying about if it is still Scrum is based on 20 years experience with Scrum and is described here: How to improve or change your Scrum practices. This is part of our larger Scrum Support system. I believe having a framework where being effective sometimes requires you to go beyond it is insidious. I contend there are place in any tech org of more than 50 people that no one set of practices work, particularly in shared services, DevOps, maintenance. We have put this together because we’re not limited to Scrum.
The Scrum Guide tells us “Scrum’s roles, events, artifacts, and rules are immutable”
This presumes people need this structure and can’t think on their own without it. Structure is good, but it can be achieved by specifying outcomes and principles while providing a starting point that can be changed as long as the outcomes are still achieved. Agile adopters should be focused on getting their work done, not on following a single set of rules that some people are advocating for everyone.
If you’re a new adopter of Agile don’t accept less than someone who respects your knowledge and experience. Get a coach, not a shepherd. Coaches provide clarity on the intentions and principles of Agile. Learn the how by doing your work. If that’s not in your vendor’s syllabus, get another vendor. If they say it can’t be done, find someone who does it.
You have more experience in your company than any outsider will ever have. Starting with immutability is the anti-thesis of Agile and it leaves an impression. Avoid the discussion of “Agile tells us we must do …”. It doesn’t. Scrum might but Scrum != Agile.
And it isn’t “Scrum And” over “ScrumBut.” Sometimes you don’t want to do something Scrum says.
Why Net Objectives Is No Longer Providing SAFe Training
After 6 years of being a contributor to SAFe in technical Agility and Kanban, my having been the first SPCT outside of SAI and us being a SAFe partner, we are amicably breaking off our relationship with SAI. I believe that SAFe has expanded the understanding of Agile at Scale and incorporates many needed practices that are not found elsewhere.
The reasons for this move include:
- SAFe has grown considerably more complex than it needs to be
- Many small- to mid-scale orgs (technology <1000 ppl) are looking to Essential SAFe even though it is not a good solution for them
- Many orgs are looking to take “SAFe out of the box” which has never been our approach
- SAFe training is not tailored to the size of the organization that will use it
While taking Implementing SAFe 4.6 a couple of weeks ago I realized that SAFe and Net Objectives are on divergent paths. We like to work with small- to mid-scale companies that want a focus on their specific challenges and not just adopt a canned solution.
We will continue to offer consulting and training to those who do SAFe using our own materials.
If you want to see how we do Agile at scale, check out The Essence of FLEX (FLow for Enterprise Transformation). If you are still interested in SAFe, check out these two articles from my upcoming book Achieving Business Agility at Small to Mid-Scale:
This is an overview of a 5 part series starting tomorrow.
Agile adoption is often more difficult than it needs to be because most people settle for pre-packaged frameworks instead of what their particular org needs. This has people focus more on a framework than on the actual skills their ppl need to get the job done. Follow up training for these skills (eg ATDD) usually doesn’t happen. Resistance often sets in because people are put back in their jobs with higher expectations but no higher skills. This is made worse if the framework doesn’t match what’s needed close enough.
What keeps this in place is the focus on certification. While a good amount of what works in one place does work in another, the transition to these practices takes one of several paths. Many consultants offer only one type of framework, forcing them to push it only & blame their clients for not following it if it doesn’t work
What’s needed is to be guided to understand their problems, the root causes of these problems and a set of proven practices that can solve them. This is harder to manage, but the results are worth it & the cost is much less over the long term. It is also more likely to be sustainable as people actually learn the skills needed.
This is an excerpt from Adopting SAFe at Small- or Medium- Scale a chapter from my upcoming book “Achieving Business Agility at Small- to Mid-Scale.
Essential SAFe, the smallest option of SAFe, was designed for programs within a large organization. It was not designed for an entire organization that is the size of a program. Here are examples of challenges that come with this.
- The planning pace for SAFe is two to three months. At the small-scale, it is more reasonable and Agile to plan one to two months ahead.
- Different type of organizations often require different methods of planning
- Having an innovation and planning iteration should not be required at small- to mid-scale (not to mention that the cost of it would be proportionately long given the shorter planning increments.
- Many concepts needed at small- to mid-scale are not in Essential SAFe (in particular, how to go from strategy to the product backlog)
Fortunately, what to add, modify or leave out can be guided using Lean-Agile principles – most of which are ironically included in Essential SAFe.
This enables those wanting to use Essential SAFe as a core to have a framework that is effective, efficient and most importantly, is the right for them.