The Mistaken Assumptions of Essential SAFe and What They Tell Us

From the SAFe site:

  • With such a robust framework, the question becomes; how closely does an organization need to follow various SAFe practices to get the desired result?
  • [Essential SAFe] provides a starting point for implementing SAFe and describes the most critical elements needed to realize the majority of the framework’s benefit.

SAFe is projecting the word ‘robust’ (which means strong) on itself instead of using the more appropriate ‘complicated.’ This is merely putting lipstick on a pig.

SAFe’s complexity makes it hard to implement as a whole. There are many essential concepts in the higher levels, however. The choice becomes insufficient or overly complicated.

Essential SAFe has Mid to small size organizations (especially those within larger companies) lose the opportunity to solve one of their biggest problems – prioritizing what to work on. Claiming that one should start at the bottom is reckless.

The bottom line is that SAFe is an overly complex framework requiring one to start with only a part of it. But this violates what SAFe claims to be built on – systems-thinking and Lean. It also loses the opportunity of getting the higher levels involved quickly.

Questions to Ask Yourself While in an Implementing SAFe class

Organizations going to Agile at scale are often pretty set on SAFe. It’s a popular framework so it must do some good. And it does. It attends to the key objectives required but gives only one solution when there are several options needed. While alluding to Lean principles, no one can learn how to apply these in just two or three days.

Taking an implementing SAFe can provide key insights especially if consider three things when in the course: Continue reading “Questions to Ask Yourself While in an Implementing SAFe class”

We need to focus on our work, not the framework

A great way to illustrate this is to read imaginary certification question for a framework, vs how to get your work done. Which would you rather be able to answer? My experience is it takes about the same amount of time to learn either one.

“What is a program backlog?” compared with “How does an effective intake process help define responsibilities for product management and make life better for developers?” Continue reading “We need to focus on our work, not the framework”

How MVPs are Limiting you if You’re Using SAFe

MVPs were defined by Eric Ries to mean “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

If you are an established company, especially if you are using SAFe, the chances are excellent that you area not creating a new product but enhancing an existing one. You already have a customer base, know a considerable amount about your product and you have competitors you are trying to either keep ahead of or catch up to. This is a considerably different situation than creating a new product that you hope will create a new market.

In this situation, product development starts with initiatives to build. he question isn’t so much how do you discover if there is a product, as is it “what is of the most value that we can deliver sooner.” This requires a different tact. This is what a Minimum Business Increment is for. MBIs are that smallest part of an initiative that will realize the most value when delivered. This is a far cry from the MVP where we start small and extend.

While both MVPs and MBIs are conceptually about value sooner, they are considerably different in implementation. If you’ve been having trouble using MVPs, now you know why.

How to do SAFe “by the book” better than the book

I hear many C-level folks mandating doing SAFe by the book. This post is for those of you who need to do this but want to take advantage of the fact that SAFe is a framework and can therefore be modified to some extent.

As a former contributor, SPCT & gold partner I can give you some advice you won’t get from SAFe partners.

1) Find an SPCT that is not dogmatic about SAFe. Talk to a former client. Everyone says they are not dogmatic. I can give you a referral with no strings or cost attached as well.

2) Make it clear what an MVP is. The inappropriate use of MVP in SAFe in non-startup environments has caused confusion. If you don’t make it’s meaning clear it will mean everything, and therefore nothing.

3) If you have platform teams, ensure you set up your trains accordingly. SAFe gives little guidance here. Use Kanban to manage their work driven by other teams & prioritize by MVP importance. Chapter in book is coming soon.

4) Take ATDD up front and don’t think you’re getting it in the ASE. ATDD is a collaborative method with POs, devs and testers. By relegating ATDD to 2nd tier training & making it a technical offering SAFe is doing you a disservice. We offer ATDD training with SAFe if you’d like to learn more.

Why SAFe’s Top Layers Are Needed But Overly Complicated

I had hoped they’d fix the underlying flaws of SAFe but am now convinced that will not happen. Here’s why we only help folks doing SAFe but don’t train it anymore:

1) SAFe’s based on levels & not on the value stream. All companies need the concepts in the top levels (e.g., strategies) but these are overly complex due to factors described in the rest of this list so SAFe’s method to achieve them is unusable for many organizations
2) SAFe has tacked concepts together by focusing on roles & artifacts while misusing/redefining previously useful terms
3) SAFe does not have a concise, well-defined concept of the smallest increment of value used to extend an existing product. MVPs are for new products & epics are too large. This makes prioritization across teams difficult
4) there is no simple way to have the org align around value
5) the Lean principles mentioned are used in a superficial way

