SAFe is not Agile if you are planning 3 months ahead

SAFe is not Agile if you are planning 3 months ahead

For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.

Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.

If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.

Long planning periods:

  • require reworking requirements in last couple of sprints
  • loses focus on realizing value
  • makes it more likely that features will be bigger than needed
  • loses focus by teams on releasable value
  • results in more work being injected into already planned work
  • has the refinement of any stories pushed out of the PI due to new work be waste
  • makes it harder to pivot
  • causes a loss in a sense of urgency
  • requires more refinement up front without advantage of feedback
  • establishes a baseline of “not good but good enough” so improvement stops

It’s fine to do high level quarterly planning but then work in a flow model to implement it.


Lean-Agile Newsletter – April 4, 2019

Net Objectives

First of all, we have a new website which better explains some of our services. See

Second, I’m almost done with my book: Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation. While it’s about our approach, we have written a section on how you can make SAFe agile by putting our Lean Portfolio and Product Management on top of Essential SAFe. To learn more, see Part IV: Using FLEX to both enhance and simplify SAFe. You will see how to have much less complexity while having much more effectiveness.

We have created an online workshop: Advanced Scrum Masters / Kanban on-the-job workshop. This workshop is let by Al Shalloway. The cost is only $100 a month and usually takes three months to complete. This workshop is part of the Net Objectives University. A lot more is there beyond this workshop.

We are offering our first workshop on our FLow for Enterprise Transformation approach. FLEX is not another framework but rather an approach that integrates existing solutions to create a custom-fit approach to your needs. More effective, less complicated than preset solutions.

Of course, we are still offering our standard set of ATDD/BDD, TDD, Design Patterns, Scrum and Kanban classes.  Note the public offerings of some of those courses coming up in Seattle and California in the next month plus listed in the table below my signature.

If you are considering doing some Agile at scale and think SAFe’s too big (or expensive) please contact me as I would love to chat about some ideas and services you may not be aware of.

There are regular new blog posts on Many of these have audio included and are available on iTunes.

I would be happy to chat about anything regarding delivering value to your customers (internal or external) faster.

Al Shalloway, CEO, Net Objectives

SAFe® is a registered trademark of Scaled Agile, Inc.


Don’t see an offering in your area? Let us know so that we can see about scheduling one nearby!

Public Courses

Online Courses

Here are online courses and workshops being offered now on Net Objectives University.

The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think

This was originally published in June, 2014

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller

Continue reading “The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think”

Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination

This was originally published May, 2017

Note: This blog assumes the reader understands the basic roles and practices of Scrum.

Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, Scrum Master) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.

Continue reading “Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination”

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


Why Scrum Works and How This Tells Us When It Won’t

This was originally posted in August 2012


We hear that Scrum works because it allows teams to self-organize. I believe, however, that Scrum works because it mandates a method that manages queues implicitly. Self-organization may get you there, and will certainly be useful in sustaining improvements achieved with Scrum’s implicit queue management. But it is not the real reason Scrum works. Knowing why Scrum works at the team level provides insights into why it often doesn’t work well at the enterprise level.

Continue reading “Why Scrum Works and How This Tells Us When It Won’t”

The Five Whys of Lean as an Answer to the “But” of Scrum

This was originally published in October 2009

In this blog I discuss the need to get to the root cause of why so many teams are not having success with Scrum.  Merely saying management is not removing impediments or labeling it “Scrum but” does not give much indications as to what or where the problems are. The question is “why does this happen and what can we do about it?” I will suggest one of Lean’s problem solving tools – “5-whys” – may assist Scrum teams in moving forward.

In an Agile Collab interview, Ken Schwaber acknowledged that only 1 in 4 Scrum implementations achieve the success desired by the companies trying it. He attributes this to the organizations accommodating the impediments the team faces instead of solving them. This number has been generally accepted by the Scrum community as accurate (as discussed at Scrum gatherings and on user groups). What surprises me isn’t the low rate of success but rather the general lack of interest into why it occurs. I’ve looked at both sides of this (see Challenging Why (not if) Scrum Works and Challenging Why (not if) Scrum Fails). My own belief is that one has to take a scientific approach and do an inquiry into why things work or don’t work. The intent of both blogs was to spark a conversation about how to improve Scrum.  Unfortunately, neither blog achieved this.

In the past, the generally accepted reason simply seemed to be people were not disciplined, educated or motivated enough to do Scrum properly.  More recently, the belief that developers don’t properly understand what they need to do has resulted in much discussion about having Certified Scrum Developer courses to solve this problems.  But I am afraid both of these are superficial answers.

