The Horror Of The Scaled Agile Framework

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

bride-of-frankenstein-boris-karloff-1935

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

21 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: http://www.improvement-services.nl/blog/?p=475

  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?

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current ye@r *