The Horror Of The Scaled Agile Framework

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone


I’ve just watched a presentation that’s made me so angry it’s prompted me to write my first blog post in ages! Sorry I’ve been away so long :)

I’m not a fan of the “Scaled Agile Framework” to say the least. Dean Leffingwell is in on this, a man who I generally find myself agreeing with. However this framework is a horrible, pure money-making bastardisation and Frankenstein of Scrum, Agile and Waterfall that is being sold to large companies who are too afraid to really change and just want to increase productivity, reduce defect counts, etc. and find a place in the “Agile” world for their managers.

The whole concept of iterating over a product rather than simply incrementing features is fundamental to Agile and Scrum but completely bypassed with this framework. Continuous delivery in order to tap into the market as early as possible and adapt the product is ignored (instead a 2-day release plan meeting is held in which all the features the PM wants done in the next 10 weeks are broken down into user stories and put into Sprints – yuk).

There is even a “hardening Sprint” which is a fancy term for a 2-week phase for bug-fixing and deployment activities because companies “really need it” (read it’s too hard to truly get things “done done” so we’ll leave time for it at the end – of course “the end” is a deadline date based on an estimation of how long all the features will take to build – i.e. guesswork around fixed requirements – ring any bells?). Yuk yuk yuk!

Scrum scales perfectly well without this framework, thank you very much! Each product has a backlog, which is derived from an overall program backlog at the portfolio level. Each product has 1 to many synchronised teams – done! Why synchronise the whole frigging organisation’s product development?! Yeah like that will work. Means any one team can’t adapt their process because it’s locked in to the organisation’s “Agile” framework.

Scrum-at-scale is far better because it holds true to the founding principles of Agile and Scrum but also allows hundred of people to be working together towards a common goal. If the business needs to change program priorities then they can do because they are doing Scrum! Simply cease work (if required) on the product or work stream that is being moved down the backlog at the end of the next Sprint and start the team (or a different team) on the new product.

Rant over – for now! Be interested to hear what others think.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

