Der NPS ®-Wert von SAFe ® ist -56 — Die Umfrageergebnisse

In Kürze: Der NPS ®-Wert von SAFe ® als Skalierungsframework ist -56

SAFe® war schon immer ein kontroverses Thema innerhalb der agilen Gemeinschaft. Deshalb habe ich bereits 2017 eine erste Umfrage zum Net Promoter Score® des Scaled Agile Framework SAFe ® durchgeführt. Das Ergebnis war damals -52.

Viereinhalb Jahre später habe ich diese Umfrage nun wiederholt: SAFe® hat zwischenzeitlich mehrere Iterationen durchlaufen und mehr agile Praktiker haben Erfahrungen mit diesem Framework gesammelt. Die Frage lautet jedoch immer noch: Würden Sie SAFe ® weiterempfehlen?

Zusammenfassung: Der NPS®-Wert von SAFe® auf der Grundlage der Umfrage von 2022 beträgt -56. (Details finden Sie in den Daten unten.)

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 34.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Die Daten der Umfrage

Zwischen dem 13. Dezember 2021 und dem 27. Januar 2022 nahmen 505 Praktiker an der Umfrage teil. Ich verwendete zur Durchführung der Umfrage einen Online-Fragebogen, der über Google Forms verwaltet wurde. Der wichtigste Akquisitionskanal war der Newsletter Food for Agile Thought. Außerdem habe ich den Link zur Umfrage über Blogposts und verschiedene Beiträge in sozialen Medien verbreitet.

87 % der Teilnehmer haben praktische Erfahrung in einem oder mehreren SAFe ® Projekten.

👉 Die Ergebnisse einer weiteren Umfrage auf LinkedIn könnten ebenfalls von Interesse sein: Would you recommend SAFe®?

SAFe ®s NPS®-Wert berechnet wurde

Die 505 Stimmen der Umfrage verteilen sich wie folgt auf die elf Kategorien:

Kategorien [0-10]	Anzahl der Stimmen	Stimmenanteil [%]
0	86	17%
1	41	8%
2	74	15%
3	53	10%
4	30	6%
5	33	7%
6	37	7%
7	41	8%
8	37	7%
9	35	7%
10	38	8%

Die Werte der Kategorien 0 bis 6 repräsentieren die Distraktoren-Fraktion mit 354 von 505 Stimmen, was 70 % aller Stimmen entspricht.

Die Werte der Kategorien 7 und 8 repräsentieren die Passiven-Fraktion mit 78 von 505 Stimmen, was 15 % aller Stimmen entspricht.

Die Werte der Kategorien 9 und 10 repräsentieren die Promotoren-Fraktion mit 73 von 505 Stimmen, was 14 % aller Stimmen entspricht.

Folglich berechnet sich der NPS®-Wert von SAFe® auf der Grundlage dieser Stichprobe als Promoteren minus Distraktoren gleich -56. (Ich habe Excel zu diesem Zweck verwendet. Sie können aber auch einen Online-NPS®-Rechner hierzu verwenden.)

Sie können das Formular nicht sehen?
Dann bitte hier klicken.

Zitate von Umfrageteilnehmern

Die folgenden Zitate von Teilnehmern decken das gesamte Spektrum der Antworten ab, geordnet von Distraktoren über Passive bis zu Promotoren. Bitte beachten Sie, dass ich Grammarly verwendet habe, um Tippfehler und Zeichensetzung zu korrigieren:

While the cross-team big room planning is very useful, in my experience, SAFe is top-down. Executives that are not close to the customer problems make the decisions at the portfolio level, and teams execute, which can lead to disengaged teams. I would be in favor of a scaled framework that empowers teams to solve customer problems the way that Scrum does. (Quelle: Macon Morrison.)