The issue of teams doing a pseudo Scrum by cherry picking their practices has reached epidemic proportions. One hears of this so much that there has become a name for it “Scrum but.” That is, “we do Scrum but for this”.  However, why do people do this?  This is an important question.   In some situations this is probably a good thing.  After all, Scrum is not a prescriptive methodology but rather a lightweight framework. One would suppose that would mean that there aren’t any absolutes in Scrum, but I’ve heard several CSTs say if you aren’t doing daily stand-ups or retrospectives then you aren’t doing Scrum. The reticence of many Scrum CSTs to present a model of why and how Scrum works (many claim such a thought process is actually counter-productive) only exacerbates this situation. In other words, if one doesn’t have a set of principles to work from, one is left with little understanding of why practices work or not.

So what’s supposed to be in Scrum and what’s not supposed to be in Scrum and who is to decide? If one believes that practices are context dependent and that teams need to be self-organizing then one would expect the teams to decide what they should be doing. Tailoring Scrum should therefore be left to the team and an outsider shouldn’t pass judgment on the team’s efforts. However, since teams don’t understand Scrum well at the beginning of their adoption of it the advice is to require teams to follow a starting set of rules and to only tailor them after you understand Scrum. But why should we believe the starting set works in all situations?

Ironically, many Scrum thought leaders believe software is so complex there is no causality you can understand. In other words, you need to just solve the problems as they show up. In other words, after you’ve tried things and learned them, then you should do things in a way that works for your situation. While this makes sense, it seems to have led to the current situation that if it works, we’ll call it “Scrum” but if it doesn’t, well, we’ll call that “Scrum but.”

The dilemma of Scrum becomes evident. While we don’t want to be prescriptive, when you learn Scrum there are rules you need to follow.  Then, as you get better, you can tailor it to your needs.  The unexamined assumption is that you can always do this.  I do not think it is as simple as this. I believe we need a real analysis of why teams accommodate their problems or why teams don’t follow certain Scrum practices. In other words, let’s get to the root cause of Scrum not working or teams doing “Scrum but.”  To do this, let’s use a Lean tool called “5-whys.”

Five Whys

When something goes wrong, we often jump to conclusions about what caused it. Even when correct, we often stop there – instead of asking ourselves, “well, what caused that?” In other words, we don’t get to the root cause.  Thus, even if we fix this problem, if the root cause is still present, it’ll likely cause another problem.  A popular Lean tool to get to root cause is called “Five whys.”  It basically is an a technique where one keeps asking “why something happened” until the root cause of the original incident which set off the query is uncovered. This may take anywhere from 2-9 levels of questioning – so “5” should not be taken as the exact correct number of “whys” to ask.

Let’s use Five Whys to determine root cause for accommodating impediments and “Scrum but”.

The root cause of accommodating impediments

One of the common impediments teams face in corporate-wide Scrum implementations is that team members are often assigned to work on several projects. It is easy to dismiss this on the lack of commitment of management. If it’s available for them to solve it, there is a kind of implication (and insult) that they’re not up to it – either in intelligence or in commitment. But the truth is somewhat different when one looks at the issue.  The question “why don’t they solve the impediments?” and “what do they need to know to remove the impediments the team is facing?” are questions that should be asked, but rarely are.

Teams often run into impediments whose cause are outside the team. The teams therefore can’t solve them. But why doesn’t management? For example, many Scrum teams are composed of members who work on other things besides their main project. This causes thrashing an delays.

Why does this happen? Because management believes that one of their jobs is to make sure that everyone has productive work to do.

Why? Because management tends to look at people’s productivity in making management decisions.

Why? Because productivity is what they have been taught and used.

Why haven’t they been taught more useful agile methods? Shouldn’t this change in Agile? Not necessarily.

Why? Because many Scrum thought leaders believe you shouldn’t teach much, just create a framework.

Implicit assumptions that may not be correct

Two (unexamined) tenets of Scrum are impediments that slow the team down will be recognized as impediments and that the team is capable of removing them. Besides my earlier statement that impeded teams may not have the capacity to remove the impediment I will go further and state that teams may not even recognize all of their impediments as just that. Many things that slow a team down are often just viewed as the way it is. There is no notion that it is an impediment. For example, I don’t consider the fact that I have to take planes when I want to travel long distances an impediment – it’s just the way it is. Now in this case, I think my perception of reality is correct (but it would be cool if one day I woke up and found out I could fly on my own!).

