This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Scaled Agile Facts

Scaled Agile Facts is a curated review of facts, evidence, and opinions from relevant sources without vested interests, to help decision-makers considering the SAFe make informed choices and get better results.

1 - Introduction

Now that Agile passed the early adopter stage, there are many companies interested in adopting it, and many practitioners interested in learning it. Yet those companies and practitioners without extensive Agile experience have a hard time evaluating what will bring them value and what not.

Many of the larger companies and novice practitioners look at the marketing from SAFe, and they don’t know if they can trust it or not.

On this site members of the Agile community are collecting available information including on these marketing stories.

Some practitioners have been there and know the difference between marketing and real stories, others know not only how things started yet also how things are going now.

The information collected here is to help decision-makers and novice practitioners make an informed decision.

This site is a mirror of the content available here: https://bit.ly/SAFe4DecisionMakers.
If you like it, re-share it.

2 - Contributors

This content is a collective effort with multiple contributions, mainly from the Agile community. The list is long.

They are the experts and the practitioners mentioned below whose posts and articles have been linked in Sources, the many readers that suggested several improvements, those who worked on the case studies, and the facilitators of this effort, Luca Minudel and Yves Hanoulle.

They all have spent hours, days, weeks, and even months codifying, debating, verifying and generously sharing their findings. With the shared purpose of improving the state of affairs for everyone.

3 - Contribution Guidelines

This is an open-source project where we share valuable knowledge with decision-makers from organisations that are considering the adoption of SAFe, and with novice Agile practitioners considering investing in it.

With the purpose of supporting them in making an informed choice. These are the guidelines for contributors to this project:

  • You can add anytime to fix spelling mistakes;
  • Please do not remove others’ contributions;
  • Except if people misquoted you, in which case you correct;
  • If you quote someone, please inform them, to check if they still agree with the quote;
  • Feel free to fork this GitHub repo and open Pull Requests to add your contributions.

4 - Case Studies

So far all the SAFe case studies that allow for some form of verification or third-party observations all show that SAFe does not make the organisation more agile, it worsened the shortcomings that are typical of the pre-Agile approaches, and overall makes things worse.

It is also known that SAFe isn’t used by any leading software commercial organisations such as Facebook, Google, Netflix, Microsoft, and the like.

This overall picture is congruent with the growing number of anecdotal evidence emerging from Sr leaders and employees sharing stories about their previous companies where SAFe was adopted.

4.1 - U.S. Air Force

In December 2019, Nicolas M. Chaillan then Chief Software Officer at the U.S. Air Force, issued a memorandum as part of the DoD Enterprise DevSecOps Initiative.

The memorandum concluded by strongly discouraging the use of rigid, prescriptive frameworks such as SAFe.

In a highly publicised move, Scaled Agile Inc offered free consulting to address the concerns from the memorandum. Later the USAF CSO confirmed the conclusions from the memorandum were still standing, and SAFe was still strongly discouraged and will not be used in any form in their DevSecOps Initiative.

References:

4.2 - ThoughtWorks

ThoughtWorks is a global technology company that has pioneered Lean and Agile. After observing, between 2015 and 2021, several clients that had adopted SAFe, ThoughtWorks advised against adopting SAFe.

These are some of the things they observed from the clients that had adopted SAFe: SAFe created friction in the organisational structure and its operating model, promoted silos, hindered tech from creating business capabilities, generated waste in the value stream and discouraged creativity, it limited autonomy and experimentation.

References:

4.3 - BlueDolphin

BlueDolphin consultant Wolfram Müller together with a hub of other consultants including Steve Tendon has worked in recent years helping several organisations to deal with issues after they adopted SAFe.

They recently analysed the performance of teams from a company department of 200 software developers that have been working with Essential SAFe for 1.5 years. The result highlights the same problems typical of the traditional pre-Agile approaches.

There are no signs that Essential SAFe helped them increase their agility and improve.

References:

4.4 - Volvo Cars

Volvo Cars was founded in 1927. It is headquartered in Gothenburg, Sweden. It has around 40,000 employees and produces around 700,000 cars per year. In software development, it employs about 10,000 people with about 150 million lines of code per car. Nowadays cars are steadily becoming “computers on wheels”.

Between 2017 and the end of 2019 Volvo Cars went through a 2 years and a half Agile transformation phase to scale Agile with SAFe.

In a 2020 interview with the Head of Continuous Improvement & Change at Product Creation, there is evidence of a lack of focus on technical excellence as instead suggested by the Agile principles. The interview also reveals a focus on processes and a hierarchical top-down approach, but no focus on the Agile mindset.

Two academic case studies by the Chalmers University Of Technology also confirm the lack of focus on the Agile mindset and the lack of alignment with Lean and Agile principles, a hierarchical approach with an org-chart made deeper by additional levels. One of the papers also notes the inflexibility of SAFe and its disadvantages.

Three years later, Volvo Cars is still using SAFe in several parts of the organisation. In September 2022, an internal source confirmed that a whole department in Volvo dropped SAFe after it became obvious to them it wasn’t adding value. Since then the teams were functioning in a fairly Agile way in spite of the SAFe limitations: the PI planning was becoming mostly for show and the real organisation of the work and the collaboration was happening much more fluidly; the program board was adding very little value in the face of the significant effort spent for it.

This change involved 11 teams and just over 100 people including Product Owners, Software Developers, UX designers, graphic designers, subject matter experts, etc. They wanted to honour how the teams want to continuously plan and not just how they want to work, empowering teams to apply pressure upwards through the organisation in order to continuously improve.

References:

4.5 - ANZ Bank

ANZ, Australia and New Zealand Banking Group Limited is an Australian multinational banking and financial services company headquartered in Melbourne, Victoria.

In 2017, CEO Shayne Elliott wanted to reshape the bank’s staid culture to give ANZ customers more and faster by introducing Agile. Shayne Elliott was taking inspiration from what technology companies from Amazon to Microsoft did and what some banks such as ING and ABN Amro had been doing although with mixed results.

To do that Shayne Elliott focused on processes by rolling out SAFe across its Australian division, and on tools: by an enterprise agreement with Atlassian for the use of Jira and Confluence.

Five years later the bank’s home loan approval systems have become one of the slowest in Australia, and as a result, ANZ lost a substantial share of the $2 trillion mortgage market, its share price is down 17 per cent since Elliott became CEO seven years ago. And its technology systems lag behind its biggest competitors.

Martin North, the founder of DFA Analytics, says “I don’t rate ANZ as an agile organisation. In fact, I would say that they’re quite sluggish in terms of some of the things that they’re doing.”

References:

4.6 - FitBit

Fitbit is one of the success stories promoted by Scaled Agile Inc.

Fitbit Inc. is an American company founded in 2007 with its headquarters in San Francisco. It now has about 15 offices around the world. In 2019 Fitbit was reported to have sold more than 100 million devices and have 28 million users. Between 2015 and 2016 FitBit adopted SAFe.

Damian Brown, Sr. Director of Program Management Office, describes the success of SAFe citing criteria, such as processes and teams’ Velocity, that are irrelevant for Agile teams and show a lack of paradigm shift or an Agile mindset. He continues commenting on the company’s growth and the commercial success of the new products released. But the financial data, reports from financial analysts and other publicly available data contradict that.

A person working at FitBit confirmed the lack of autonomy of the teams. And added that later FitBit had abandoned SAFe, and the person that had persuaded the company to try it had left the company as well. The FitBit case study is still listed on the SAFe website as a success story. This story seems far from being a success.

References:

4.7 - Conclusions

So far all the SAFe case studies that allow for some form of verification or third-party observations all show that SAFe does not make the organisation more agile, it worsened the shortcomings that are typical of the pre-Agile approaches, and overall makes things worse.

It is also known that SAFe isn’t used by any leading software commercial organisations such as Facebook, Google, Netflix, Microsoft, and the like.

This overall picture is congruent with the growing number of anecdotal evidence emerging from Sr leaders and employees sharing stories about their previous companies where SAFe was adopted.

5 - SAFe Experts' Opinions

A small significant sample of former SAFe experts, some instrumental in shaping SAFe.

5.1 - Al Shalloway

Al Shalloway has been one of the three initial SAFe Principal Contributors for six years, the first SAFe program consultant trainer (SPCT) outside Scaled Agile Inc, and with his company, he has been a SAFe Gold partner.

