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 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.
Neil, I want to take time to digest your post before I respond to points but I felt compelled to make an initial response. I’ve read Dean’s book and have even taken the 4 day course on the Scaled Agile Framework. I want to open a unbiased dialogue with you on this as I disagree with some of your take aways from the framework. Who knows, maybe we both can learn something. The one thing I will say is that when I’ve spoken to Agile fundamentalists I get some pretty biased responses that aren’t well thought out as they regard to real-world practices. However, based on your bio’s you don’t seem to fall in the fundamentalist category.
Hi Steven, and thank you for your comments.
Would be delighted to have an unbiased dialogue with you! The blog post was an angry rant at the time, but re-reading it I still mostly agree with what I said
By the way, I love your use of the term “Agile fundamentalists”!! Agile has become so dispersed in its meaning and supports such strong values that people are very passionate about it (rightly), almost to the point of religiously and as such can also get very defensive and protective about their chosen path (wrongly), inhibiting learning and improving. You are spot on there.
As for your first comment in the dialogue, I agree entirely
Overall I guess where I’m coming from is that, while there maybe some good things in the framework, it does smack of just another trademarked off-the-shelf Agile method; another money-making scheme that makes it easy for companies to “buy Agile” (the topic of my upcoming talk at the LAST Conference in Melbourne) rather than figure out their goals, try and learn and improve, etc. What I’m seeing is companies taking the easy way and adopting a plug and play approach to Agile. Becoming a learning organisation that continuously improves its effectiveness is not easy – in fact it’s really, really hard, and I just worry that many folk still see Agile as a silver bullet to “getting teams to deliver faster”. Would love for that not to be the case 
Okay, I’ve done my share of rants (often at the most inappropriate times, but that’s my problem) and they are always rooted in some kernel of truth as I see it. One thing we can obviously agree on is the bastardization of Agile and the perversions layered on to suit either people’s selfish needs or their ignorance. I’m sure we could share war stories of the things that people have passionately preached or practiced that experience tells us either doesn’t work or is nowhere in keeping with the spirit of Agile and Lean thinking. The first fundamentalist war-cry I try to knock down is the ‘silver-bullet’ belief. In fact, I believe there are some scenarios where some adherence to a waterfall process not only works but is needed.
.
Can we agree that while the spirit of Agile is not a heavy handed set of rules to corral a companies IT department there has to be some level of organization and common understanding whether the group is 10 or 10,000 bodies strong? If you agree to that then logically someone has to create and disseminate that common understanding. I’m not saying it has to be any one person or groups set of mandates, just that someone has to do it. Now, let’s take a moderately sized organization. The personalities are diverse, the goals and aspirations are diverse, the skill sets are diverse, and experience is unique to each individual. Approaching this group and saying we want you to adopt a process that is self organizing, seeks growth and enlightenment, and is not adverse to change but we aren’t going to tell you how to do it. The first thing that comes to my mind is a picture of someone herding cats or the Tower of Babel. Humans are humans and they approach things from angles as unique as they are. Some will cling to what they know, are afraid of change, are lazy, want to be in management, belief that others are simply steps to their goals, etc. Okay, I’m listing the bad qualities over the good for a reason, not because they don’t exist. I guess my point is that while, in spirit, expecting people to reach any level of enlightenment as a group is futile. Someone has to provide some guidance. Of course, a true anarchist would say I’m wrong – until their electricity goes off or there are no groceries on the shelves at the supermarket. I’m digressing onto my own soap box, I’ll stop.
Yes, corporations are notorious for looking for a silver-bullet, placating executives and management, or making statements for the warm and fuzzy of their shareholders. I can’t deny this and because of this they are deep-pocket marks for anyone who can sell that next great thing. Therefore, on the outside, any proposed magic would be naturally suspect.
So, after all of this long-winded straddling, I agree with much of what you replied. However, having watched Dean, Drew, and Colin building and marketing the Scaled Agile Framework I can tell you what I’ve observed. They do not take a silver-bullet approach and they truly are trying to build a best of breed. I can’t say I agree with everything they have put forward and I still have questions. With more understanding I’ve changed my views on some of that. However, the one thing I observed that gave me a lot of confidence was the fact that they are not putting forward a static model. In their development of the framework they are adopting the practice of listening to their users, introspection, and adaption. They are continuously making modifications to the framework and often point out that it is JUST a framework and it MUST be used in such a manner that allows groups to keep, drop, or change the pieces.
So, in closing I have found that they are not jumping on the band wagon and are truly trying to deliver a working solution. As far as setting a ‘standard’ and making profit from it, I have no problem with that. I would like to say that I get up every day and go to work for the pure joy of it, but so far in my 30 years of IT work that has rarely happened. Also, something I observed and is on a more personal note. While I don’t know this for sure, Dean Leffingwell has had a long and productive career. He doesn’t need to make SAFe a roaring success. He’s paid his dues and can gracefully bow out whenever he wants to. He truly seems passionate about this. That spoke volumes to me. BTW, I’m not their cheerleader or salesman, just an Agile practitioner
I guess my first comment would be to emphasize that the framework is not to be taken as the hammer and everything else is the nail. To take an entire corporate culture and impose upon them a single process with a single cadence would be a failure waiting to happen – and the wait wouldn’t be long. Instead, lay the framework over a single stream of business value, a single product or set of products for that business stream. Obviously, the need to impose synchronization and a steady cadence not only becomes important but crucial. I agree that imposing the same level of synchronization company wide would be more of a deterrent than a help.
Having implemented a corporate-wide Agile support system for Export Development Corp, an organization with 110 software projects in various stages of progress ranging from a few thousand dollars to $40M, and having seen this fairly conservative organization adopt Agile corporate-wide for ALL projects (not just software projects) with considerable benefit, I can say that I think any corporate Agile framework is a step in the right direction. Nobody gets everything right the first time. I’d hazard a guess the Scaled Agile Framework will iterate over time based on customer feedback. Let’s calm down, take a deep breath and, like everything else in life, try to see past obvious imperfections for the benefits and how we can accelerate and magnify the benefits over time.
Pingback: Scaling Agile & Lean - Scaled Agile Framework (SAFe) « Agile Rescue