SAFe revels in redefining useful ideas, by that they dilute their meaning, which in turn stops people from growing because they‘ll have it harder to discover the novel and challenging original ideas. SAFe profits from hype topics that they incorporate but bring nothing of value back. The release train used to be a very useful pattern for coordinated multi-Team single-product releases; stretching it to a whole org is a huge waste. A dependency board used to be a good way to figure out what dependencies to eliminate; now, it only encourages people to “plan better.” WSJF used to be a very useful prioritization formula; the way SAFe calculates it is a perversion. And the one novel idea that they had, big room “increment” planning, is novel because everyone else considered it a huge waste of time and never proposed the idea. SAFe could do me thing to improve quickly, though, but the feedback loop and the user into the middle of their diagram and scale them up. (Quelle: Richard Gross.)

SAFe is an immoral consultant’s wet dream. It’s a technique to pray on the insecurities and misunderstandings of companies and take ridiculously large sums of money and redistribute it to the consultant’s pockets. (Quelle: Martin Hinshelwood.)

SAFe is for compliance and contacts, Scrum for performance. While there may be valuable concepts to consider within SAFe, my observation of companies trying to adopt it focuses mostly on certification and compliance rather than deepening the understanding of agile principles and values, specifically on the leadership level. This results typically in focus on adopting practices – without focusing sufficiently on changing behaviors in an agile-friendly way. (Quelle: Wolfgang Hilpert.)

Too often, it is rolled out, top-down, left-right (in the traditional enterprise SDLC). It completely ignores any technology or architectural constraints and doesn’t surface the underlying cycle times and/or lead times that the organisation is operating with, testing is often still left as an integration cycle post the PI and invariably 18-24 months into the adoption, people are staring at unchanged outcomes in either productivity or agility. It also creates an incredibly greedy machine that becomes ‘sentient,’ and no single individual is able to control or reset the system. (Quelle: Rory McKenna.)

I have hours of content on why SAFe is non-viable, but I’m looking at it from the perspective of CX and UX. SAFe shows that time after time, it has no idea what UX is, who should do it, or how it’s done. Their “HCD” articles were written by Agile coaches who never worked a day in UX and clearly Googled the topic to write the article. SAFe uses their “principle 9” to claim that UX can be “decentralized” and anybody can do UX work, yet their own definitions of what can be decentralized would show that UX CAN’T be decentralized… they must not understand UX at all. Their page on continuous delivery assumes that “design” takes 4 hours (not if you want it done well). It’s speed over quality at its worst. Saddest is that given decades of UCD and HCD as our key processes, SAFe picked “Lean UX” to add to their model. Lean UX is neither Lean nor UX; don’t be fooled by the name. It’s a non-viable, workshop everything model that nearly zero UX practitioners adopted. I have hours on this as well. But you can see why SAFe liked Lean UX. Lean UX is a model where UX has no real power to do much or make decisions. Everything is done by a workshop and team meeting. UX can’t do anything themselves. So if an Engineering model wants to make sure to dominate UX, you pick Lean UX (which is why nearly all UX professionals have, willingly).

Ultimately, we need to look at Tri-Track Agile so that Engineering doesn’t control UX. Consider models like the “Three Voices,” which treat Product, UX, and Engineering as equal partners and collaborators. It’s not a democracy in any of these domains. These domains retain their power and don’t let everybody make decisions. They don’t workshop their work to death. Product doesn’t roadmap-by-committee or sticky note. And then SAFe dropped “Customer Centricity” and “Design Thinking” on their infographics, but they still have no idea what these mean or how to do them well.

Can we please talk more about this? We need to kill any Agile approach that doesn’t aim towards customer-centricity, and our highest priority is customer satisfaction. People read Agile Manifesto principle 1 and saw “continuous delivery.” So they turned engineering teams into assembly-line robots, putting them under pressure to do more faster. Then they tried to get UX to do more faster, but we’re about quality of work. We’re about biz intelligence and risk mitigation. Better research upfront means better knowledge about users’ needs and tasks. Better risk identification. Avoiding the wrong products or features, just like Agile and Lean claim to want us to. Again, I have HOURS of content on this—articles, books, videos, etc. I would love to give you more information if you are publishing this!

(Quelle: Debbie Levitt.)