In 2018 he broke off his relationship with Scaled Agile Inc and SAFe, citing among the reasons that SAFe has grown considerably more complex than it needs to be, and that he was told had to prove he had done a few “by the book” SAFe adoptions to renew his SPCT certification.

In 2020 he further commented that he thinks it’s more appropriate to call SAFe an improved Waterfall than it is to call it a poor Agile. That creating ARTs (Release Trains) merely accommodates dependencies and is a poor value creation structure. And that a 3-month PI (Product Increments planning) is better than annual but is not Agile.

Al Shalloway has also made some positive comments about some elements of SAFe. He said that SAFe can provide a good start for organizations that can’t deliver quickly or are even stuck, and that it provides:

  • a holistic view
  • an introduction to first principles
  • a cost-effective method of training teams
  • a way of providing alignment across the organization.

He added that the challenge for most organizations is that SAFe provides just enough to get started, not enough to finish the job of continually being able to improve. Most SAFe adoptions start with Essential SAFe and never move to the higher levels because of SAFe’s complexity. Many others stagnate after 2-3 program increments because they revert to a push system.

References:

5.2 - Alex Yakyma

Alex Yakyma has been SAFe first Associate Methodologist. Between 2012 and 2016 he worked for Scaled Agile Inc and SAFe Fellow. Since 2017 when he distanced himself from SAFe and Scaled Agile inc.

After that he focused completely on the human aspects of work, focusing on the Agile mindset, organisational culture and learning. And commented: “The solution to the problem is not in practices, methods or tools. They are helpful but only when the mindset is evolving too. The real solution lies in educating the industry in the new ways of thinking and making it applicable in the organisational context.”

References:

5.3 - Bob Galen

Bob Galen became SAFe SPC certified around 2013. He tried to understand, support, and apply it, but then he struggled with it for a long time to the point that he just couldn’t be associated with it any longer.

In his farewell to SAFe he mentioned several reasons, here are a few: It’s too big; It creates far too many roles, layers, flows, etc; It’s too focused on certifications and training; It’s created lazy organisations who think the framework does the heavy lifting for them; It’s created a community of SPC’s and other consultants who look at every problem and thinks SAFe is the solution.

References:

5.4 - Conclusions

This is a small sample of a growing group of SAFe experts that are distancing themselves from SAFe with motivations that are congruent with the problems observed in the case studies and by other experts and practitioners.

6 - Comments from the authors of some practices assimilated by SAFe

A small significant sample of former SAFe experts, some instrumental in shaping SAFe.

6.1 - Jeff Gothelf

co-creator of Lean UX

Jeff Gothelf is the co-creator and co-author of Lean UX. He has direct experience with SAFe and indirect experience with several clients.

Commenting on how SAFe and Lean UX works together he says “all the principles we’ve built into Lean UX don’t seem to exist in SAFe.”

Based on what his clients are being taught by their SAFe trainers/consultants they are unable to see how SAFe and Lean UX can mix together. Neither does he have any good answers for them, since deviating from the framework is considered heresy in most cases.

References:

6.2 - Dave Farley

Dave Farley is a pioneer of Continuous Delivery, an expert in DevOps, and co-author of the first and most relevant book on Continuous Delivery.

After working with several clients that have adopted it, he noted that SAFe Release Trains practice is anti-Continuous Integration where Continuous Integration is a fundamental technical practice of Agile that Continuous Delivery is built on. That means that Release Trains in SAFe are anti-Continuous Delivery.

References:

6.3 - Ken Schwaber and Jeff Sutherland

co-creators of Scrum

Ken Schwaber and Jeff Sutherland are two of the creators of the Scrum, and co-authors of The Scrum Guide. They are also part of the group of authors of the Agile Manifesto.

They both criticise SAFe, as detailed later in the document.

Jeff Sutherland in particular says that SAFe is inconsistent with the Scrum guide and codifies dysfunctions that can cripple teams for years.

Ken Schwaber says that there is a fundamental philosophical schism between Scrum and SAFe because Scrum controls risk through empiricism while SAFe tries to control risk through predictability.

References:

6.4 - Conclusions

This is a small sample of authors of original practices that have been integrated into SAFe, who say the integration of their practices is fundamentally flawed.

