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.

10 Lessons from 20 Years in Agile: The Goal is Business Agility

This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)

In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.

This episode is about the Goal: Business Agility. Continue reading “10 Lessons from 20 Years in Agile: The Goal is Business Agility”

Issues with using preset training materials

It’s exciting to see how the competency of internal change agents is going up – many well above the average consultant. They don’t help in what to do as much of it being an issue of the time to do it

Turning to set training materials is often their only option. But using set materials without change is almost certainly not ideal for the organization. This makes it hard to adapt the method to the organization and avoid a “one-size fits-all” approach. While this may benefit the people selling the materials it is certainly not a benefit to the change agent

This is why FLEX has two courses:
1) FLEX for Change Agents. This is a 3 day course intended for people who will teach FLEX internally. Its high level agenda is:
Day 1: 1/2 day on FLEX, and a 1/2 day on doing an assessment to determine their organization’s challenges
Day 2: Full day on FLEX
Day 3: 1/2 day on how to use FLEX to create a starting framework that will work for their org, and a 1/2 day on how to teach FLEX

They then take a 2-day online workshop that provides the optional practices they need

At this point they can teach the 2nd FLEX course – Adopting FLEX. This is a 2-day course they teach to their organization that they’ve tailored themselves

Agile needs to be flexible

10 Lessons from 20 Years in Agile: The Goal is Business Agility

This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)

In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.

This episode is about the Goal: Business Agility. Continue reading “10 Lessons from 20 Years in Agile: The Goal is Business Agility”

FLEX: A Pattern Language for Achieving Business Agility

Patterns are solutions to recurring problems within a context. A pattern language is a set of patterns that when combined solve a large problem. FLEX is a system that explicitly describes the process experts use to help an organization achieve business agility. These patterns include: Continue reading “FLEX: A Pattern Language for Achieving Business Agility”

The Minimum Business Increment (MBI) Template

MBIs represent both the smallest amount of value that can be implemented and realized while also containing all of what’s needed for this realization. In other words, MBIs are small but sufficient. If it’s bigger than necessary, you will make flow harder to achieve. If it is insufficient, product may be built but it won’t be effectively realized.

Here is what an MBI must contain. Continue reading “The Minimum Business Increment (MBI) Template”

Minimum Viable Products (MVPs) are very different from Minimum Business Increments (MBIs)

MVPs are used to discover when a product is useful. MBIs are used to define the smallest increment of value that can be built and released that realizes value for the business. Although both of these are about doing a small amount of work and releasing it, they are quite different in both intent and method.

An MVP is intended to create a new product without an existing customer base. It is built by taking the smallest step possible to determine if it is viable. An MBI is for building the smallest enhancement to an existing product. Continue reading “Minimum Viable Products (MVPs) are very different from Minimum Business Increments (MBIs)”

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.