Project Management

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

From the Agility and Project Leadership Blog
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog


Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility

There was this great movie back in the early 90’s staring Bill Murray who plays a weatherman covering the annual Groundhog Day event (which is an odd tradition in the US wherein the emergence of a groundhog supposedly predicts when spring arrives early or not).  He gets stuck in a snow storm and gets smitten by the lovely Andy MacDowell but turned down cold in the pursuit of her.  Of course the most interesting thing about this move is that he gets stuck in some weird time warp and has the ability to re-live each day up to his pursuit of his love focus until he gets it right.  Lots of laughter and hijinks ensue making for a highly entertaining and fun filled movie!

Unfortunately, the recent rise and popularity of the Agile SAFe (Scaled Agile Framework “for the enterprise”) makes me feel as though I’m like the Bill Murray character but without the ability to get it right but still feeling as though I’m stuck in a déjà vu like experience.  But let me preface this by stating that I don’t want to diminish the hard work of the people who outlined this framework nor the “ideological” basis of it, which sounds pretty good on paper.

Yet I can’t help but feel as though this movement (and this isn’t the first proposal of scaling Agile… remember the “Scrum of Scrum” idea?) has many parallels with the traditional PMO/PPM model from the traditional community.  When the traditional prescriptive-oriented model started getting a hold in the workforce and done with a modicum of success, people had the bright idea to try and scale it up so that the organization as a whole could start benefitting from doing standard PM practices. 

But from my own anecdotal experiences as well as studies I’ve read from PMI and various other sources, this did not really work out so well.  The idea was to create project center of excellences, but instead just ended up slowing people down as they got drowned in processes, governance and standardization methodologies and documents telling them how to do everything with the possible exception of tying their shoes!  But in this process heavy prescriptive model, you have a framework that could at least support projects being delivered collectively in a mediocre McDonald’s like consistent way.

But let’s face it, as I’ve mentioned it on this blog some while ago, Agile is light because it assumes that your people are heavy.  This means your team, project manager and some person who is acting as an ambassador for providing your well-defined and meaningful business requirements (a.k.a., the Product Onwer in Scrum lingo) are heavy duty, high skilled “can self-organize” types of people.  Without kick-butt people, this whole Agile shindig will fail.  And if I’m not mistaken, very few companies have a whole bunch of these types on their payroll.

So the while the idea of scaling Agile is great, in practice I think it will be super freaking hard to nearly impossible.  Whatever the case may be, it’s not going to stop people from trying and creating more frameworks, training programs, consulting and certifications (Is the SAFe certification like PMI’s OPM3 certification but done faster?).  As Einstein once said, “insanity is doing the same thing over and over again expecting a different result!”

Is this a fair assessment, or am I just being overly glib and facetious?  Let me know! 

Posted on: January 31, 2015 09:15 PM | Permalink

Comments (36)

Page: 1 2 <prev

Please login or join to subscribe to this item
Groundhog day was one of the best movies ever! I would say to work with whatever makes you and your team happy and more efficient as per your own standards. I currently have two teams, and one of them is implementing full Agile/Scrum methodology and the other one is in pure Waterfall. both are doing great! I would say it depends of the nature of the project, team members background and likes.

How about using a truly Agile approach and make the selected method suit all stakeholders and context. So make it fit the complexity, customers, team, organizational culture etc.

Great post. Thanks for sharing.


very good job, very interesting article. May I have the diagrams of this post in a better resolution (o bigger size), they are not really very readable.
Thank you

Don, excellent post. Very good information. Everyone, you can click on the actual diagram and it will enlarge. There are actually links within the diagram itself which provides much more information about the icon you selected.

I made an earlier comment when I was first starting on this "SAFe" project, and now I've had lots of experience. The key is to not get too hung up on the methodology, but rather to focus on adapting what you know to the individual situation. For example, if you are having an issue with customer involvement, shore up your business analyst capabilities on the scrum teams to ensure that you are providing a firm and clear line of communications. There has been lots written about how virtually all projects are hybrid - with pieces of waterfall and agile. It's up to the PM to ensure the most optimal organizational configuration and processes are in place. Stuff will happen - and you need to anticipate or respond in kind...

I guess the verdict is still out. However, as our BOD member shared, market-based solutions seem to be better than a one-size fits all approach and then try to drive the market to it.

Thanks for sharing. Luis

Thanks for sharing

May I quote you, " Agile is light because it assumes that your people are heavy." It gets at the crux of the entire issue. Trading skill for process and method has worked well in many areas where the work has a repetitive component to it. And has allowed relatively unskilled people to create highly complex and detailed products as lower cost and higher volume. But as you point out, the idea of doing that with software development has failed time and time and time again.

So why is that?

My best guess is that it is the result of two elephants in the room that almost everybody appears to just ignore.

1. Software development is not a repetitive process.
2. And as you point out, skilled people are hard to find.

Each newly developed software product is a creature unto itself. It's not like making houses. You build the same house plan many times, but you only build the software once. So you don't get most of the benefits of process and method with building software as you do with houses. If houses were software, then each house would be a craft home, never the same plan, never the same framing structure, never the same milled lumber. Add to that, the idea of software as it works in the world is a moving target. Whereas, stick platform construction with dimensional lumber has been a constant for house construction for at least the last sixty years.

For the second point, skilled people are hard to find, the first fully operational Von Neumann machine came online around 1950. At that time there were no more than a few hundred programmers in the world, and that is probably optimistic. In 2014 IDC estimated there were over 18 million programmers. If you fit an exponential curve to this, you get a doubling in programmers every four years. If it takes 8 years (stackoverflow data seems to indicate this) to become competent as a programmer, that means that three quarters of all the programmers in the world are incompetent. Of the 25% competent programmers I would expect half of those to be what you refer to as "heavy" with around 12 years of experience. So 12 out of every 100 programmers would be good candidates to be agile developers. Now maybe 12 years is more than needed, but you get my point. As long as the demand for programmers keeps doubling every four years there will always be too few heavy programmers to supply the need.

Which brings us back to process and method, I can see how so many people wished it would work when developing software.


Hi Don

I agree with you on every point. Also with Lawrence "you can't scale Agile - but you can be agile at scale..."

On the point about people thinking up new names, or acronyms, for old concepts "Servant Leader" got my goat as Dale Carnegie was writing and lecturing the exactly the same management and motivation methods 50 years ago :-|

Thanks for sharing

Thanks for sharing

Thanks for sharing

Hi Don,

Great article! I am consulting with a very large global company, which is starting their transition from Waterfall to SAFe. I am working on the InfoSec transition. Your comments could not be more accurate - thank you for sharing.

Page: 1 2 <prev

Please Login/Register to leave a comment.


The only people who find what they are looking for in life are the fault finders.

- Foster's Law