A larger number of experts share similar comments about other practices that have been integrated into SAFe.

7 - Agile Experts' Opinions

7.1 - Ron Jeffries

co-author of the Agile Manifesto

Ron Jeffries published on his personal website a very constructive, detailed long list of criticisms about SAFe. His criticisms have fallen on deaf ears, and instead, the latest versions of SAFe have even worsened the problems.

References:

7.2 - Andy Hunt

co-author of the Agile Manifesto

Andy Hunt states that SAFe is not an Agile approach. He also mentioned professionals that made a career fixing severe problems caused by failed SAFe adoptions.

References:

7.3 - Martin Fowler

co-author of the Agile Manifesto

Martin Fowler is also Chief Scientist in ThoughtWorks, so you can imagine that the view of ThoughtWorks on SAFe, also documented here, is congruent with his view.

During a panel at the GOTO conference, he made very clear his dislike for SAFe.

References:

7.4 - Alistair Cockburn

co-author of the Agile Manifesto

Alistair Cockburn suggested that the money and time spent on installing SAFe could produce much better results when spent instead on improving collaboration and delivery that in turn would move the company’s attitude and behaviour some distance.

He added at that point that he stopped defending SAFe because he thinks there is a better way to spend the money.

References:

7.5 - Brian Marick

co-author of the Agile Manifesto

Brian Marick described SAFe nature as problematic and prescriptive due to the set of rules to follow, with a fret to enforce them. And he also described SAFe processes as overly-codified to the point that they actively work against the collective creation of tacit knowledge.

References:

7.6 - Ken Schwaber and Jeff Sutherland

co-authors of the Agile Manifesto

Ken Schwaber and Jeff Sutherland are part of the group of authors of the Agile Manifesto and two of the creators of Scrum.

As mentioned before they both criticise SAFe.

Ken Schwaber equates SAFe to RUP, an abandoned heavyweight methodology. He comments further saying that a core premise of Agile is that the people doing the work are the people who can best figure out how to do it. And that the job of management is to do anything to help them do so, not suffocate them with SAFe.

Jeff Sutherland says that he finds scaling frameworks like SAFe overly prescriptive and limited in their efficacy.

References:

7.7 - Mike Beedle

co-author of the Agile Manifesto

Mike Beedle was an American theoretical physicist turned software engineer, and he was the author of the first book and earliest papers about Scrum. He was also a co-author and a signatory of the Agile Manifesto.

He debated that SAFe is not Agile, and he added that there are many other better alternatives. He articulated how SAFe in particular and the Agile Train Releases concept, violate all the values in the Agile Manifesto.

References:

8 - Other Experts' Opinion

8.1 - Chris Matt

Chris Matts is an experienced Agile practitioner specialising in delivering trading and risk management systems in investment banks. He contributed to BDD with Daniel Terhorst-North, he developed Feature Injection practice and with Olav Maassen he introduced the concept of Real Options in Agile.

Chris highlights that the creators of SAFe have not engaged with the wider Agile community in the usual debate that challenges the new practices in a process that validates and improves them, and ultimately gives (or not) credibility. Chris adds that he is not aware of a single leader in the Agile Community that has endorsed SAFe.

As an example of the flaws of SAFe he mentions the definition of Epics in SAFe. And he also challenges the idea that SAFe could be a stepping stone to good Agile.

References:

8.2 - Marty Cagan

Marty Cagan is a Silicon Valley-based product executive with more than 20 years of experience with industry leaders including eBay, AOL, Netscape Communications and Hewlett-Packard.

Based on all Marty Cagan has read and heard, he says he would not want to work in a company using SAFe. He can’t either imagine any of the strong tech product companies he knows choosing to move to SAFe, and if for some reason they did, he’d be pretty certain their top talent would leave.

He believes that with SAFe the core benefits of Agile and Lean are lost. And he found in SAFe all ten key attributes of Waterfall and project mindset that are the most common root causes of product failure in product companies.

References:

8.3 - Mary Poppendieck

Mary Poppendieck, with her husband Tom Poppendieck, is the co-author of the book Lean Software Development, a seminal book for the Agile community.