The result is a pre-defined, over-complicated solution. SAFe can be a massive improvement for companies whose development group is blocked & it provides low cost training materials. But it will not help achieve true agility except when guided by a real expert who goes SAFe to achieve that. SAFe is often used to gain consistency not agility.

These are not idle comments. If you are using SAFe and finding value at the program level but want to improve its higher levels, you will find value in Part IV: Using FLEX to both enhance and simplify SAFe

 

How Frameworks Are Being Used Now Is Impeding Agile and What We Can Do About It

Part 1: Frameworks are taking our eye off the ball

We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein

How Frameworks Are Now Impeding Agile: Part 1

We cannot solve our problems with the same thinking we used when we created them.

There is no question that Scrum & SAFe have transformed how we work. Both have created a new mindset around work- Scrum focusing on the importance of team & SAFe focusing on the necessity to coordinate teams.

And both have now created new challenges in somewhat the same manner. Each has taken our eye off the real task- working in an Agile manner. This is finding what’s of greatest value, allocating our capacity to work on it, properly decomposing it so it can be built in increments and being able to deploy frequently/continuously. Scrum’s focus on ceremonies has takes peoples’ eyes off of how they do their work – leaving it to the team with the unquestioned assumption that they’ll figure it out (& then blaming them for not doing Scrum if they can’t or change anything in their attempt).

SAFe has gotten management involved but mostly to demand that SAFe be done. SAFe is often led internally by agents who demand that SAFe be followed. Again, the focus is on the framework.

Frameworks were an excellent way to go when we didn’t understand the mechanics of Agile. We do now. We should attend to them or at least drive our frameworks with them.

How Frameworks Are Now Impeding Agile. Part 2 – Scrum

Take a look at the common challenges teams have when adopting Scrum:

  • not being able to write small stories
  • essentially doing waterfall in 2 week cycles-Scrumerfall
  • having many open stories at the end of the sprint
  • difficulties poised by being interrupted in a sprint
  • not being able to coordinate well with other teams

The similarities across widely variant dev groups is striking. Not a surprise since systems-thinking would predict this. While Scrum proponents claim “if you did Scrum these things wouldn’t happen” is likely true, what does that matter? People are doing their best.

We need to attend more to what insights & skills would help us avoid these challenges directly.

The above challenges are due to not attending to:

  • flow
  • managing work in process inside the sprint
  • the team’s part in the bigger picture

Yes, I know Scrum doesn’t say not to do these, but that’s not the same as saying to do them.

In the early days just getting teams co-located, cross-functional & working in small chunks was a major improvement. To go to the next level we need to shift our focus to the work & how to do it.

How Frameworks Are Now Impeding Agile. Part 3 – SAFe

Many people complain that SAFe is too complicated and doesn’t truly get management involvement. I would agree. But why is that?

Take a look at the common challenges organizations have with adopting SAFe:

  • little improvement beyond the program
  • little improvement in the area of portfolio management
  • difficulty resolving conflicting requirements given to platforms and shared services
  • a continuation of top-down management
  • too much work in play overall
  • not being able to get deliveries within a program increment

The similarities across widely variant organizations is striking. This validates systems-thinking’s assertion that the system people are in causes behavior. SAFe proponents claim it addresses the main issues & people just need to fill things in. I would suggest that the way SAFe addresses these issues prevents people from filling things in.

Pre-defining roles & artifacts takes our eyes off of the value stream and the work that is taking place in it. This is exacerbated by SAFe overloading and redefining terms.

In the early days getting a plan for a program & having teams work together towards that a major improvement. To go to the next level we need to shift our focus to the work itself.

How Frameworks Are Now Impeding Agile. Part 4 – The Solution

Actually, if you’ve been following my train of thought here, you’d know there is no solution. But there is an approach that will lead to a solution. It’s using Lean as an overall context for your work because Lean focuses directly on the work. Lean can help achieve business agility – the quick realization of value predictably, sustainably and with high quality.

Lean provides insights to shorten the time from beginning work until value is realized. It does this by starting with the question of what’s value to the customer? Then attending to the value stream so that we can improve it to eliminate delays in workflow and feedback. By attending to queues of work we can see where our bottlenecks are and improve them. Instead of overloading teams we have them manage their work by implementing pull systems. And, because we’re looking at improving our work directly we can continuously improve.

Fortunately, this doesn’t mean we have to re-invent the wheel. All we need to do is look at the outcomes we need at each step of the way and select the best method for us to get there. This is true agility – figuring out how to solve our problems instead of taking canned solutions.

Want Some Free Advice on Solving Adoption Challenges in SAFe? Help Me with My Book.

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.

Why Net Objectives Is No Longer Providing SAFe Training

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: