Introduction to FLEXProvide Feedback
Part VI: Resources on the Net Objectives Portal
Absorb what is useful, reject what is useless, add what is specifically your own. – Bruce Lee
Essential SAFe is intended to take a program in a large organization and get it started with SAFe. This is definitely easier to do than starting further up the value stream with stakeholders and product managers. But easier is not necessarily better. In fact, the common adage “go for low hanging fruit first” often makes getting the real jewels at the top of the tree harder to get to.
The Risk of Using Essential SAFe at Large-Scale.
Using Essential SAFe at large scale means you are firing up programs in a large organization. This may or may not be a good first step. Definitely easier. But may not really address the issues at hand. Many large organizations’ real problems have more to do with product management, however. Starting with Essential SAFe may be a decent first step, but don’t consider it adopting SAFe.
Often the real challenge organizations face is that programs are overloaded with work because management above the program level cannot decide on how to sequence their work and demand more to be worked on than should be. Essential SAFe, however, does help create an intake process that may help improve this since the teams should only pull the amount of work that they can handle. But if the real issues isn’t addressed, at some point demands on production will likely occur. Even if they don’t, great opportunity is being lost in any event.
Starting at the program level sometimes lulls executives into thinking they are now “doing SAFe” and don’t have to change their methods. While some value has been achieved and even open doors for new improvement, it more often tends to lead to stagnation because something has been accomplished – even if it’s not the true problem.
If you’ve been around the Agile world long enough you’ve likely seen something similar to this with Scrum. Many organizations adopted Scrum by putting together a few cross-functional teams. Adopting Scrum in this way is relatively easy because we took the teams out of the normal environment and created one within which Scrum works well. And it can achieve great results. We have found that cross-functional teams working together are 3-10 times more productive than teams siloed and scattered throughout an organization.
But doing this often doesn’t address the real issues of what is to be worked on and how teams work together. A bigger view is needed.
In many ways, the adoption of Essential SAFe has a similar pattern. There are now reasonably effective programs but business stakeholders have not figured out how to feed the programs correctly. In both cases we’ve found that a driving from business value approach to work much better than the organic growth from the bottom. Be clear that driving from business value does not imply in any manner that we’re taking a top-down management approach.
The challenge of using Essential SAFe at Small to Mid-scale
Essential SAFe is focused on the programs in a large organization. That being said, there are several practices of Essential SAFe that are useful for small to mid-scale. In particular the program increment (although it usually can be shorter than 8-14 weeks), the program increment planning event, the concept of an Agile Release Train and its corresponding RTE (release train engineer), the use of Lean principles and purportedly being driven by Cost of Delay.
That being said, a program in a large organization is quite different from when a small company’s technology group is comprised of just one, or even a few, programs.
The Risk of Using Essential SAFe at Mid-Scale. The risks here are mostly in the area of lost opportunity. While large scale organizations don’t require the complexity of SAFe the value received by having any consistency in product management may be worth it. However, at midscale, it is much easier to adopt better lean portfolio and product management. This will be the topic of the Enhancing while Simplifying SAFe with Lean Product Management chapter later in this book.
The Risk of Using Essential SAFe at Small-Scale. The risks here are two-fold. First, Essential SAFe was not designed for small-scale and is by its nature way more complicated and heavy than needed. Even if program increments are shortened to a more reasonable length (2-4 weeks), the complexity remains. On the other hand, small companies still need Lean portfolio and product management. Essential SAFe doesn’t really talk about this. If you try to bring it in by using what’s in the higher levels, you’ll increase complexity even more.
Using Essential SAFe here means you will have both more and less than you need. However, understanding how Essential SAFe ale can be used as a basis for the implementation while layering a better (small-scale) Lean portfolio and product management system on top of it is very useful.
The challenge of Essential SAFe at Any Scale
Essential SAFe is a method of trying to simplify SAFe. While that is a good intention, it doesn’t follow systems thinking which tells us to look at the system as a whole. Simplifying SAFe would require to still look at the organization as a whole but be more focused on what it is attempting to do. This is one of the reasons we suggest Looking at Your Work From a Value Stream Perspective. Even if we focus on the programs we must consider how they fit in with the rest of the organization.
Essential SAFe was designed for programs in large organizations
Essential SAFe, the smallest level of SAFe, was designed for programs within a large organization. This is what might first be considered “mid-scale.” The challenge is that programs within large organizations face a different set of challenges than the ARTs that are in small to mid-scale organizations.
Essential SAFe, being designed for a program within a large organization, has the same practices regarding program increments and architecture as present in large organizations. However, these issues at small to mid-scale are different in both pace and in needing a full portfolio and product management solution. Essential SAF therefore needs to be tailored for the size of the organization adopting SAFe.
Tailoring Essential SAFe for small to mid-scale organizations
Some of SAFe’s practices need to be modified for small to mid-scale companies adopting it. This includes:
Essential SAFe Leaves Out Concepts Needed at Small to Mid-Scale
To best see this, take a look at SAFe’s Big Picture. Click on ‘Essential SAFe’ and familiarize yourself with it. Now click on ‘Full SAFe.’ Now go back to ‘Essential SAFe.’ You’ll notice that if you click on Enterprise, Solution, or a number of other icons on the Essential SAFe picture, the description lies in the higher levels of SAFe. These concepts still apply, but are not needed at the level of complexity they are in big organizations.
Even small companies have the issue of portfolio management, identifying the work to be done and managing their work-in-process. It just happens on a different time frame and with fewer people. SAFe’s portfolio management, designed for large organizations, is overly complex for small ones and is left out of Essential SAFe in any event. Part 5: Essential SAFe with FLEX will fill in these gaps.
Essential SAFe’s Choices for Agile portfolio management are not effective
Essential SAFe has a couple of buttons to imply portfolio and solution management are important at the program level. And, in fact, they are. But Essential SAFe’s guidance here is based on the full SAFe level. These higher levels have grown over time by adding more and more concepts that may be needed at higher levels but are seriously more complex than they need to be at small to mid-scale. Instead of requiring several concepts that comprise overloaded and redefined terms, a simpler Agile product management system is required. This will be discussed later in Part 5 when we show how to overlay a simple, effective, Lean portfolio and product management method on top of Essential SAFe.
The bottom line is that while SAFe provides many good practices, it is defined in such a way that small to mid-scale organizations are left with the choice of 1) adopting only part of SAFe to keep things simple while missing some key concepts or 2) adopting all of SAFe and having it be more complicated than what is needed. Fortunately there is a third option – take the essence of SAFe, guide it with patterns of successful Lean-Agile adoptions, and adopt a subset of SAFe that works for your organization.
Essential SAFe at a Program in Large-Scale
Many large companies are adopting Essential SAFe for their programs because they find the higher levels too complex. The challenge is that for many of these organizations, the real challenges lie at budgeting and getting agreement across programs.
Using Essential SAFe for programs at large-scale makes sense as a way to start SAFe. But one must be clear that by doing so, one is solving the problem of the program and not a problem that most larger organizations have – how do you feed programs work and how do they interact with each other.
This is not unlike when Scrum teams were started in organizations whose real challenges weren’t the teams themselves but how they could work together. Essential SAFe solves this problem one level up – but typically it is not the key problem to solve. One again needs to start higher up.
Thus, while Essential SAFe is an attractive place to start, it must be recognized that it doesn’t always get at the problem.
Don’t Fall Into the “That’s How We’ve Always Done it Trap”
You’ve probably heard the anecdote about a young woman, preparing for a family get together, asking her mom why she cut off the ends of the roast before putting it in the oven. Her mom responded – “I don’t know, my mom always did it that way so I copied her. Why don’t you ask her tonight?” So that evening the young woman asked her grandmother about it and she responded “because the roast wouldn’t fit in my pan if I didn’t do that.”
The history of Agile adoption has a kind of bottom up approach. This is not surprising for two reasons. First, the Agile Manifesto on which most Agile adoptions are based focuses on the team. The second is that SAFe started at the program level because finding people who could work with higher levels of management are difficult to find. While SAFe has grown to no longer always take a bottom up approach, the vestiges of how it has evolved are still apparent.
Our experience is that it’s better to decide where to start by first looking at where an organization’s challenges are and looking to see what will have the best long range impact.
Essential SAFe definitely provides a lot of goodness and is worth both investigating and implementing. But it’s worth noting that Essential SAFe will just provide a backbone for an Agile adoption at both small and mid-scale. There will be practices that need to be adjusted, some discarded and some added.