She agrees with the overall conclusion of the U.S. Air Force memorandum which is to strongly discourage the use of rigid, prescriptive frameworks such as SAFe.

References:

8.4 - Dave Snowden

David John Snowden is a researcher in the field of knowledge management, and the creator of the Cynefin framework applied in software development and management science.

Overall he expressed a very negative view of SAFe. Among other comments, he explained that SAFe employs ordered world approaches to solve complex problems, and because of that it’s a-priori wrong. As a result, he adds, SAFe is a massive backwards not a forwards move.

References:

8.5 - Steve Denning

Steve Denning is a recognised expert and author in leadership, management, and innovation.

In some of his articles, he describes the efforts to scale Agile with SAFe as counterproductive. He further criticises SAFe stating that it destroys the very essence of Agile, and it degrades and undermines everything in Agile that is authentic and useful.

He added that SAFe gives to organisations a mandate to call themselves Agile while keep doing what they have always done, reaching the conclusion that SAFe is the epitome of fake Agile.

References:

8.6 - Barry W. Boehm

Barry W. Boehm was a prominent American software engineer and author of the COCOMO costing model and the Spiral Model software process.

He commented on the approach embraced by SAFe: “Tailoring-down all-inclusive methods lead to unnecessary expenses in time and resources”, and he adds that it’s the opposite of the Agile approach.

References:

  • The original article with the quotes couldn’t be found, the search done concludes that the most probable source of the quotes is the book “Balancing Agility and Discipline: A Guide for the Perplexed”

9 - Sample of practitioners' opinions

A list of opinions from practitioners that details the problems they identified in SAFe. These opinions may reflect the possible reactions of the employees in an organisation adopting SAFe.

9.1 - Paweł Huryn

Watch Out, Waterfall Ahead! The Truth About SAFe

Paweł Huryn comments in his post on various aspects of SAFe, where he notes that

  • SAFe adopts a Waterfall approach to requirements
  • SAFe processes and roles show a lack of trust and autonomy of development teams
  • SAFe focus is on plans and output more than on outcomes and feedback
  • SAFe version of Scrum deviates from the real Scrum making it worse. He concludes by suggesting that with SAFe an organisation doesn’t feel the need to change anything substantial, but with it, they feel they can call themselves “Agile.”

References:

9.2 - Kevin Bendeler

I Don’t Like SAFe

Kevin Bendeler after working several years with SAFe comments on 7 flaws he noticed in the framework’s adoption:

  • In SAFe extensive front-loaded planning encourages ineffective larger batch size work
  • Technical debt tends to increase in SAFe organisations
  • SAFe Program Increment (PI) cycle time is unfit for teams that need to be responsive
  • SAFe roles and structure may discourage teams collaboration that’s an Agile value
  • SAFe approaches to estimation is more predictive than empirical as in Agile
  • SAFe focus more on output and volume than the value created and delivered
  • SAFe doesn’t have enough focus on the feedback loop and related learnings. He concludes by saying he thinks that trying to scale Agile up by applying heavyweight, top-down methodologies is antithetical and counterproductive.

References:

9.3 - Sam Haynes

SAFe: A Waterfall Pig with Agile Lipstick

Sam Haynes, based on his observations of SAFe implementations thinks that:

  • SAFe’s ask for excessive time to developers for estimations and metrics is demotivating
  • SAFe requirement of starting by getting everyone SAFe trained and certified is suspicious
  • SAFe “branded agile” risk to discredit genuine Agile
  • PI Planning tries to manage dependencies instead of having a loosely coupled architecture
  • PI Planning cadence doesn’t allow to timely react/adapt to changing customer needs
  • PI Planning and Release Trains are inferior to on-demand planning and Continuous Delivery. He wonders why anyone with a genuine Agile mindset would be using SAFe in the first place.

References:

9.4 - Luca Minudel

My Opinion on SAFe

