Last week I published my monthly newsletter with the post below as the content (Not on my mailing list? You should subscribe here.) As you can imagine, it stirred up quite a few feelings. Many folks reached out in support of the post. Several folks were, well, less pleased. This makes perfect sense. If the work that someone does centers around the Scaled Agile Framework my post below, attacking this framework, can feel like a personal attack. I feel this way when someone launches an attack on Lean UX so I have a bit of experience here.
One thing I pride myself on is an open mind and a growth mindset. Every single person who sent me constructive feedback (ad hominem attacks go right in the bin) critical of my thesis I invited to share their experiences, case studies not just with me but in a public forum where they can build more goodwill towards this method. Most declined. One agreed. (Stay tuned for when and where that will take place.)
To be clear, I wouldn’t share my thoughts if I felt they weren’t based on first-hand and secondary evidence. I am clearly not the only person who feels this way. There is a clear pattern of respected practitioners, thought leaders, consultants, coaches, et al who’ve given this method a try and decided it doesn’t work for them or their clients.
My main clients are large orgs. I’d say nearly all of them are attempting to implement SAFe. Some are further along than others. All of them are struggling. I’m with them on weekly and monthly basis trying to help them figure out how to make these ideas work AND add in customer-centricity, discovery, learning and course correction. Based on what they’re being taught by their SAFe trainers/consultants they are unable to see how these ideas mix together. Frankly, I don’t have any good answers for them either since moving off the framework is heresy in most cases.
Ever since the Scaled Agile Framework (SAFe for short) adopted Lean UX in version 4.5 I’ve received a steady stream of inbound questions about how, exactly, these two methods are supposed to work well together.
The short answer is, I have no idea.
The slightly longer answer is that all the principles we’ve built into Lean UX don’t seem to exist in SAFe.
Continuous learning and improvement, customer centricity, humility, cross-functional collaboration, evidence-based decision making, experimentation, design and course correction — to name a few — are visibly absent from the SAFe conversation. Instead, organizations adopting this way of working focus on rigid team structures, strict rituals and events and an uneven distribution of behavior change requirements depending on how high up one sits in the organization.
In short, SAFe is not agile.
Given the heavy training regimen teams have to go through to become “SAFe certified” it’s no wonder they resist change. They’ve been trained to work in a very specific way — a way focused solely on predictable delivery, not learning, not course correction and certainly not agility. The activities that make teams truly agile require flexibility in planning. They require alignment on customer success, not a predetermined set of features. They require a continuous discovery process that inevitably leads to unplanned course corrections. These corrections would “derail” a Release Train in no time.
Large organizations seeking agility realize the uncertainty that comes with it and cling to the familiarity of waterfall processes. SAFe gives the illusion of “adopting agile” while allowing familiar management processes to remain intact. In a world of rapid continuous change, evolving consumer consumption patterns, geopolitical instability and exponential technological advancements this way of working is unsustainable.
If you work in a large organization that has adopted or is in the process of implementing SAFe, ask yourself what’s changed during this transition. Are you closer to your customers? How long does it take to learn whether you’ve delivered something of value? Even better, how are you measuring “value?” Ask yourself how easy it would be to pivot an initiative based on a new discovery? Then compare those answers to how things were before you started using terms like “big room planning”, “PI” and “release train engineer.”
Scaling any way of working in a large organization is tricky and uneven. Attempting to apply one blanket process to the entire company, a process that is focused strictly on delivery rather than continuous discovery and course correction, only hardens traditional ways of working. SAFe is compelling because it seems to offer a one-size-fits-all recipe for agility at scale. In reality it rewards predictability, conformity and compliance while providing executives with cover for the question, “How do we become more agile?”
What’s been your experience with SAFe? Have you been successful? I’d love to hear your story.
Hardly controversial, SAFE is really an answer for PMOs/Executives on managing their organization. It’s no different than a typical stage gate driven PMO process, just different terms and roles. It will age like milk and be replaced in a few years with something else.
I’d be interested to hear a clear arguement for a 6 sprint PI. Using the 6th sprint, partly, to plan out 3 months of work would be my number one issue with the model. Requirements and direction can change daily as we research and discover more which is a good thing. SAFe’s big up front planning and dependency management piece has its origins from RUP which was the best iterative waterfall model. I cant see it as anything other than that. I concur that it feels large organisations see it as the right stepping stone to agile, allowing them to avoid the required management reorganisation required. Our problems in both camps come from those senior management with authority who no longer fit in or have the skills to do so.
It’s self evident “SAFe is Not Agile” from the diagram.
However, IMHO, this is a symptom of the actual cause, new, non-trivial software cannot be developed in a predicable manor since by definition the solution is not known util completion.
This is understandably at odds with the business needs of predicability, but none the less this is the case since the beginning of commercial computing, and has only improved incrementally with the advent of better technology and methodologies.
IMHO, organizations must adapt to this reality to be successful.
May want to look into “capabilities-based planning” fo SW Intensive System of Systems, where “done” is defined by the needed Measures of Effectiveness and Measures of Performance for accomplishing the mission or fulfilling the business strategy, developed with SAFe and similar approaches from the system you likely use every day
– ISO 26266 automobiles
– DO-178D avionics flight safety
– OSHA 1910.119 process safety management
– 21 CFR Part 11 – medical systems
– NIST SP 800 security systems
Stick to the truth! Yay, thank you for uninterrupted integrity – it will help in the long-running (wayyy before Agile) habit of “lipstick on a pig”. Essentially, Agile/Lean UX takes risks, fails, learns, takes risks, BEFORE putting anything on a train. But, business has risk management (aversion) at the deepest levels. This is such a huge change, I’ve seen so many methods become popular that, sad but true, are there to make the risk-averse folks feel good.
I’m not sure what is so hard about spending the resources to analyze and course correct early (and lightly) other than it’s asking for trustful investment before something can be seen and demo’d.
I think that more high-level decision makers would benefit from being a farmer. Farmers know they have to literally bet the farm before the ground even thaws in the spring.
Thanks,
Paul
I have no vested interest in arguing with you or proving you wrong. I do, however, wonder if it’s SAFe that’s inflexible or the organizations who apply it. I’ve been an RTE for 4 years. I am by no means a purist. But I think you’ve got some major misconceptions. Email me any time. I have no issue with discussing it further, and openly.
I was going to write almost the exact same comment – thanks Amber 🙂
I work in a company that is large enough to allow me to witness multiple ways of applying SAFe (multiple release trains across different business units) and I can tell you they are not the same. My gut feeling tells me that 90% of the difference comes from the cultural background that the people involved in the key positions have.
Something that as an RTE I religiously repeat is “why are we doing this? what is the purpose? how can we reach the same goal with less bloat?”
example: when I took over from another RTE two years ago, the bi-weekly ART Sync meeting attended by ~20 colleagues took 3-4hrs and was dreaded by everyone who needed to attend. Today – the same ART Sync takes usually less than 60mins AND includes a short demo of the system to stakeholders. In both scenarios SAFe is applied…. I’m happy to share more thoughts and experiences as openly as it can get 🙂
I totally agree with you, Amber. He lost me with this comment “Continuous learning and improvement, customer centricity, humility, cross-functional collaboration, evidence-based decision making, experimentation, design and course correction — to name a few — are visibly absent from the SAFe conversation.”
This tells me he clearly knows nothing about SAFe or is not having a conversation about SAFe because SAFe exemplifies all those things (not sure how he missed it).
I do agree that larger organizations like to pretend they are implementing SAFe, when the truth is, they are only putting lipstick on a pig; not changing much except maybe adding some PI planning and calling it SAFe. Sadly, all too often, SPCs allow them to get away with it – so, they do not reap the rewards of SAFe and people think SAFe doesn’t work…
I am an SPC and I experienced this unwillingness to change from upper management in a major corporation – after head-butting with the management team who said they wanted to implement SAFe (they had all sorts of pretty posters advertising as much too…) for over a year, I gave up and said to call me when they finally reached the tipping point and were ready to seriously implement the change.
LEADERSHIP is ALWAYS going to be the problem/the roadblock to a successful SAFe implementation.
Yes, Michelle for the win! Thank you for so eloquently expressing what many of us feel, I appreciate your thoughts on this, I am with you all the way!
Can you elaborate what you experienced different?
Release train by itself is a nonsensical and redundant concept in the world of agility and things that promote it – microservices, CI/CD, autonomous cross functional teams. Dependencies are removed by decoupling, not managed
I agree with you, but I consider this, as one the best shots an organization have to maintain certain formality with some agile practices and frameworks incorporated like scrum.
My personal point of view is that there are new barriers that are truly difficult to defeat when scaling:
– Dependencies and Risks
– Value Chain/Streams
– Politics
– Heterogeneous environments
– Time Zones
– Alignment
– Communication
– Tooling
All of these are less present when you’re talking of one, two or three teams.
But when you’re talking of more than 40 or 50 teams things emerge and gets truly complicated.
But!! Do you nessasarely need 40-50 teams. More with less I always say!!
SAFE, is an attempt by organization to bring management control into agile. Agile by nature has very limited management involvement , agile teams has a very flat distributed non managerial structure. Large organizations adopt SAFE as a means to bring structures in agile, so no SAFE is no agile but a waterfall reincarnation:
Jeff – I’m not a fan or practitioner of SAFe for the reasons you outline above. Ultimately, I feel SAFe is a coverup for being Waterfall. It is not agile! However, I do find massive benefits in some form of all-hands planning for exactly the reasons you point out as benefits of lean UX/agile: customer-centricity, discovery, learning, and course correction, and I feel it adds two more components that help execs let go so teams can be autonomous — transparency and collaboration. It helps us to focus on the initiatives that drive the most value for the customer and in turn the business, as opposed to being siloed by a particular product or a particular team. In the absence of all-hands planning, large orgs fall prey to becoming feature factories.
We practice dual-track agile using mostly scrum and some kanban, and we leverage design thinking and lean methodologies at the moment they drive the most value. Our public roadmap is thematic, with initiatives that drive customer outcomes, aligned to long-term and near-term OKRs. Our internal four-month delivery plan is an output of all-hands planning, leveraging the somewhat new “Remote: Agility Framework” (r:af). The plan is always a mix of delivery and discovery. When you have more than a couple of teams (in our case 12 scrum teams), all-hands planning is a lifesaver. It gets cross-functional teams and stakeholders talking to each other, sharing insights, and fostering healthy debate, which empowers them to solve problems —together, and results in buy-in from everyone else.
What I see most often is that teams need more training and help with discovery. So I say skip the agile framework training and arm the teams with discovery tools and education. A lot of teams stop the discovery loop after they gather a bit of qualitative voice-of-customer and do some light sketching. They tend to skip the hypotheses, risk assessment and experimentation. Also, most teams think about discovery as validation of the work they are already planning to deliver. Doh! Arriving at “invalid” is equally important. Everyone could do themselves a favor by taking a more scientific approach to discovery instead of being offended that an idea is invalid or low value. Let’s focus on discovery maturity.
Dear Jeff,
You will probably not remember me, but we have met in a couple of conferences, where I was lucky enough to interview you for a magazine I collaborate with. In fact, you were kind enough to do to a proof reading of my book ‘The Lean Playbook’.
That aside, I find your article quite true. SAFe is not about agile. SAFe is about organizational adaptability, consistent structure and coordination & alignment between multiple teams. That alone proves to be a huge value added reason for many large companies to adopt it. However, and I can tell you based on experience, as we have been implementing SAFe for years in the company I work for, that SAFe, although rigid in its processes, provides means for innovation, testing, learning and adjusting. It just puts tighter controls or guardrails around them so we do not lose track of the strategic objectives to accomplish.
I think it’s important to remember that this is meant for large organizations. Small to medium ones should really avoid SAFe, as they don’t suffer from the bureaucracy and complexity of the larger ones and they should be designed for speed. But an elephant (a large organization) will never be gazelle; let’s not fool ourselves. However, at least they can partner with gazelles (startups and small ventures) to have the best of the 2 worlds: robustness and strength combined with real agility and speed.
Amazon does a good job of being nimble. Businesses that refuse to be nimble (it’s a choice) must to hope and pray that amazon does not compete with them.
Interesting perspective. Having joined a company 18 months ago using SAFe I can see some of the point of view. I still question agility when you are fixing work for the next time period (PI). I see lots area where SAFe is trying to offer support and guidance and I see lots of area where it falls over. But is this just he fault of the execution. Failure to effectively manage a backlog of work that can be executed does not help, lack of assessment of execution, retrospective will not help you to continuously learn and adapt.
For me like many things SAFe is a framework, it even includes this in the name. As such I take this as a guide that you can adapt to your own business needs. The same with any other methodologies. Just hitting the key markers and getting everyone to give you a thumbs up is not going to get you anywhere.
Whatever methodologies or frameworks you use there are some key practises you need to include, as Jeff has included in this article. Key to this, as with most things these days, is the people (employees & customers). Making sure they are involved in supporting these processes as well as guiding them.
I am coming from an agile at scale organization, which adopted some principles of SAFe and created its own format, culture, rituals with some of its components.
These days, I am working in a Full SAFe setup, and the major flaw in the “system of SAFe” is the “process optimization” it applies to scaled agile, so breaking everything down to a plan and an organizational structure.
If you already have to mindset to adapt, to “go and see”, to change stuff in a sustainable, customer centric manner, I think SAFe does not harm.
What I am still searching, is a industry example, where a company adopted SAFe and became successful afterwards based on a product coming through the funnel.
Thank you for sharing. It is an interesting perspective. From my reading, rather than arguing the point that ‘Safe is not agile’, you are really articulating that organisational change is difficult and complex. There are no ‘one size fits all’ solution that makes change easy.
If you were to compare Scrum with Kanban, you could easily argue that Scrum is not at all agile in comparison to Kanban because Scrum is quite formal, process, ceremony and role based. While change is welcomed, there is strict timeboxing (sprint) and fixed scope within that timebox that discourages change. Kanban in comparison is extremely light on process, has few roles, does not timebox and change can happen on an hourly basis if you wish, as opposed to outside sprints only.
That said, would I recommend that a traditional, process dependent organisation transform from Waterfall to Kanban in one jump because Kanban is the most agile of the methodologies? absolutely not. Simply because the change required at a systemic and people level, would be so great that only an already nimble organisation like a start-up could implement that level of change successfully in one jump.
Your point is valid, but it is the context that I would question. If the organisation and its people are already nimble, there are many more suitable approaches to scaling agile like LESS, Scrum of Scrums or build out your own with Lean Change Management. But if you have a more traditional, matrixed, process dependent organisation who does not have a history of implementing significant organisational wide process transformations and people transitions, then a step-by-step approach is likely to be more successful in the context of organisational change.
The concept of Shu Ha Ri always comes to mind for me when I consider an organisational transformation.
Shu – First we must master the basics of our craft. Scrum for teams and Safe for scaling. Simple, easy to follow and possible to master. Remember at this point we are likely still constrained by monolithic architectures, limited release capabilities, manual testing, lack of understanding organisation wide what agile brings and what problems it solves.
Ha – We are mastering of Scrum and Safe and thus growing our agile mind-set organisation wide. We understand what agile can do for us individually and organisationally. This knowledge is allowing us to adopt our approach. Some teams or business groups will start modifying their processes to suit their more agile needs. Still true to agile but their mastery is allowing them to adapt the processes to suit their specific needs. Adding Lean concepts, design thinking, more agile delivery approaches, CI/CD. Modular architecture.
Ri – You no longer follow an industry standard agile approach. You now have your own customised approach to delivering maximum value via a sustainable approach. You are delivering more for less. You understand your customer, what value is, and you can connect the value back directly to the balance sheet. Your only guardrails are agile, lean, design thinking principles and the vision of the organisation.
Agility, like all change is a journey. It starts with understanding why change is needed, then what is our current reality, then what needs to change, committing to the change, tackling obstacles to that change and finally measuring our success.
I completely agree w/Ray Kinsella’s comments (above). Taking a large organization and it’s staff – folks who have been working in a highly matrixed, hierarchical organization – and asking them to pivot towards a lean, self-empowered, autonomous, agile org-structure is not without challenges. The saying ‘culture eats strategy for breakfast’ truly applies in this situation!
A transformation of this nature truly requires the change-agents to be supported by the business and to utilize that support to initially establish predictability. IMHO, a Release Trains ability to deliver in a predictable manner (on cadence) – fortifies trust with business stakeholders. That trust enables teams within the Train to create more opportunities to: review, measure, experiment, make mistakes and by extension learn and evolve. It really is, as Ray notes, a stepwise progression towards what we hope becomes a better organization made up of great people, that build and deliver awesome products, with the utmost quality!
My take on SAFe in a nutshell: of all the possible transportation metaphors available, a framework that uses “trains” – the least nimble of ALL transports – is probably not Agile/agile.
I think people who use SAFe often interpret articles like this as SAFe is bad or SAFe does not work, which is not what the article is saying (Note the title-> SAFe is not Agile). SAFe is one way to effectively delivery software, it’s just not Agile. There are so many people who don’t understand Agile and Scrum and they just blindly do what everyone else is doing. There is also a misconception that if I have a lot of development teams, I need a scaling framework. Scaling frameworks are meant to be leveraged by teams supporting the same product, not an organization with a lot of dev teams. If you have 20, 30, 40 teams supporting the same product, you’ll never truly be Agile, and that’s ok.
I trully agree with that. And in the end I don’t think it is important if you are Agile or not but if you are delivering value for your customers and your company. If a framework can help you do that, then go for it.
Most C-levels are result-oriented people. More often than not how you get there is secondary -within limits (ends certainly do not justify all means). Whether you get there by meditating, rain dancing, SAFe or LeSS doesn´t really matter. All that matters is “does it work?” How many companies, that tried SAFe went back to their old ways? Some, but i guess not the majority. The same could be said about LeSS Huge or Enterprise Kanban. The point isn´t that “frameworks, methods etc” are actually “good” or put you in an ideal state. The point is: is it better than before? is better than 1 month ago, 1 year, 1 decade. Are there even better ways? maybe. you will never know without trying.
I have years of experience with what became LeSS Huge and several attempts at SAFe in different companies. None makes your pains go away, but most(never all!) people agreed it is better than before. Seems to go in the right direction. 8 out 10 won´t go back. So far i haven´t experienced anything better to get close to “Learning Organisation” at large enterprise scale. It may exist, i just haven´t met it. And: Agile has no brain, use your own.
I certainly agree that the way in which SAFe is implemented is not agile and will concede that SAFe is rigid compared to other scaled agile methodologies but I disagree that SAFe is not agile.
The problem, as I see it, with SAFe is in how it is implemented. It it is supposed to be a framework, a tool kit, but practitioners are dogmatic about its structure. While companies are investigating heavily in the window dressing of SAFe, they are ignoring the less sexy fundamental practices; integrated teams, prioritizing based on capacity, acceptance criteria, Wip limits, and the validation of outcomes.
SAFe is a gateway to agility, but we must all recognize that simply copying the structure is not enough.
There is a big difference between the outcomes seen in the way organizations choose to warp it to avoid changing existing power and control structures, and the design centers of SAFe.
If you actually read about it and go through the trainings, you will discover that it actually does teach, in black and white, most of the things that detractors say it does not in the original post and comments above.
Before jumping to conclusions about my intentions, please understand that I am not defending one framework or another, and instead trying to illustrate that none of them are, in my view, the cause of the problems noted, nor a path to solution.
Whether the approach is effective in generating change, whether organizations understand or have the motivation to change, whether the existing organizational systems have feedback systems that will defeat the approaches that almost all agilists use, whether agilists tend to avoid doing the hard work required to challenge beliefs effectively and enable the required change factors at the appropriate organizational levels , rather than running from the opposition – these are separate issues.
Most transformations, agile or not, fail. Whether this is the result of the frameworks or other underlying factors – not so clear.
The argument that “because transformation x failed, the end-goal was invalid” seems difficult to rationalize to me.
It’s these other non- framework things that the community seems driven to not address, and I wonder what the cause of that is on a regular basis .
By the measure of “What works in generating change,” it seems that an objective review of evidence would say that all agile techniques and frameworks have very limited proof of successful outcomes, regardless of which one you inspect. I mean real change, not the “we stood up x agile teams” or “look at how many points we compete” vanity measures theater.
Perhaps someday a real discussion will evolve out of these noise-filled “my framework is better than your framework” arguments. That would be refreshing.
I feel like SAFE was gaslighting me with their Lean UX stuff and only now do I feel sane again thanks for this,
From a developer perspective, as it was said, for big companies usually the adoption of SAFe brings the impression of changing in a better way, but not for the dev teams. For the managers it is nice to have a release every 3 months, but for developers it means a commitment to a 3-months plan.
When it comes to start adopting SAFe, several teams already run some kind of Agile individually. In most cases Scrum. They are used to respond fast to changes and unplanned demands, and they are trained to not make strict commitments to more than 2 Sprints. At the moment SAFe comes the teams need to move to a waterfall in iterations and deal with longer commitments. In order to not suffer during the PI they need to spend more time with refinement before they PI planning instead of creating value, while the comprehensive documentation is no longer there to support. Yes, I don’t know why but it’s a pattern I have noticed. The teams need to have all those changes in the way of work and still keep running Scrum, but the concept of Sprint no longer makes sense in this context. The actual goal is set for the end of the PI, the Sprints are now just a break down to achieve the PI commitment. Sprint goals become void and artificial. Besides that Scrum considers only completely finished stories to report in the end of Sprint. This privileges picking up small, low-priority items or switching the context to another ongoing feature instead of continuing with that very important feature.
I heard once that SAFe is well sold because it represents a change that the managers and C-levels can handle, considering their PMBOK mentality. It is still valid to bring some agile aspects, especially driving managers to bring the business to the devs. It is a step forward for the manager but a step backward for the developer.
There’s been a lot of comments stating that it’s not SAFe that is not Agile but how companies interpret and implement SAFe in a nonAgile way and I agree with all of them.
Would love to hear your thoughts on my article and how we implemented SAFe: https://strefapmi.pl/strefa-praktyki/safe-done-properly/
My email is available and you can find me on LinkedIn
It seems pretty easy to throw stones at SAFE and say it is not agile. I think it’s (at least sometimes) cart before horse to say that SAFE is management attempting to control Agile.
As an organisation scales, how *are* we supposed to run 20, 40 or more teams, working on a programme that requires a degree of dependency and coordination between them (i.e. they are contributing to the same product, platform, service, whatever)? Each team cannot be purely self-directed and pivoting on a dime, as other teams are relying on them to deliver things their plans are depending on. Not everything can be done immediately, so things get queued waiting for a dependency to be fulfilled. even the learnings often span multiple teams, or can only be realised once multiple teams have delivered their contributions to the feature. This all seems to require a level of coordination and forward planning that is beyond Agile.
So rather than just say “this doesn’t work”, what is the better alternative for organisations of a scale where the Agile manifesto just doesn’t cover, that is not waterfall or top down management with shiny lipstick?
A completely related topic, watch “SAFe on Trial” to see SAFe in a virtual courtroom on whether it is Agile or not Agile!
https://agiledmv.org/safe-on-trial-is-it-really-agile/
Couldn’t agree more. I am also one of the “experts” that came out of few years ago to say as much: https://agileforest.com/2018/06/24/why-safe-is-not-the-scaled-agile-approach-you-need/
As for the argument “its not the methodology, its the implementation”, I have seen “SAFe experts” actively creating divides between IT and the Business and saying it is okay if SAFe is just used in IT. This is just wrong, it isn’t the organization that is failing -it is the expert implementors. If they can’t get it right then there is something fundamentally wrong with how SAFe trains, grows and endorses its experts.
Scaling agile in a corporate environment is difficult and challenging. For me it is about remembering what we are trying to achieve and at the heart of this is the ability to release working software in small incremental chunks that is aligned to business value.
SAFe is not all bad – but its definitely also not all good! For me companies need to look at their operation, look at the various frameworks and then from the POV of knowledge build a framework that meets their unique and individual needs. Routed in the principles of continuous improvement.
At Boots we are definitely not an Agile organisation; but we are also now not a waterfall organisation – we are incrementally changing the way to operate and the way we build software exploring what has worked for other companies and then internally reflecting to see how that is applicable in our own context.
We do use elements of SAFe, we also use Lean principles, and have also taken useful learnings from Large Scale Scrum, Disciplined Agile, Enterprise Kanban and Scrum@Scale. One size does not fit all – for me this is about having a continuous learning / improvement mindset and accepting that their are many roads that will hopefully lead to agility.
SAFe works within narrow contexts. If it’s not working for you, go further back towards first principles, i.e. start from the client’s and your perceived major risks (not BAU) and develop controls to mitigate these risks. Place these controls along a timeline and develop KRAs and KPIs that show controls are in place. Place gateways along the timeline to indicate when a review process will take place and then proceed with development.
Many of the controls you need will have been developed previously and can be used again, so here you have both an agile and waterfall process.
What’s wrong in combining agile practices with some good long term planning? That’s all SaFe is to me.
Agile is great … being agile and doing Agile … the simplicity of Snowbird … Scrum, Kanban, Lean, Less, CI/CD … find the recipe that works for you and just do it. But if you have multiple teams working together on complex applications over a quarter or longer … SAFe will help you … get it done while staying agile. I’ve seen it work. SAFe and Agile are by no means mutually exclusive. And SAFe can be as simple or complex as you wish.
I am CSM and SA certified with 8 years as an Agilist and 34 years before that as a programmer/developer.
I’m happy to discuss, contrast, and debate frameworks juxtaposed with SAFe, as would any practitioner interested in helping organizations grow in Agility…the ability to learn, change, grow, and lead. I’ve argued the case for everything from W. Edwards Deming’s System of Profound Knowledge and 14 Points, Goldratt’s Theory of Constraints, Jack Stack’s Great Game of Business, Meg Wheatley’s Leadership and the New Science, among many others over the years, but what seems to be lost here–the gross misrepresentation of SAFe notwithstanding–is one central and simple reality: SAFe isn’t trying, and doesn’t pretend, to be just Agile. While the Framework certainly includes Agile, it is so much more. And like my experience with companies endeavoring to implement any of the other ideas, methods, models, or theories above, I can’t help but conclude that the reason for any failure here can be attributed to what Dr.’s J. Clayton Lafferty and Rob Cooke at Human Synergistics International would refer to as the Leadership-Culture-Performance Connection. And this failure of leadership should be addressed first, or the problem of organizational rigidity won’t go away…no matter how robust a Framework you throw at it.
“Continuous learning and improvement, customer centricity, humility, cross-functional collaboration, evidence-based decision making, experimentation, design and course correction — to name a few — are visibly absent from the SAFe conversation”
Is that right ? Here are a few references that suggest otherwise.
continuous learning
https://www.scaledagileframework.com/continuous-learning-culture/
relentless improvement
https://www.scaledagileframework.com/lean-agile-mindset/
customer centricity
https://www.scaledagileframework.com/customer-centricity/
collaboration
https://www.scaledagileframework.com/scrumxp/
https://www.scaledagileframework.com/pi-planning/
experimentation
https://www.scaledagileframework.com/build-incrementally-with-fast-integrated-learning-cycles/
https://www.scaledagileframework.com/continuous-exploration/
design
https://www.scaledagileframework.com/design-thinking/
What a lot of horse shit Jeff, SAFe is about Business Agility – that means more than Scrum or Team Based Agile. Pretty scary given your position and there is more Lean UX, Desing, Product and Solution, Exploration, Experimentation and Customer Seat at the Table. CX, centricity in SAFe than any other Off the Shelf Option.
Suggest you revisit and re-read with a more open mind or change the SPCs and Trainers your using.
Core Principle:
https://www.scaledagileframework.com/assume-variability-preserve-options/
Design Thinking:
https://www.scaledagileframework.com/design-thinking/
Customer Centricity:
https://www.scaledagileframework.com/customer-centricity
Experimentation:
https://www.scaledagileframework.com/build-incrementally-with-fast-integrated-learning-cycles/
https://www.scaledagileframework.com/continuous-exploration/
Product Management:
https://www.scaledagileframework.com/product-management/
Continuous Learning:
https://www.scaledagileframework.com/continuous-learning-culture/
Relentless Improvement:
https://www.scaledagileframework.com/lean-agile-mindset/
Collaboration:
https://www.scaledagileframework.com/scrumxp/
https://www.scaledagileframework.com/pi-planning/
I know these elements are included in the diagrams and training. How much of this actually gets implemented? Where has this happened? My experience tells me that the majority of this gets ignored when SAFe is implemented.
The problem with SAFe and its implementations is that the resulting change is usually a change in the way of working (terminology, ceremonies..) instead of changing in culture, top mng. egos and mindsets. Also terminologies and entire framework is pretty hard to grasp so usual implementation of SAFe is that IT part of organisation now uses new terms and way of working, rest of the company stays same. Maybe CTO/CIO and his B-1 level changed too but rest of the org is not much on board.
BUT IMHO it is not entirely fault of SAFe but rather that too much attention is put into changing processes and structure rather than heads of top and senior mng. Obviously this is supported by SAFe business model as money comes from certifications that tests terminology and definitions knowledge. And change leaders are in illusion that if you change org chart and how you work you become agile enterprise.