SAFe is inconsistent with an agile mindset as it is plan-focused, bureaucratic, complicated, dis-empowers team autonomy, and includes a lot of often unnecessary processes and structure. It replicates the portfolio level management hierarchy established by PMI, by defining roles and responsibilities at the portfolio, program and team level and by also introducing the solution level. SAFe enables top-down bureaucratic control, as decision-making powers in the SAFe structure are generally left to the managers and organizational leaders; misunderstanding of epics which in SAFe are substantial enterprise initiatives that need to be evaluated for their potential return on investment before they can be initiated; lack of flexibility-the framework is difficult to adopt and team members are stuck in their defined roles; SaFe is excessively oriented around planning. The release planning sessions involve bringing lots of people together, which poses a challenge. Getting positive results and clear direction from these meetings is a typical problem; the framework is oriented around volume and not value; it limits retrospectives and continuous improvements; makes it difficult to produce a high-level quality product increment, as due to the large-scale nature, it can be strenuous to run quality assessments on every bit of code that’s written; the tendency to organize work in massive batches produces issues with work estimation; dependencies are managed by increasing focus on planning, process, hierarchy, and standardization; SAFe collects small product teams into “Agile Release Trains” groups of teams with an additional layer of management roles spanning each group at what is called the “Program” level. Generally, these roles impede the autonomy of teams. They add process and communication overhead out of proportion with the value they provide. The System Architect role, which is a stamp of big design-up-front waterfall projects, is well preserved in SAFe. As the System Architect is not in a position to be close to the actual teamwork, the architectural solution they devise may be disconnected from reality; the innovation or IP sprint is a notoriously misused phase in the SAFe framework. Teams or enterprises often use it as a hardening phase for the increment, mainly for bug fixes, pipeline issues, stabilization, etc. (Quelle: Alexandra Ursea.)

It is a certification factory that absorbs the deep thinking done by others and rebrands into something tepid enough for large enterprises to buy. It sells a fallacy that agility can scale like a cloud-native app.

In reality, agility requires a deep cultural change in most organisations that has to be led from the top. Thinking and acting empirically is alien to most organisations. Most adopting SAFe stop short of the changes required and will surely jump on the next big thing when it arrives.

(Quelle: Rob McDonald.)

There is just too much about SAFe that is skewed… I hold a strong grudge about the way they disempowered the product owner and scrum master. They use contradictory language. For something they claim to be non-prescriptive, it is overly prescriptive. It is a “yes, but” approach to agile. There is nothing lightweight about it.

Nearly all the signatories of the Agile Manifesto and many other prominent agile leaders, including Scrum, Lean, and Lean UX leaders, have turned their backs on the way SAFe approaches these ways.

I don’t like the way SAFe approaches Scrum (or agility in general). It hides behind pragmatism, but it takes the spirit out of the game.

I don’t challenge the good intentions driving the creators of SAFe nor those who reel SAFe into their organization. SAFe inherits a truckload of rigidity; they didn’t create it. It won’t make any significant difference no matter how much Agilecadabra and consultancy fees one throws at it.

What SAFe practitioners are doing is bold, and I fully support the mission of taking on rigidity no matter how large the enterprise. But please, enter the light. Remove the prescriptiveness and please get real with Scrum, or get out of Scrum!

(Quelle: Sjoerd Nijland.)

SAFe provides a complicated, over-regulated, over-staffed, and rigidly structured framework for providing command and control at management layers and so is systematically non-agile. It attempts to give the illusion of promoting agility at lower (team) layers, but the overarching rigid non-agile structures mean this can only ever be a limited effect. In my experience, team members can work in a more agile-like way by locally discarding SAFe dogma and using more proper agile practices. In summary, SAFe is really about making it easy for management to control and track the progress of the teams, who often deliver results despite SAFe and its awful ‘commitment-based’ planning and restrictive non-agile practices. Because of its inherent over-complexity SAFe also perpetuates the need for organisations to buy ever more expensive training and contract expensive consultants, who invariably recommend more of the same. But, finally, I would say that some agilists have no choice but to work in organisations that use SAFe due to lack of proper’ agile jobs. I am in that position myself, and so I attempt to work slowly and steadily to win small battles by moving away from SAFe practices and introducing small improvements where possible. I try to influence and change the minds of people who blindly see SAFe as the answer by offering how we can steadily improve practices by becoming more agile, especially at the team level. In this way, I do see myself being able to make a difference and not have to completely sacrifice my agile principles. Ultimately I am convinced that most people do want to improve by becoming more agile even from within the stifling dogma of SAFe. (Quelle: Dave Holland.)