Luca Minudel analyses various aspects of the framework and comments on their practical implications noting that:

  • The 12-step SAFe Implementation Roadmap is like a 1-size-fits-all Waterfall programme
  • SAFe Budgeting and Portfolio management don’t solve the problems of annual budgeting and planning due to the prescriptive, top-down, rigid nature of most SAFe implementations
  • SAFe Requirements Model is a pre-Agile deliverable-oriented hierarchical decomposition of the work mirroring the hierarchy of the roles in SAFe, it reinforces a top-down approach
  • SAFe Roles add more bureaucracy, disempower the teams, and make collaboration harder
  • PI Planning hinders business-tech collaboration, accommodates dependencies instead of removing them, and perpetuates a top-down pre-Agile approach
  • Release Trains is a very inefficient pre-Agile practice inferior to all the modern alternatives
  • Overly complicated SAFe contradicts the Agile principle of simplicity and emergence Following his observations, he concludes that SAFe violates all four Agile values.

References:

9.5 - Yves Hanoulle

My Opinion on SAFe

When I first heard of SAFe, I was hearing the same kind of negative things as I heard when I first heard of Scrum. (From people doing XP) or Kanban (from people doing scrum). So I decided to look for a SAFe project to experience it myself. As I did not want to just have an opinion based on theory. After that project, my general feeling was: SAFe goes further than the companies implementing it want to go and does not go as far as what the companies really need. I saw that at best it was a gateway drug to agile. Yet in most companies, it just gives a new name to an old way of working. A nice example is dependencies, instead of making dependencies transparent to start working on removing them, they at best visualise them so show them as reality. I used to think it was nice they showed many different techniques to a large audience. Now I see that not only do they explain them badly and give practitioners a bad start with a new technique, but they also try to copyright techniques from agile friends. The sentence “this is not agile”, is not agile in itself, yet calling a cat a dog, does not make it bark.

10 - General SAFe trends

The adoption of SAFe and its market share are still growing.

The less flattering trends below come from anecdotal evidence. There is a growing number of Agile professionals and certified SAFe professionals that decided not to work again with clients adopting SAFe. They declared it publicly, it occasionally comes up at meetings among Agile professionals, and some recruiters reported candidates refusing job opportunities because of SAFe.

The number of experienced Agile professionals publicly criticising SAFe is also increasing.

There is a growing number of sr leaders and former employees of organisations that tried to adopt SAFe that are sharing stories of stalled and abandoned adoptions, adoptions that went wrong, and problems caused by SAFe.

The number and frequency of posts on social media and articles in online magazines about failed SAFe adoptions is also increasing.

More organisations are asking for Agile professionals that are framework agnostic, and that have enough experience to work without the need of a guardrail from a scaled framework.

It is not possible to say if these trends are ordinary by-products of the increasing adoptions of SAFe, if they are due to SAFe itself, the quality of its implementations, the characteristic of the organisations choosing that framework, or other factors.

11 - Conclusions

Each one of the top experts’ opinions, creator of a practice integrated into SAFe, scrutinised case study, and practitioner opinion, taken alone in isolation is not enough to draw a conclusion.

At the same time all of them together, with their similarities, seem to suggest that the implementations of SAFe tend to:

  • lack fundamental elements of good Agile that are vital to achieving agility
  • amplify some of the well-known problems and limitations of pre-Agile traditional solutions
  • spend a lot of time and effort to learn and adopt practices that are outdated, or 2nd best

12 - Alternatives to SAFe

At the moment there is not one single best practice, standard solution, or silver bullet that can guarantee an organisation to increase its technical agility, organisational agility, business agility and ultimately become more successful, resilient and innovative.

For decades the whole industry has been trying to find a solution to this, while at the same time the opportunities and the challenges organisations face are also changing and evolving.

But after over 10 years since when large organisations are trying to adopt Agile, we know that there are alternatives that are less recommended and don’t work and others that work.

12.1 - Not recommended alternatives

All heavy-weight frameworks like SAFe, that promise to scale Agile, have problems similar to or equivalent to SAFe.

All the canned solutions and standard recipes for Agile transformations, Digital transformations, and for Scaling Agile, coming from large consultancy firms, don’t work either.

All attempts to copy and paste solutions of other organisations, like trying to replicate the Spotify model, have also failed repeatedly. Also, the attempts to extend or customise SAFe or other heavy-weight frameworks for a particular industrial sector, have failed.

Attempts to adopt Agile following one framework by the book, of running an Agile transformation using a Waterfall programme don’t work either.

12.2 - Recommended alternatives