The whys of “Scrum But”

Let’s take another example of applying 5-whys to a common “Scrum but” – retrospectives.

Why is the team not doing retrospectives?
Because they don’t see the value of the retrospectives.

Why don’t they see the value of the retrospectives?
Because they think there is more value in doing their work.

Why do they think there is more value in doing their work?
Because the retrospectives haven’t really done anything for them.

Why haven’t the retrospectives done anything for them?
Because they often don’t get agreement on what to do.

Why don’t they get agreement on what to do?
Because they think software development is about intelligent people using their judgment – that is, there are no real rules to use or a scientific method to apply.

Why do they think this?
Because software is so complex and no one has presented them with a theory to explain it.

BTW: This is one reason I talk a lot about the theory of flow underneath Lean-thinking. I have seen that it can provide a thought process that helps unite the team.

The dilemma (faulty thinking?) of Scrum

Scrum is in a dilemma here. On the one hand, Scrum is based on being a light framework that doesn’t give a model to work from. On the other, without such a model many Scrum practitioners don’t realize the importance of the practices or how to manifest the affect of the practices in their own context. It seems that the reaction has been to insist that certain practices be done (at least at the start) – which is ironic because Scrum is not intended to be prescriptive. If there isn’t a model, then how can one tell if one is doing Scrum? The common thinking is that you’re doing Scrum if you are removing your impediments, but you’re not doing Scrum if you are accommodating them. This, of course, assumes that Scrum can always work – a dangerous assumption, in my mind. It also makes it very difficult for new teams to know how well they are doing.

Getting beyond “Scrum But”

To get beyond “Scrum But” one needs to be able to understand when the practices of Scrum work and when they don’t.  I believe this requires both an understanding of why Scrum works and a scientific approach in how to apply these rules.  Unfortunately, I have not seen the Scrum community embrace this approach.


Smart People, XP and Scrum – Is there a pattern?

This blog was originally written January 2010.There is a division in the agile community about whether one should rely on people or focus on people supported by systemic thinking (no one I know of suggests systems alone are enough). This debate is often the people over process vs. people and process (or as Don Reinertsen would say people times process). I’ve been in the agile community for some time and have seen some interesting things that I think shed some light on this debate. This long-time perspective has enabled me to see an interesting pattern. This blog will discuss the pattern of what happens when smart people do not have the proper understanding of what they are doing.

I’ll start with what I consider to be my most embarrassing moment in my career. It was in 1984, 14 years into my development career. I contracted to build what would be the software system to power the touch controlled information kiosks at Vancouver Expo ’86. At the time, this was very avant garde. I was essentially in charge of rewriting a Basic language prototype into C for both improved performance and features. Since I was experienced in both languages, I remember thinking it’ll be easy – it’s just a re-write.

There were two main components of the application. Mine was the user component that defined how the system should work. Basically you entered events on a timeline that the system would run when the screen was touch. The other was a run-time component that ran the pseudo code mine compiled. I sub-contracted someone else to do the executable program because mine looked to be the more complex beast. At the time, I had a reputation for functioning code extremely quickly (and yes, I intentionally did not use the word maintainable).

It only took me a few week to get the basics of the system up and running – everyone was pleased. I was confident of success because, given this was a rewrite I figured the customer would know what was needed and I would just be adding functionality. Unfortunately, after they started using the system for a while bad things started to happen. It seemed every time they wanted a new input feature (e.g., specifying when a new event, like touching the screen, or starting audio) I would put it in quickly and it would work, but a couple of days later I would find out that I broke something that had been functioning. The problem was that I had tightly coupled code and was not following Shalloway’s principle. Up to this time I had studied how I could code better (e.g., structured programming, etc.) but hadn’t done a study on what caused errors (e.g., tight coupling, lack of encapsulation). BTW – this is not the embarrassing part yet.

The next few weeks followed this pattern – 1) get a customer request, 2) get the request working, 3) be told by the customer the next day or two that something else was no longer working, 4) fix the new bug. This extra bug fixing work was taking a considerable amount of time. It was clear that we were in serious trouble. Now, with what I know today, I would have concerned myself with writing better code (stopping errors instead of fixing them). But what I did back then was recognize that I was causing bugs because I just wasn’t finding all the coupled cases (I was unaware of Shalloway’s Law at the time – in fact, it was this experience that inspired Shalloway’s law). I figured if there were just a way I could tell I was about to commit an error, I could continue programming fast. The problem of having to type something in several places didn’t bother me. At the time I could type about 100 wpm (not my highest speed, but still pretty fast).