SAFe is a very dangerous framework to implement when it is your organization’s first touch with Agile. I’ve seen SAFe go wrong in almost all companies I consulted because they used the framework to go from waterfall to ‚Agile.‘

But because of the huge amount of hierarchies in SAFe, these companies just mapped their old titles and processes on the SAFe roles, artifacts, and ceremonies. SAFe didn’t really transform their way of working, although they all believed they went through a rough agile transformation.

Eventually, the value was still delivered by hidden projects that took multiple months to be completed end-to-end.

I have only had one customer that was more or less successful in implementing SAFe, but it was already practicing Scrum for more than five years in their separate development teams.

They looked towards SAFe as a vehicle to improve their collaboration between teams that were located all over the world. But with their ‚Scrum‘ luggage, they were able to look critically towards the framework and questioned certain aspects to remain focused on the delivery of value (and not just Epics/Features/Stories).

(Quelle: Jeroen Nollet.)

A big elephant dressed up for the agile ball. (Quelle: Mario Aiello.)

It’s a mixed bag of useful practices. As long as you see it as a library of different practices, I believe one can benefit from it. Many practices are described in detail and with steps on how to conduct them. This has value for me.

As a whole, I find it too rigid, with too many roles, too prescriptive, and confusing as well. The confusion for me is in the practices that are described. They differ from scrum patterns, for instance. A scrum of scrums has a different definition compared to a scrumplop. This I find confusing.

Claims like ‘you need to become Agile first’ and ‘prevent scaling’ sound nice, but in reality, SAFe is ‘implemented’ by companies (that I’ve worked with) that aren’t what I would call mature in living the Agile principles. And the first thing that they do is scale.

(Quelle: Eddy Bruin.)

Its infographic can help organizations understand the basic building blocks you need for an agile organization. However: SAFe doesn’t help AT ALL in driving the cultural change necessary for an agile transformation. On the contrary: SAFe makes people believe (similarly to the Spotify model) that “if we apply this structure, we’re agile,” whereas companies still drive their “fixed (upfront) scope, fixed time (deadline already committed without consultation), fixed budget” projects. (Quelle: Robert Kalweit.)

SAFe is a framework that provides large organizations with opportunities to incorporate Agile thinking at program and enterprise levels. It lets Agile teams practice their Scrum, Kanban, XP development as appropriate (depending on maturity) but by addressing the areas of biggest impact: how to help the business drivers and shakers to focus on their priorities and value opportunities. By addressing particularly the program and capabilities and not so much the user stories, it can help influence the influences, thus reducing the chaos often impacting Teams. When teams are impacted, it always slows the rate and comprehension of Team Agile concepts. Implementing SAFe also helps to address the inclusion of departments that are usually fringe to a development team, such as Data, operations, security. Not all companies or organizations need to adopt a framework like SAFe to do this; for some, the values, priorities, and communications are already in place. But for those without, for those who could benefit from having a framework to follow, then it’s a great opportunity to Adopt, Learn and Adapt. (Quelle: Anne Riley.)

Retread of RUP with an agile twist. Looks attractive to firms that can’t let go of top-down project management thinking. It has some smart features, like enforced quarterly ‚big room planning‘ and the release train concept, but wrapped in a hierarchical and bureaucratic wrapper. It may be suitable for some firms but not a panacea, or even a solution, for scaling challenges. (Quelle: Rick Freedman.)

SAFe is perceived as a robust packaged approach to achieving business agility which is attractive to organizations and leaders who want and need black and white steps to follow rather than espoused theory by dogmatic practitioners acting like kung fu masters boasting their style is the best and only way. I view SAFe as sort of a trojan horse. It will get me through the organizational gates so then I can begin better observing and advising on how to uniquely make the framework best for the context at hand. I don’t like the PI Objectives and how it is treated as “everyone gets a trophy,” nor do I like how Business Value is taught. I express those thoughts to my clients and provide alternate solutions, which is my responsibility as a steward of my clients’ trust. People are able to make SAFe work for some contexts; other people are not able to. It still comes down to people and the choices they make. SAFe doesn’t jump off a shelf into your enterprise; people choose it, people lead it, and people decide what is working and what isn’t. (Quelle: Bruce Nix.)