Successful Agile adoptions or organisations that have successfully developed their technical, organisational and business agility with lasting benefits for their business, often present some common elements. These elements are listed below.

For a more detailed list of available alternatives follow the related links in Appendix 1.

Your chances of success are greatly increased by taking inspiration from these elements below:

  • Embracing an experimental approach to Agile adoptions has been instrumental in many successful adoptions. It consists in starting small and proceeding with small experiments, learning, adapting and evolving. It focuses on making things work well in the small before going bigger. Furthermore, it is an Agile approach to adopting Agile. The journey through these experiments, the mistakes and the related learning are instrumental to understanding, learning, adopting and adapting Agile to your specific organisation’s needs.

  • Using a people-centred approach where employees are invited to participate in the adoption and where autonomy to individuals and teams is increased, has worked well too.

  • Building on the previous point, ​​a focus on team autonomy, coupled with alignment to clear customer outcomes and wrapped up with lightweight governance, instead of the hierarchical and complex SAFe approach, is certainly a more effective way of scaling agile across an organisation.

  • What has also worked well is a focus on descaling the problem. For example, through modularisation, aligning teams and the organisation along individual products and services and more in general along value-streams (take a look at Team Topologies for an in-depth Introduction on this). And also through technical excellence reducing and relaxing cross-team dependencies,

  • A pluralistic approach that takes elements from various non-scaled Agile frameworks (think of eXtreme Programming, Crystal clear, DSDM, Kanban, Scrum, etc.) and patterns and practices available from the Agile community, has also worked well. This approach is informed and guided in each of its steps by the values and principles of Agile, Lean, and Human Complexity.

  • Exploring team types, their composition and their interactions is a key factor to consider when one considers ways of working across an entire organisation. There are a number of constructs that explore this in more detail: Team Topologies by Matthew Skelton and Manuel Pais explores team types (topologies) Sriram Narayan in his book ‘Agile IT Organization Design’ explores similar Sooner Safer Happier by Jon Smart et al - explores safety teams Managing Digital by Charles Betz explores team spectrums Extra-dependent teams by David Kesby explores same skilled teams

  • There’s more exhaustive organisational design literature but the above is a good place to get started. There are also learning triads as well which are worth exploring too but don’t tend to be a long-term team given the size.

  • The above should be considered in the context of an existing organisation but won’t necessarily give you concrete practices to de-scale the work/interaction/dependencies although it’s a good start. What people often need is a platform-based approach (see Jade Bloom) and the book Continuous Architecture by Murat Erder and Pierre Pureur.

  • A focus on technical agility and technical excellence is also a trait common to successful Agile adoptions. With a reference to the domain-specific technical practices used to build the product or to supply the service the organisation offers.

The journey itself to learn and adopt Agile is unavoidable. It is not possible in any way to fast-forward or skip to the finale. Each Agile adoption is a gradual process of exploration and discovery. The destination takes shape and acquires meaning by going through the journey. And it is a place where continuous improvement is the norm.

References:

13 - Sources

Case studies

U.S. Air Force

Ask Me Anything Event – Feb 21st 1300 EST - https://software.af.mil/media-archive/ https://software.af.mil/media-archive/#:~:text=Ask%20Me%20Anything%20Slides%20v2.3 (slide 33)

ThoughtWorks

BlueDolphin

Volvo Cars

ANZ Bank

FitBit

Conclusions

SAFe experts’ opinion

Al Shalloway

Alex Yakyma

Bob Galen

Opinions from the authors of some practices assimilated by SAFe

Jeff Gothelf

Dave Farley

Ken Schwaber and Jeff Sutherland

Agile experts’ opinion

Ron Jeffries

Andy Hunt

Martin Fowler

Alistair Cockburn

Brian Marick

Ken Schwaber and Jeff Sutherland

Mike Beedle

Other experts’ opinions

Chris Matts

Marty Cagan

Mary Poppendieck

Dave Snowden

Steve Denning

Barry W. Boehm

The original article with the quotes couldn’t be found, the search done concludes that the most probable source of the quotes is the book “Balancing Agility and Discipline: A Guide for the Perplexed”.

Sample of practitioners’ opinions

Paweł Huryn

Kevin Bendeler

Sam Haynes

Luca Minudel

Alternatives to SAFe