I thought the answer to my problems was detecting errors quickly, and (mostly) effortlessly. So here’s what I did. I spent a day essentially writing the equivalent of a UI Test runner and sub-contracted someone to run the tests for me. While I could re-run the test cases automatically, I needed someone to set them up and check the results against good cases. I had basically instituted semi-automatic acceptance testing in 1984 (still not the embarrassing moment – this was actually pretty cool).

From this point on we zoomed along. My quick coding style was no longer holding us back. I’d make a change, give it to my tester and within 15 minutes he’d tell me what I unintentionally broke by forgetting to change something that was coupled to my fix.. I fixed it almost immediately because I knew it was something I just changed. Bottom line, we got our system out in very good time. We even became a real product whereas we were originally only supposed to be a tactical solution for the Expo. The strategic product was being built in parallel with a longer timeframe and 30 people (compared to our 4). However, our product ended up being better so they released both.

So what’s embarrassing about “inventing” automated acceptance testing in 1984 and building a product for my client within budget and time while exceeding functionality initially envisioned and with a high quality? It was that I didn’t do automated acceptance test again until 2000 when I read about XP.

This episode was one reason I knew XP would work the moment I heard about it. I had done an iterative, close customer, automated acceptance test, continuous build (there was only me! ) project 16 years earlier. Only now I had 16 years of experience in considering what made for good programming.

This was why I immediately questioned why XP worked (not if, I was clear that it did). I remember this not being very well received. At the time, Kent Beck and Ron Jeffries (two of the originators of XP) pretty much insisted that you had to do all of the twelve practices of XP or you’d lose its power. There was also little in the way of explaining how to code.

Yes, I know about the four rules of writing simple code:

  1. The system (code plus tests) clearly communicates everything that needs to be communicated at the current instant in its development. This means that it runs every existing test, and that the source code clearly reveals the intention behind it to anyone who reads it.
  2. The system contains no duplicate code, unless that would violate (1).
  3. The system contains the minimum number of classes possible without violating (1) or (2).
  4. The system contains the minimum number of methods possible, consistent with (1) (2) and (3).

The problem with this definition is that it is practiced based. It also is stated in a way that is understandable to someone who already understands these practices (that is, has intuited the principles underneath them) but will cause great misunderstanding for those that don’t have this intuitive sense.

Of course, Kent, Ron and Ward (the third originator of XP) are all brilliant developers and had the necessary intuition. Unfortunately, most of the people getting excited about XP didn’t. I remember talking to several of my associates about XP and said that without the proper understanding of what was underneath XP (something no one wanted to talk about at the time) there would be serious problems for any undertaking it. I even gave a time frame – 6 months. Now be clear, I though XP was brilliant. I just said it was dangerous without the key understanding of it. Sure enough, while many people had great success, many others had great problems with code poorly written (ironically, mostly in the test code).

Those of you who know me know I’ve said pretty much the same thing about Scrum. I’ve written on why it works and why it doesn’t. Ironically, here, as in the XP case, my comments/concerns were pretty much ignored by the Scrum community. Today we have many (most?) Scrum teams practicing what the Scrum community calls “Scrum-but” (that is, we do Scrum, but …”). I wrote a blog on this as well The 5-whys of Lean as the answer to the but of Scrum. Even Ken Schwaber, Scrum’s co-creator and biggest evangelist, has said, I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

So what is the pattern of these three things?

  • My not doing automated acceptance testing for 16 years
  • XP teams running into code problems after a few months
  • The prevalence of Scrum-But and the general lack of success by many companies undertaking Scrum

I would suggest it is counting on smart people to find the right thing to do is not always a winning strategy. That giving people understanding of the principles and rules underneath programming and development will make them much better. I admit this begs the question that I am a “smart” person. But, I do think I qualify – summa cum laude, 2 masters degrees (one from MIT), successful author, have run a successful business for 11 years (and still going), … I’m not trying to toot my own horn here. In fact, I’m saying, how could someone as smart as me do something as stupid as not use automated acceptance testing for 16 years (isn’t that embarrassing?).

Well, my answer is that relying on practices even if you are smart is insufficient. You must learn why those practices work. Of course, this makes sense only if you believe there are rules underneath what we do. Many in the agile community don’t believe this (I’ll be writing a blog on this next week). Bottom line for me is, get the best people you possibly can. Then, make sure they study their methods, as explicitly as possible, so they can create solid, support systems and understanding of what they do. You will get a much greater return from their efforts if you do so.