From my point of view, SAFe covers a lot of topics of the business as well as the agile contexts. Due to their history and structures, companies might struggle with the (from their viewpoint) sometimes esoteric aspect of an agile mindset / other agile frameworks. SAFe is, therefore, for them a safe option to not get rid of every old structure but at least try some agile methods.

This actually already provides both sides of the medal from the companies/organizations perspective: Positive: Companies might be more willing to try out agile methods as it seems that they don’t need to change too much at once. Negative: Companies might, due to not changing central aspects (which are could be the main causes for not being able to succeed in getting more agile/flexible at all), not achieve the hoped-for positive effects and therefore reject further experiments.

From an individual perspective: I have the perception that often, people are looking for concrete advice for how to do certain things (e. g., how to run a proper review). Most frameworks are not very specific (which is a good intention!), still sometimes not satisfying the needs of the once starting their agile journey. Here, SAFe provides some more concrete answers, which then again lead to people following those guidances as if those were laws.

My perspective is that SAFe can provide some interesting aspects which are worthy of trying out. Still, I would not recommend trying to be dogmatic in setting up a full-blown SAFe approach. Every environment/team has its own specifics, why I tend to inspect the circumstances and check what to do next => instead of just recommending any kind of framework (which also includes not blindly recommending Kanban, Scrum, etc. which is even more important when it comes to scaling!).

(Quelle: Ronnie Kellenberger.)

SAFe provides a rich set of resources and tools and very useful elements for Agility. Like any process framework/methodology, it can easily be abused and, if it is rigidly implemented, can become as much an obstacle as an enabler. Some of the criticisms against SAFe (that I had myself) can also be seen as benefits in the right context; for example, I was very outspoken about how SAFe disempowers the Product Owner at the squad level, establishing a hierarchy. However, I have found that it can be a healthy environment for young and inexperienced Product Owners to be developed with strong support from the ecosystem.

In conclusion, I would say when selectively and pragmatically used SAFe has a lot to offer.

(Quelle: Stefan Wolmarans.)

SAFe is a very well-documented set of practices that are very useful for the Agile Transformation of big organizations. These practices are not invented by SAFe; however, these fit each other and to the concept in general.

We can see SAFe as less flexible and more prescriptive than, e. g., the Spotify model; however, we can’t forget that agile transformation is a journey, and SAFe provides great help for “traditional” organizations.

In past years we saw several versions of SAFe, which shows that SAFe Inc leads from feedback and sets the priorities based on it.

(Quelle: Denis Bogdanov.)

I think SAFe is working well in our environment. It provides a balance between being able to provide expectations and commitments to our business partners and being able to refocus quickly to keep in front of changing demands. I work in a large organization where we have to coordinate with multiple organizations–both internally and externally. The SAFe framework allows us to plan with all of our stakeholders so that we are all working towards the same goals. We are not so rigid with our plan that we cannot change if new regulations, directions, etc., arise during the middle of a Program Increment. (Quelle: Barbara Weaver.)

I was very skeptical at the start, and when going through SAFe training – it seemed like a bit of a money grab. At the end of the course and using what I’ve learned, I believe that there is a place for SAFe with traditional large companies. SAFe attempts to manage and answer the kind of questions and issues large companies face in a controlled manner.

I suspect part of my answer is that I am in the honeymoon phase with SAFe, but it has certainly been helping (me at least) in getting to answers required by the company I work for.

(Quelle: Pierre van Dyk.)

The most adopted, well-rooted, well-supported, well-descriptive, agile practice scaling solution for organizations that need to move from a handful of agile teams to a synchronized, collaborative, and better aligned, yet much larger agile entity with a functional and workable connection between strategic steering and trench-level product development and deployment.

