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

 

The Purpose of an Assessment

Assessments are not about where you are. They are about where you want to go. By seeing where you are and what challenges you are having a roadmap for improvement can be made more effectively.

Assessing can be done in several ways. The most popular Agile method is to see how well the company is doing from the perspective of the approach they are taking. For example, a common assessment for Scrum is the Nokia test which specifies how well teams are doing Scrum. SAFe® has its own assessments. But consider these as assessments in how well a framework is being adopted, not how well the company is delivering value. We have found that focusing on the work, not the framework, is a better approach.

Because FLEX is based on a model of flow, it can be used to see where an organization is having troubles with achieving flow; that is, performing its work with few hand-offs, turmoil, delays, and rework. Reducing these helps achieve business agility. It is more effective to attend to how work is being delayed or how extra work is being created than how well a practice is being followed. Therefore, an assessment should focus on the value stream and what is impeding it.


For more, see Using FLEX to Perform an Assessment for Small-Scale Organizations

Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation)

I’ve created a new design for my book and am pretty excited about it. There are five parts to it:

  • Part 1: Workbook: understanding what’s required for flow in your organization
  • Part 2: Workbook: Using FLEX to transform your organization
  • Part 3: Topics in depth
  • Part 4: Using FLEX w/SAFe
  • Part 5: Resources on the Net Objectives Portal

The first two parts cover the basics of FLEX. They present what the effective enterprise of the future looks like, giving a vision for the transformation. They are designed as workbooks to guide readers via a way to learn by doing. They are also relatively short so they represent a quick overview of the entire approach.

Part 3 provides an in-depth explanation of the topics used in the first parts. Part 4 discusses how to take advantage of FLEX’s Lean portfolio & prod management approach for those using SAFe.

The last part of the book is online, providing the latest ideas and practices we are coming up with.

If you are looking for a more effective approach than either SAFe or LeSS, I invite you both to look at the book as it is uploaded. If you are interested in using it to help with your own adoption, let me know as I am looking to work with a few people while it is being written


To see the book, go to Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation) (online book)

The Effective Organization of the Future

The future is here today for a select group of companies.  It’s no longer a question of what to do, it’s a question of getting there. By looking at the characteristics of these select organizations we can gain insights into what we have to do to help our own organizations. One thing is clear however, we cannot try to do what other companies have done. No great organization was ever made by following another. However, there are ways of helping foster innovation, alignment, teamwork and strategic clarity. So the goal is not to copy another company that leads their field, but to learn from what they’ve done to get there.


This article describes the goals and characteristics of the effective enterprise of the future. It then describes what is required to achieve these goals and offers some helpful resources. Continue reading “The Effective Organization of the Future”

The Future of Agile

Here are some of the things Agile has demonstrated to be of value.

  • Having self-organizing small teams
  • Building incrementally
  • Taking an iterative approach

However, an organization is not merely a collection of small teams, it must also do the following:

  • Have a vision to guide what is built
  • Have collaboration across teams

All this means we need an ecosystem that illuminates the vision and allows teams to self-organize to achieve it. Continue reading “The Future of Agile”

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.

A Simple Solution to Agile at Small-Scale

I keep running across organizations with 4-10 dev teams struggling with Agile. They look to the two most popular frameworks out there for a solution (Scrum & SAFe) to solve their problems. On one hand they see something that can work at the team but doesn’t help them with their product management. On the other they see something much bigger than they need. They’ve fallen into a trap–looking for a solution instead of solving their problem

What are their problems? Most have trouble Identifying what has the greatest value to deliver, breaking it down into the right size business increments to give to the teams, coordinating their teams’ work, teams not being able to decompose the business increments they’re given into small stories, and building, validating and releasing the code quickly. These abilities should be their focus

When Agile Product Management provides guidance in what’s important, coordinating teams is straightforward. It’s easier to pull a rope than it is to push it. 2-3 days working on prod management, ATDD, a little Scrum and a little Lean is all you need. Invest here, it returns more value. And it’s less expensive. Proper training &coaching methods can get your product folks, 6 teams & their coaches working with Agile methods for less than $40k

Seeing Challenges in the Value Stream

In the same way that looking at the value stream helps you observe how value moves, looking at the value stream helps you discover challenges you are facing. Here are some of the most common challenges.

  • It takes too long to get anything done
  • Work is not properly prioritized
  • Chunks of work are too big
  • Too many things are in work
  • There are unclear requirements
  • Teams don’t understand the needs of the business
  • Some people have too much to do and are constraints on multiple teams
  • There is high technical debt
  • There are many integration errors
  • There is insufficient collaboration
  • Ops is blindsided and pulled in many directions
  • There is a lack of visibility of what is taking place

Often, these challenges are apparent when work is stuck in large queues just before the step where the problem is. Lean suggests that instead of focusing on how people can work faster, you should take steps to keep queue size down. Usually, this involves working on small batches, how you do work, and how you organize talent.