27 thoughts on “The Horror Of The Scaled Agile Framework

  1. Interesting article. I found it while looking up information about the Scaled Agile Framework.

    There is a good chance I will be working with this approach in the near future and I would have loved to see a constructive discussion in the comments section about the pros and cons concerning the opinions in this article.

    Without any experience with this method myself, the case being made here seems valid and matches my expectations. But in real life things are seldomly purely black or white…

  2. “companies who are too afraid to really change and just want to increase productivity, reduce defect counts, etc.”

    Increase productivity and reduce defect counts? How dare they have those goals in mind!!!

    Sorry Neil, I don’t have a strong opinion about SAFe yet, but it sounds like you are an Agile purist and feel that businesses should fall in line with your thinking “just because”. I’m afraid in most companies I’ve worked at change is slow and painful… Making change more acceptable to the slow-to-change is a great strategy in my opinion.

    1. I believe that the enterprise synchronization is particularly hurtful, that is: trying to change everything with one big change, trying to get everything on the same page “just because it’s enterprisy to have one way of doing it”.
      Instead, introduce the change in the small – ie around products. When you can get 3 (smaller = less change) products to truly work in an agile way (whatever you define that to be), move on and adress the rest.

  3. Neil, I respect your opinions on this, but I think SAFe has some merits. It is, after all, based on Scrum and XP, with a lot of lean thinking and Reinertsen mixed in. One thing that I see would happen in optimizing the whole agile release train as opposed to starting with individual teams is that you might not get the kind of productivity gains you get transitioning using Scrum on a team by team basis. I think Ron Jefferies got it right with his title:’Good, but not good enough’. I believe there is nothing we can rest on, except maybe our values and principles. Any belief, practice and by extension, framework, must be subject to rigorous and empirical review. Lets see how well SAFe or for that matter, any of our beliefs, stand up to inspect and adapt.

    But I echo the sentiment above. An open debate will take our art, craft and meaning forward – In any event, I’m for rejecting dogma in favor of relentless pragmatism, and taking back the agile principles and values. Open to your comments!

    1. Ewan
      SAFe does have its merits and the biggest one is holding hope to much of management that all the improvements that come with Agile in general and Scrum in particular don’t really upset their organizational structure.

      Will SAFe have an impact on the topography of Agile implementation? Yes and it will be useful as long as practitioner organizations don’t have to compete against good Scrum and Agile practitioners. You already know them. They are the ones whose focus is on getting better meeting customer, regulatory, and legal changes while having fun doing it. Read Craig Larman and Bass Vode on LeSS for a better understanding.
      What makes SAFe a hopeful way to look at change and offers a silver bullet from the lone masked rider. Bad news, All Agile methodologies and Scrum in particular destroy all hope like this.
      Unlike hopeful approaches to change, scrum serves as a very crisp mirror making transparent all of the fallacies one hopes to preserve. Unlike hope filled approaches, Scrum let’s you see immediately what the impact of any change you make.
      The hype about ScrumXP. Old news. Most practitioners of Scrum and many CST’s and CSC’s have been rolling the two together for almost a decade. As far back as 2004 leading members of the Scrum and the XP communities were quietly collaborating.

      So you can go the SAFe path or the Scrum and Agile path. All you need to do i figure out how big a cliff you want to deal with down the road.

    2. Ewan – small detail while SAFe includes the mechanics of Scrum much of the spirit that makes it work seems to have gotten lost. Based on my initial encounters with SAFe it seems like a **starting point** for becoming more effective. Unfortunately I’ve already seen applied as a veneer for the current organizational dysfunctions.

      When I have about a week of spare writing time I will detail all of the issues I’ve seen.

  4. Thank you Neil for an excellent rant .. I mean blog. The tone and language is not nice and I find it refreshing among the tepid “SAFe maybe is not that bad at all” or “Agile at large-scale is something that needs a framework”.
    Large-scale Agility framework bring in what I call “institutionalized dysfunction”. Instead of removing a dysfunction (for example need to re-work after Sprints) it makes the dysfunction official and valid part of workflow (“stabilization Sprints”).
    Another dysfunction is large-scale as such. I have seen much more unnecessary large organizations than organizations that suffer from lack of large-scale framework.
    To be truly Agile, we should look into what matters to customer, organize ourselves against that demand (“inspect and adapt” as some would say) and have as small projects as possible.
    Unfortunately, this is not safe enough (pun intended) for management. They are willing to put big money to keep their empire large and make sure no-one thinks too much.

  5. “Yeah like that will work.” I am very sorry, Neil, to disagree:
    Just because there a so few ‘experts’ around who ever successfully delivered a 100+ people product, that does not imply it is not possible to do so. It simply depends on the guy who is orchestrating the concerto.
    Those who know how can do it with or without Scrum, with or without SAFe, with or without RUP. I signed Agile Manifesto back in 2003 – and I never worked different than agile, not even between 1989 to 2003.
    BTW, maybe someone can help me here to clarify one thing quite mysterious to me: Where in the Scrum guide is stated that you may not use a diagram for depicting usefule information to the people involved?

  6. I agree with a lot of what this article says, but it doesn’t address an alternative for those companies who are, in fact, afraid of moving to Agile. What this article seems to imply is if companies who are unwilling to move toward a more pure agile implementation, well, that’s just too bad for them. This is, I believe, has been the #1 problem with the agile movement to date. It’s also the #2 problem and the #3 problem.

    The article also seems to imply that continuous-delivery is the Utopian goal of any organization that developers software, which it is not.

    In my opinion, the Scaled Agile Framework is the only process that effectively demonstrates how Portfolio / Business can participate in the process.

    Also the ‘two day event’, knows as the Release Planning Event, is valuable for large organizations with remote teams and executives. They can dedicate the time to meet in a common location where questions can be answered and issues resolved. Don’t underestimate the power of this. I’ve personally witnessed organizations resolve issues in hours rather than weeks simply because all stakeholders were physically there and available for an impromptu-meeting.

    I do agree with the author with regard to a potentially-shippable-increment is a bit of a step backwards in that it smells like waterfall. There’s some truth to that, but I wouldn’t go as far as saying it’s watefall. I think it’s more like a mini-agile project. Think Extreme Programming (XP) — you have a fixed date, and you have a backlog, and some rough-story points assigned to the backlog so you get an idea of how much you can do in the PSI (Potentially Shipable Increment). The scope always changes once the PSI starts, just like a normal agile project. This is handy when the business doesn’t want continuous delivery.

    I don’t recommend Scaled Agile Framework when the business is able to adopt a more pure-agile process. But if they cannot, because of size, team-distribution, etc., SAFe is the best there is. Don’t hate.

    1. Hi Kenneth, and thanks for your comments. I wrote that post over 2 years ago, so my views have evolved since :)

      You make some good points. There are some great ideas in SAFe for sure. With good coaching, and a recognition by senior management of how they will need to change the way they think about how work is organised, it might be an effective option :)

  7. Thanks for the post. It is important to robustly question working methods. Although I do not see SAFe as the perfect solution for larger scale Agile work (if there can ever be such a thing!), I have seen some benefits from usage of SAFe in its entirety or some of its techniques individually.

    From my own experience when scaling using a Scrum of Scrum approach and/or an Agile self-organising team of teams and stakeholders, I have found that something similar to SAFe emerges fairly naturally in any case.

    The self-organising groups have realised fairly quickly, particularly on larger development efforts involving 50+ people, some of the benefits of alignment of cadences and planning, some program-wide alignment of architectural and ux views, assigning long running budgets rather than using projects to wrap pre-defined feature bundles and combining Scrum and XP practices in the development teams (something which most Scrum teams do naturally anyway).

    It is also worth noting that your concerns about batching features for releasing rather than releasing on demand is not really an issue with SAFe. Although this was not very clear in the SAFe 2 model (because of the “H” in HIP sprint and because release was not a separate swim-lane in the cadence) there were statements in the course-ware about “deliver on cadence, release on demand” that clarified the position.

    Release on demand is made much clearer in SAFe 3 where the “H” is dropped from the HIP sprint and a release line is graphically decoupled from the development cadence.

  8. Neil, I agree with you that Scrum scales perfectly well without SAFe. I have always used a Scrum of Scrum team that handles the strategic stuff, like making trade-off decisions on feature/epic, and decide on the content of the upcoming release based on remaining work and team velocities, etc. Even in large organizations, that was enough.

    Although a hybrid approach could perhaps be helpful to make a stepwise transition toward a company-wide Agile way of working, the pitfall is that it may institutionalize organizational dysfunction. A true transition toward Agile, on whatever scale, requires an Agile mindset of everybody involved, especially higher management. And that’s where the shoe pinches.

    Neuroscience has recently discovered that people (in a business setting) may respond to uncertainty and unpredictability in a rather instinctive way, comparable with the brain’s reaction to pain. If there’s not enough information, our crocodile brain will characterize the situation as ‘not safe’ by default. So that might be part of the explanation why old-school managers don’t want to let go of the V-model, and rather choose for a hybrid model to stay in control.

    For more background, please read my blog entitled: ‘Two Religions on One Pillow’, to be found at:

  9. The comments have been very interesting. However, I am confused.

    My organization’s issue is not how to do one product well. It is which products to do and which not to do with a wide variety of different stakeholders.

    How do you handle product effort intake?

  10. I think SAFe is the latest hype to make money. I have been working with agile for the past 7 years. My company requested I attend a course on SAFe and get certified. I took a class that Rally sponsored and it was awful! After the class I spent some time reading the materials and they studying the framework. I took the test and was shocked at how poorly written the questions were on the exam. Then when you are finished, you are not even given an explanation of what you got right or wrong. Thankfully I passed but barely!

  11. We have implemented SAFe in a very large IT environment. Change is hard. SAFe is the only agile framework out there that focuses on change mgt. Moving from a waterfall/pmi mindset to pure agile take years, and SAFe is a great way to make incremental change towards the ideal. Most of the comments above sound like they come from folks that work at the lowest level of software/services delivery and forget that there actually is other important concerns of running a complex business like budgeting, alignment to business strategy, and investment prioritization in an environment of constrained capacity.

    1. @worksofwisdom

      I agree that in a huge lumbering multinational, change management and predictability of end result are huge factors with massive potential risk. SAFe may well be a very appropriate tool in that environment.

      I suspect that some of the criticism is from people, who as you say, work in a context where the concerns expressed about SAFe place less risk on the organization than others – as an example, in a company with ten developers – the risk of two of them leaving because of a methodology perceived as being inappropriate being “imposed” upon them, may be of far more danger to the health of the organization than the advertised productivity gains for SAFe over a more raw agile approach.

      There are no silver bullets in software development – which, in my experience, is a case of the appropriate risk management in the context of the environment in which it operates.

      For some companies, SAFe may be a well considered improvement. In others, where it may not be the best fit, it could be seen as the symptom of out-of-touch management.

      The answer to – “is SAFe appropriate” – is the same as any other process – it depends on context.

  12. As an experienced Scrum Master but someone who is new to enterprise scaling and is currently 2 years into a SAFe project I had a reply in mind as soon as I read the article, but then I read further and saw Kenneth Kasajian’s response. Kenneth’s reply says *exactly* what I currently think of SAFe, and more eloquently than I would have done. I was also heartened to see Neil’s change of position since he first wrote this piece.

    SAFe and its alternatives do have a place in the world for organisations who are currently too structured and rigid to transform their business processes overnight. Agility is a journey, not an end state (continuous improvement), and only ever a means, not a goal in itself.

    Unfortunately this blog doesn’t have a ‘like’ button, which I’m afraid all this comment really is!

  13. While I applaud any effort to examine and improve development and quality assurance QA processes, in general SAFe fills me with the same foreboding I felt the first time I was exposed to the ISO9000/1/2/3/# juggernaut, and the many analogs spun off by the burgeoning business-management industry (you know who you are) after a comparatively painless introduction to QA through the 14 points of the Deming model. I’ve seen children embrace and execute Deming’s approach successfully; very few adults (even those with Masters in Business Administration) are as successful with ISO900X, even with the requisite certifications under their belt. Agile methods are perhaps less kind to corporate structure than SAFe, but better minds than mine have already suggested that many of the problems our industries experience are the fruits of our management empires — perhaps less pain infers proportionately less gain.

    Although it may be heresy to voice such a philosophy here, I would cautiously suggest that Agile (in all its many divergent flavors) is more logical, easily adopted, and profited from than yet another five-page process-chart-driven paradigm of the SAFe flavor. The KISS principle (Keep-It-Simple-Stupid!) has weathered many innovations and criticisms, and will no doubt serve magnificently long after we and our various preferred abstractions are dust in the wind. Simply adopting SAFe as a sop to anxieties felt by upper management is like prescribing topical anesthetics for every ill; it will unarguably lessen the discomfort, but may not serve the best long-term interests of the patient.

  14. I am an almost extinct dinosaur in IT that started fresh from uni in 1976 as a programmer/analyst working in small teams for a consulting firm. We worked directly with clients and achieved great things. I can still recall my horror when assigned to my first client with a large waterfall project – I had become so used to direct contact with business people and having a voice. When first reading of Agile, there was a sense of deja vous and joy as the shackles smothering IT were being removed. Unfortunately, I had moved into the BA space and my assignments were more giving stakeholders a voice in the corporate space.

    The question of how to control IT has been present since day one and the tension has been between finding money and realizing the vision. If a corporate vision is not there, stifled or just profit, then SAFe is a good starting point as it synthesizes a vision from talented (hopefully) upper management and incorporates the bean counters.

    Agile (and SAFe?) taps into and enables the creativity of all people in a team rather than limiting this to a BA like me. In Agile my role is to facilitate, ask dumb questions and add experience that spans many businesses.

    Agile also extends creativity to the business people that participate, so what does an organization do if creativity is not permitted or heavily scrutinized due to cost or risk concerns? It uses a rigid framework to tame creativity and play it safe. There are many businesses that do not need creativity and this is a hindrance for Agile. SAFe is an interesting approach as it creates a rigid controllable framework which tolerates or even promotes creativity at the lowest level.

    The other thing present since day one in IT is the cowboy managed project – deliver quickly and head into the sunset before the dust settles. Agile has been used by many to bring back the cowboys – no documentation, the business still does not have a voice, but everything happens quickly. To me, an important function of SAFe is providing a safety net for organizations that would otherwise fall into the cowboy Agile space delivering short term IT cost savings.

    Please excuse the waffle (my prerogative as a BA). People are the most important part of IT evolution with personalities, modalities and other human traits having a major impact. Choosing scaled Agile, SAFe or classic waterfall for a large organization is more dependent on the comfort level and attitude of senior management than market pressure. Is a development team member an important creative person or a disposable resource to be exploited?

Leave a Reply

Your email address will not be published. Required fields are marked *