It expands on the fundamental agile values and agile principle and adds a wealth of underlying knowledge and set of values and principles that enrich the practice with lean portfolio steering and budgeting and customer-centricity and inclusion of DevSecOps into an enhanced tri-interloop of Continuous Exploration (CE)/ Continuous Integration (CI) / Continuous Deployment (CD).

It also comes with a strong recommended set of KPIs (from team level all the way up to enterprise portfolio level) and the modern way of focusing on Business Outcome, supported by Business Competency and Agility.

It is recommended for an organization with a solid org chart and a growing number of agile teams, who don’t want to shuffle and re-org but have outgrown their ability to synchronize and collaborate among many agile teams and external dependencies and find it hard to connect the big picture roadmap with the detailed creation and delivery of the workable software.

Is perfect? Certainly not! But it has been the most successful agile scaling framework in following its core value of Continuous Learning and Improvement and is now at version 5.1.

(Quelle: Arman Kamran.)

SAFe brings two values: curation of good ideas and practices (e. g., Design Thinking, OKR) and an adoption path for big non-agile companies (which may be much less valuable to small or agile companies). (Quelle: Daniel Halber.)

As a bridging framework to take an entirely Neanderthal organisation towards a journey of true agility, it helps to create that path. The cost of recertifying is annoying and reeks of a cash grab. The best part is the big room planning event to align the entire group. The rest is well known from the community. (Quelle: Adam Murray.)

SAFe is a great scaling FRAMEWORK that can be adapted to any organization. Two detractors from SAFe are 1) “By the Book” consultants that use SAFe more like a blueprint than as a framework and 2) SAFe used as a PMO “hammer” to rebadge archaic command and control processes like Agile. Most organizations that struggle with SAFe also struggle with creating an agile culture in general, and SAFe becomes the scapegoat. (Quelle: Michael Harpold.)

First of all, your first question was inappropriate as we SAFe we don’t do projects, but we work around a solution in a development value stream.

SAFe integrates all the best practices of agile, lean, and DevOps in a consistent big picture with a clear set of concepts, rôles, practices.

Obviously, the aim is not to “do SAFe” (neither is to do Less nor Scrum nor Nexus). We need first to understand what Agile & lean is and use the illustrated practices to solve issues for enterprises that are engaged on this agile journey.

What I often found is that there are a lot of coaches that don’t understand lean & agile and use SAFe as a Bible to be followed without the understanding of it.

For example, a good SPC will never present the SAFe Big Picture top/down but bottom/up.

A second great source of inspiration provided by Scaled Agile is that aside from the practices that are pictured in the framework, there is also work done around the “Competencies” that a lean Agile Enterprise should acquire.

This is a great tool to avoid the misunderstanding that if I have an Agile Release Train, then I’m agile. The growth measure evaluates competencies maturity and not which practices are ~in place.

Last but not least, SAFe is the only reference of experience that tackles the portfolio level that allows real agility by enforcing a lean mindset at the top level of the enterprise. They also share their best experience on how we could successfully transform an organisation thanks to the implementation roadmap.

Again these elements are aimed to be a source of inspiration from previous experiences and not a set of items to be followed “by the book” as we all should embrace adaptability.

(Quelle: David Ferreira.)

Markenbekanntmachungen für die ‚Würden Sie SAFe ® empfehlen?‘ Umfrage 2022

Bitte beachten Sie, dass sowohl SAFe® als auch der Net Promoter Score® eingetragene Marken der jeweiligen Inhaber sind:

• “SAFe® is registered marks of Scaled Agile, Inc.” For further information click here.
• “Net Promoter, Net Promoter System, Net Promoter Score, NPS and the NPS-related emoticons are registered trademarks of Bain & Company, Inc., Fred Reichheld and Satmetrix Systems, Inc.” For further information click here.

📖 Empfohlene Lektüre

Survey Results: The Net Promoter Score® of SAFe® as a Scaling Framework is – 52

Scrum Master Gehalt 2022 — die Umfrageergebnisse

Download the ’Scrum Anti-Patterns Guide’ for Free

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

✋ Nicht versäumen: Lernen Sie mehr über den NPS®-Wert von SAFe ® in der 11.000-köpfigen „Hands-on Agile“ Slack-Community

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Tags: Agility, SAFe ®