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 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 a canned solution.
Although we will continue to offer consulting and training to those who do SAFe (we have several courses at all levels that would be advantageous for SAFe practitioners to investigate) we will no longer offer any SAFe certified training.
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.
Every organization thinks they are different. And in many ways they are. But the principles apply equally to all. So no one size fits all, but there are surprisingly few degrees of freedom, so to speak. This post discusses those degrees of freedom – where choices should be made to best fit the organization doing the adopting.
At the team level
Scrum, Kanban or a blend of both
- cross-functional teams or manage people not on a team with Kanban
At the program level
- how to kick off the adoption (use a planning event?)
- if & how often to do a planning event
- how do we best organize our talent
- where are the product owners for the teams?
- are product managers needed?
At the adoption level
- who is best to lead the adoption?
- at what pace should we go?
This obviously leaves a lot out. I suggest most of what’s left out is somewhat common across organizations. Please provide feedback to tell me what I’ve left out.
The following is an excerpt from the chapter Adopting SAFe at Small Scale in Al Shalloway’s new book – Achieving Agility at Small to Mid-Scale
The Challenge of Essential SAFe
SAFe proponents suggest Essential SAFe be used for small companies. The reason for this is that small companies don’t need the complexity that full SAFe entails. But even small companies have the issue of taking their strategies to fulfillment. This means that the concepts of strategies, epics, solutions, capabilities, and MVPs are still needed. The challenge, of course, is that these are defined at the levels above Essential SAFe.
Most small companies adopting SAFe are mostly attracted to:
- the program increment and its planning event
- the role of the release train engineer (RTE) to coordinate teams
- having teams work in cadence with synchronization
These can be used as the cornerstone of their SAFe adoption. However, a simple Agile Product Management approach that takes the company from strategy to realization of value is still required.
See chapter above for more.
In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganizatio
In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganization is often not a real possibility.
Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance …
In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions.
In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.
n is often not a real possibility. Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance … In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions. In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.
This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales
SAFe has many concepts across its levels-strategic themes, epics, solutions, value stream, MVPs, MMFs, capabilities, stories & several backlogs.
While SAFe nobly attempts to present all needed concepts it does not explicitly call out the most important one–the smallest chunk of work that will provide the most value for the time it takes to build it. We call this the Minimum Business Increment (MBI). It is very similar to Denne& Cleland-Huang’s Minimum Marketable Feature (MMF), which, unfortunately, SAFe changed original meaning of to represent “the minmimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not.” This concept is already part of Agile which always suggest to build in vertical slices to test our hypothesis.
SAFe definitely intends to have the concept of the MBI, but its use of overloaded &redefined terms make it hard to see. MBIs encapsulate the intention of solutions, MVPs, capabilities & SAFe’s re-defined MMFs. Realizing this can simplify SAFe by starting with initiatives that are consistent with our strategic themes & defining a sequence of business increments for them. These business initiatives can then be refined into MBIs which create the context for everything needed to manifest value.
There are many lessons we can learn from the challenges incurred in adopting Scrum. I suggest the significant amount of bad Scrum in the world is due to the approach in teaching it.
The most popular method focuses on the framework itself. It usually consists of a CSM taught to a team. Some guidance is provided on how to write stories, but the attendees spend virtually no time writing their own stories past the ubiquitous “as a user…” method which is insufficient in the real world.
Another method focuses on Agile analysis by having teams create a backlog of their own stories using some aspects of ATDD. Only minimum training on Scrum is needed since it is now in support of what the team’s work & they already have an understanding of the why for feedback.
We have found the 2nd approach to be significantly more effective because people leave the workshops actually doing Scrum & don’t have to figure out parts later.
I see the same thing happening with SAFe with different ramifications. The SAFe framework alone often improves orgs’ agility because of the quarterly planning event. But working with product managers prior to the event & teaching teams more ATDD & less SAFe is critical.
I remember my first SAFe implementation – Northwestern Mutual (you can see a case study of it on the SAFe website). I remember that my main focus was on training the managers, product managers and shared service managers. While I did do a SAFe/Scrum course for the train, I wasn’t particularly worried about them. Continue reading “Why teams starting out with SAFe need little SAFe training but do need ATDD up front – 6 days to #SAFeSummit”
When people adopt SAFe they often believe that the way to do work with each other is by having everyone adopt SAFe’s roles and act accordingly. But this is a componentized view. That is, it looks at the organization as a collection of pieces and won’t result in a true system. A system is not the sum of it’s parts but rather the synergy that its parts create when working towards a common goal.
We have found that all roles need to agree to work with each other in order to achieve the following: Continue reading “How do we work together at Scale? – 7 days to #SAFeSummit”