In my case, the understanding would have had me look to see where I could apply automated acceptance testing effectively. Years later, I now understand that one key aspect of automated acceptance testing is to eliminate the added work that comes from the delay between code and test. I clearly knew this at some level in 1984. But not at a deep enough, or consciously high enough, level to take advantage of it on a regular basis.

XP has been around long enough that people have finally gotten to the why it works. In Scrum’s case I believe we find people doing Scrum But because their lack of understanding of the principles underneath Scrum prevents them from effectively changing the given practices. They often think they are doing the right thing, when in fact, it is not effective.

This is why, at Net Objectives, all of our training and consulting starts with why things work. If this makes sense to you, and you think you can use some help in doing this, please send me an email alshall AT to see if we can help.

If you want more information on what we now consider to be useful principles and guidelines for coding better, check out these resources pages (you’ll have to register to get access to some of these):

Challenging Why (not if) Scrum Fails

This was originally published in May 2009

Virtually 2 years ago I wrote a blog called Challenging Why (not if) Scrum Works.  Basically, I was looking to see why Scrum worked so I would be able to best take advantage of Scrum. I believe Scrum works very much due to the structure of the team, the iterative nature of development and the proper context within which the team works.  In this prior blog, I reported my experience with teams that were co-located, had all team members work together and worked on only one project compared with those who were not co-located, had team members of different roles report to different managers so they were not always working together and these same people were typically on 3-5 projects at once. The co-located teams were three times more productive than the other ones – even though the people, domain and customers were virtually the same. I thought this was a great insight for two reasons.  First, it meant if you couldn’t deliver (or even build) in increments, there were things you could do to improve your development methods.  Second, if you could do incremental development, these practices were some of the first things to implement.

Continue reading “Challenging Why (not if) Scrum Fails”

Going Beyond Design Patterns

This was originally published August 2012

In our Design Patterns Thinking  course we quote Christopher Alexander’s Timeless Way of Building – the book that inspired the software development community to create design patterns. Most everyone familiar with design patterns is familiar with Alexander’s phrase “patterns are solutions to recurring problems in a context.” However, my favorite quote of Alexander is 4 pages from the end of his 549 page book –”At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real.”

For those new to patterns, these two quotes may seem contradictory, but to readers of his book and attendees at our course, the typical response is “yes, I already knew that.” Design patterns are solutions to a design problem in the way recipes are solutions to a “what do I want to eat?” problem. Learning design patterns as solutions to recurring problems in a context in order to be a great designer is like learning how to be a great chef by learning recipes. While useful to a degree, it is not very effective to become a master.

We need to remind ourselves that patterns are examples of solutions given a particular set of issues to be dealt with. The Gang of Four’s set of 23 patterns provides a meta-pattern that can teach us how to handle variations in a problem domain. Our Design Pattern Repository lists patterns by what they encapsulate. This is an extremely important insight. In both Agile and non-Agile teams, requirements will change – the biggest differences are: rate of change, size of change, and how we prepare our code for the change.

Most new requirements change in how a concept is to be implemented more as opposed to a totally new concept emerging. Code is often written as “this is the way it’ll work” and therefore is not well prepared for when a new, different way comes along. When we truly understand the thought process of patterns, they will provide us with a different way of looking at the world. I discussed this in my article Can Patterns Be Harmful? as well as my book Design Patterns Explained: A New Perspective on Object-Oriented Design. In other words, patterns don’t just provide us with good solutions, they can provide us with a thought process in which to achieve quality solutions to unique situations for which no current pattern exists.

The focus on patterns as solutions is unfortunate. The insistence that patterns are discovered, instead of created, obscures the fact that there is a thought process underneath these patterns. This thought process is worth discovering.  One aspect of this thought process is how to refactor code using the knowledge of patterns – something called “refactoring to patterns.” I introduced this concept in our first design patterns class in 1999 (as well as my aforementioned book). It provides a basis for refactoring quality code as needed using the thought process of patterns. You can learn more about this in the Refactor To The Open Closed chapter in our Essential Skills for the Agile Developer: A Guide to Better Programming and Design book. This is also discussed in the Avoid Over and Under Design chapter the same book. If you prefer webinars, watch Avoiding Over and Under Design in Agile Projects.

If you want to learn more, the best place is to take one of our Design Patterns classes. We currently have one scheduled in Seattle – Design Patterns for the Agile Developer, October 30- November 1. If you are in another city and have 4 or more folks interested, please contact Mike Shalloway ( and we’ll see if we can schedule a course near you.