DORA Core v2

[davidstanke]

UPDATE 2024-07-10: DORA Core V2 is now live at https://dora.dev/research/

DORA Core was designed to be updated regularly. As of April 2024, we have had time to digest the 2023 State of DevOps Report, so it's an ideal opportunity to consider the next version of Core.

Review the proposal:

DORA Core V2 Proposal
UPDATED May 23, 2024

...then share your feedback in this discussion. Thank you!

[Winael]

Hi @davidstanke

Thx for this update. As I understand, now the Capabilities are classify according to their impact instead of their categories. Is it planned to update the website as well ?
As a DORA former, I noticed that for people that discover DORA frameworks, the multiple arrows modele help them to understand that it's a choose-your-own-path transformation model and the systemic impact of each Capability. Do you think that this new modele is understandable as well? (It's too hard for me to think as a new comer now)

Also, I have a knowledge sharing meeting with my DevOps Coach team tomorrow, I'll try to suggest that we could study this proposal together and I'll share with you their feedback asap :)

Regards

[davidstanke]

Thanks for the feedback, Vincent! Yes, we will definitely update the website with V2, as soon as it is finalized. I share your questions about the multiple arrows -- the "choose-your-own-adventure" approach is absolutely what we had in mind when we introduced them in V1. But we've learned that users (especially newcomers!) are finding it a bit overwhelming, which makes it less useful. So I am a bit ambivalent about whether they belong in Core. Let's see what other feedback we get!

Eager to hear feedback from your DevOps Coach team!

[steve-fenton-octopus]

I've broken my feedback into bullet points below:

• Yeeeeeeesssss! I love it.

I think the update will make the information easier to comprehend for a broad audience and I 100% back all the changes.

Additionally, the way the changes were clearly highlighted in the v2.0 proposal made it very easy to see each change.

[pberry]

Agreed, this is a very nice visual update that makes sharing and understanding easier.

[lisacrispin]

I love the groupings of climate for learning, small changes, and fast feedback. These are pretty much the secrets of successful software product development, right? I also like including the service level data. One of the best things for me is that it doesn't call out any specific specialties like "developer", "SRE" etc. We are all in this together.

I always appreciate being reminded that well-being and satisfaction are important outcomes. I'm allergic to the word "productivity", I've seen it so misused over the decades since it first sounded so great to me in MBA school. I prefer to say "able to do one's best work", but that's not short and catchy. "Best work enabled?"

[alonsomoya]

some of my thoughts here...

• I find the change from "Loosely coupled architecture" to "Loosely coupled teams" misleading. While the first one evokes me to multi-tenant and self-serviceable Platform Engineering as DevOps enabler, and the second one sounds to me too open and a reference to team "autonomy" vs "centrality of Ops"
• "Shift Left on Security → Pervasive security". I would even have "Shift Left" alone, as in my opinion it is indeed common to many Dev(X)Ops practices not only Sec (thinking FinOps, GreenOps... and actually many of the 50 concepts as code)
• From v1 I like the central positioning of the "generative organizational culture" and "Streamlining change approval", while in v2 they are sort of hidden with the rest

[davidstanke]

Thanks for the feedback!

[bobharwood]

I'm trying to "squint" and read it as enterprise architecture (including business architecture), but i agree that the team structure is only one aspect. Spot on for pervasive security. :-)

[devops-novice]

Progress for good, I must say. However, there is very high emphasis on the SLOs, and the metrics around them are overfocused. Practically, it is impossible for any organization to journey from capabilities to performance to outcome based. In an earlier version, one had the edge that it was understandable from the point of view of meeting the objectives well. One of the ways it could be addressed is adding measurements for Reliability besides SLO as well if possible.

[davidstanke]

Thanks for the feedback! Do you have any suggestions on what kinds of measurement might be universally applicable for Reliability? In our research and experience we've found that reliability is incredibly context-specific ("too slow" for one user base might be "just right" for another). The SLO framework offers universal principles that teams adapt to their individual contexts. Are there other frameworks we can explore?

[ikurochkin]

Hi everyone, some thoughts and comments:

1. I believe that the names for the three main categories for capabilities could be made clearer. In my opinion, the current categories may not fully align with both theory and practice. Аccording to the DevOps Handbook, the categories/ways listed include Flow, Fast Feedback, Continual Learning and Experimentation. So i would suggest 3 categories: Fast Flow, Fast Feedback, and Learning Culture.
2. I'm curious about the difference between "Small Changes" and "Small Batches." Could you please clarify? Small batch/change is also highlighted as one of the five principles of Continuous Delivery practice (as mentioned here: https://continuousdelivery.com/principles/) and it is difficult to identify the main principle.
3. Regarding Code maintainability, I believe it aligns more closely with Flow and the ability to make changes quickly.
4. In my view, Documentation contributes more to the Climate for Learning rather than Fast Feedback, because documentation facilitates learning and enhances team autonomy.
5. I would argue that Resilience Engineering also fosters a Climate for Learning, as its primary principle involves learning from failure.
6. Lastly, I'd like to point out that Trunk-based development cannot be easily replaced by Working in Small Batches alone. Trunk-based development involves a wide set of practices, as detailed in the primary source at https://trunkbaseddevelopment.com.

Thank you and I hope you find my comments valuable.

[davidstanke]

Thank you so much for the thoughtful feedback! I'll offer a few thoughts and I would love to hear others'...

1 / 2: Great points! We may be missing an opportunity to align the Core model to other established frameworks. There may be some edits coming. :)

3: That's a fair point, and in truth, most of the capabilities don't fit squarely in just one category. Having the groupings helps make the model more approachable, and people have responded favorably, but it's reductive and imperfect, and many of the capabilities could defensively be put in multiple categories. FWIW, my reasoning draws on the observation that [good] software engineering involves a lot more reading of code than writing of code, and so I think of the benefits of a well-tended codebase as being more about comprehension, and learning, than velocity. But it's totally both.

4: ...that said, sometimes it's clear where a capability belongs, and in this case I got it wrong. You're absolutely right (IMHO): Documentation should be under Learning. I will fix that!

5: This is another tough one, as Resilience Engineering is definitely intertwined in all of the categories. Let's consider that change.

6: Agreed -- Trunk-based development ("TBD") is not synonymous with working in small batches. However, as I understand it, small batches + continuous integration + deployment automation + [other capabilities?] --> encompasses most or all of TBD. So why not just use TBD? Two reasons: 1) When we've studied TBD, for the past few years, we find that it has mixed utility—it helps software development, but increases burnout (see: State of DevOps 2023), making it dangerous to recommend as a universal good [the same is not true of Working in Small Batches]; 2) It's arguably more of an implementation detail than a principle—TBD enforces small batches and motivates CI, but the specific rules of TBD may not be the only way to achieve these things.

WDYT?

[marjorg]

1. When we've studied TBD, for the past few years, we find that it has mixed utility—it helps software development, but increases burnout (see: State of DevOps 2023), making it dangerous to recommend as a universal good [the same is not true of Working in Small Batches];

@davidstanke Noticed that when reading the report. To me, as a fan of TBD, I'm struggling to see why it would have a substantial increased effect on burnout. Do you have any more details on this from the research, or what other strategies may have a more positive impact?

[steve-fenton-octopus]

There's a great discussion thread on the subject of TBD + burnout in the DORA Community Group.

[marjorg]

Based on the discussion thread it seems that there is pretty wide support for the idea of this being a correlation rather than a causation, and that there might be external factors to this, what's the teams thoughts on that?

2. It's arguably more of an implementation detail than a principle—TBD enforces small batches and motivates CI, but the specific rules of TBD may not be the only way to achieve these things.

I'm a bit torn on this. Version control is already considered a core capability, so I understand why TBD might be viewed as an implementation detail. However, in my experience, how you do version control can significantly impact burnout, deployment pain, and productivity. I would appreciate more research on this in the future. Perhaps the version control capability could be expanded to include guidelines on best practices and those to avoid?

Speaking of deployment pain, I see that has been suggested removed as an outcome of well-being. I've been trying to find some details on this but no luck so far, can you direct me to a discussion or provide some details on the reasons for that?

[davidstanke]

Speaking of deployment pain, I see that has been suggested removed as an outcome of well-being. I've been trying to find some details on this but no luck so far, can you direct me to a discussion or provide some details on the reasons for that?

That's a good point! We didn't really talk about that. Here's what I'm thinking: a) we already have a number of items in the V2 proposal under Well-being; b) deployment pain overlaps with some of those items; c) deployment pain is somewhat role-specific—some people in the org experience it a lot, while others don't experience it all. So I think the model becomes more relatable [e.g. to executives who are encouraged to start from the right column and flow leftward] if we don't call it out specifically but instead encourage all job roles to interpret well-being in terms of their unique pains.

[Winael]

Hi,

I finally have feedbacks from my DevOps Coach Team. We're very emphase with the Reliability metrics and the adding of resilience engineering. The change from MTTR to FDRT was very disturbing when we talk about it few month ago but having SLO metrics allow us to have a strong impact on QoS side.

One of my co-worker ask me why there is only a focus on Burnout and not a global aspect on psychological safety since burnout is just one of psychological issues in team (She's a Coach Pro too). Maybe in the future, Psychological Safety could be an outcomes instead of just well being. Transformational Leadership, Work distribution, Organizational Culture could have an impact on this outcome.

What do you think about it ?

Regards

[davidstanke]

Thank you for the follow-up! Agreed, Psychological Safety is a massive driver of organizational success and well-being. (Google's "project Aristotle" internal research project found that it's the single most important quality predicting the success of a team.) It's not currently shown on the Core model for two reasons:

1. It's unclear exactly where it belongs—it could arguably be a capability to develop, a measurement of progress, or an outcome to celebrate. But the bigger reason is...
2. DORA hasn't consistently studied Psychological Safety as such... it's definitely present within Generative Organizational Culture, and implicit in such concepts as Empowering Teams to Choose Tools. But it has not been assessed directly and modeled in our structural equation models. And so, it can't be included in Core -- not until we have 2+ years of directly studying it. Which is definitely something to consider for future research!

[stevemcghee]

with regards to the Reliability and SLO stuff, raised by @devops-novice and @ikurochkin above (breaking this out into its own thread as it might be broad):

• Is Performance just two things? Velocity + Reliability. (aside: what about Cost?)
• if so, I wonder if Reliability has these 4 metrics similar to how Performance has (the existing "key") four metrics.
• they're currently worded around "SLO thing" but I think that's maybe just an artifact of how we've talked about all of Reliaiblity through the lens of this one tool "SLOs" in the past.
• Perhaps Velocity could be thought of as "Service Delivery Objective" (SDO) similarly. Not that we should call it that, but just as a thought exercise. In that case, we'd have SDO lead time, SDO frequency, SDO failure rate, SDO recovery time.
• That said, perhaps the four "SLO things" are just poorly named, too tied to the specific implementation of SLOs that we might have in our heads.
• Really it's just:
  • Reliability Coverage - are we measuring reliability consistently?
  • Reliability Fit - are we measuring the reliability of what users actually care about?
  • Reliability Balance - are we hitting the right level of reliability (eg: 99 vs 99.99)
  • Reliability compliance - are we staying reliable?
• Better words welcome :)

As for Resilience Engineering, yes it's related to Climate for Learning, but it's also what you do with that learning. Perhaps there are two things here: Learning from Incidents (or Failures) in CfL, then Resilience Engineering (in FF). But they're very tightly coupled imo. There could be a case made for RE being done without explicit LFI (eg: you don't necessarily need to experience an outage before you start doing replication and load balancing). You can also learn things from incidents that don't result in any Engineering changes (they might be cultural or product changes).

[davidstanke]

Thank you! I think we can omit the word "reliability" when presented in this context (with Reliability as a header), but if we were to present them without the header (IDK if we're likely to do that), we could prepend "reliability" to each one. So how about...

Measurement coverage
Are reliability measurements (SLIs) in place for all critical services/applications/components?

Measurement focus
Do reliability measurement (SLI) definitions reflect system behavior as experienced by users?

Target optimization
Are reliability targets (SLOs) set appropriately, reflecting user sentiment and organizational capability?

Target compliance
Are reliability targets (SLOs) consistently met?

[davidstanke]

[black-snow]

I didn't read the above discussion but the picture confuses me a bit. It's weird to see the two stability (rather synonymous for reliability for me) measures and then have a section "Reliability" that doesn't feature them. I get the difference between the two sections - just a quick thought.

[steve-fenton-octopus]

The stability metrics are measures of software delivery stability, rather than operations reliability.

Change fail percentage and failed deployment recovery time refer to the stability of the software under change. The reliability metrics are about meeting SLOs in production, including handling unpredictable incidents and infrastructure maintenance.

If you imagine stopping all development, your stability metrics effectively stop signalling. The reliability metrics continue to signal, as networks fault, power goes out, and Steve hits "shut down", when he only meant to "log off".

[black-snow]

Please don't hit "shut down", Steve ;)

[davidstanke]

I just realized that "loosely coupled [teams|architecture]" should really be categorized under "small changes|fast flow". I plan to make that revision. (Continued caveat: arguments can be made either way, but IMHO the key benefits are more aligned to shipping faster.)

[black-snow]

Hi @davidstanke,

I partially missed the conversation about this proposal yesterday. So here are my two cents:

• I like it a lot! It feels way easier to consume and better organized. Great evolution - looking forward to v3 ;)
• Small batches vs. TBD - seems very reasonable. Two people seem to have three opinions on what TBD actually means (surprisingly or not). This leaves the door open for slightly different understandings (that actually work well for different teams), yet not too wide open when combined with the other capabilities.
• Loosely coupled teams vs. architecture due to Conway's and the architecture is hence implied? I kinda like it, it requires you to give it a little extra thought, though. But as long as the details have ... the details that's fine.
• About "Empowering teams to choose tools" - I feel like I'm missing the contrast a bit. Something like golden paths, tools, and templates provided by a platform team. As well as some agreed upon standards every team must live up to. Without that, I read the model as "everyone just go and do whatever you deem best", which is a nice idea but doesn't seem to work out very well.
• I like that "shift left" is gone (we are "shift down" now, aren't we?), I'd need an explanation for "pervasive security", though.

[davidstanke]

About "Empowering teams to choose tools" - I feel like I'm missing the contrast a bit. Something like golden paths, tools, and templates provided by a platform team. As well as some agreed upon standards every team must live up to. Without that, I read the model as "everyone just go and do whatever you deem best", which is a nice idea but doesn't seem to work out very well.

Agreed! That name isn't ideal... if you read the article about this capability you'll see that things like Golden Paths are strongly implied (though we don't [yet?] use that term). A more accurate name for that capability might be: Empowering teams to choose tools, from within a curated list which is well-maintained by a team with sufficient resources. But that's kind of a mouthful! :) I'd love to hear the community's suggestions for renaming this to something that's both simple and representative.

[davidstanke]

Thank you to all who have contributed to this discussion! I've processed your feedback, and made several revisions to produce a second release candidate. You can see it at the same link:

DORA Core V2 Proposal

How can we continue to improve it? (One thing we definitely need is to align on language for the reliability measurements -- see the comment by Steve for context)

[abitrolly]

I didn't read other comments. Just first impression here.

Background

DORA Core represents a distillation of DORA’s most foundational findings ... Read more on dora.dev/faq.

So that basically tells that "DORA Core is DORA findings". I would appreciate no self-referencing acronyms. And when it fails to explain what is this DORA is about, it sends to FAQ. I understand the intention to keep the document readable by making it short, but maybe taking the FAQ and making a short text out of it in Simple English ™️ about what is DORA, and why DORA findings are not called "DORA Findings" will be more beneficial to understand what this all is about.

I mean it is too obvious that 2.0 is a continuation and iteration over 1.0, but instead forcing people to go read 1.0 it would be better to repeat the (now updated) explanation of original problem and background as if there is no DORA at all. Otherwise it becomes DORA is about DORA, which looks kind of self obsessive (not really, but still).

"DORA Core" or "DORA Core Proposal"

If that's not a final text of "DORA Core 2.0" then maybe the document should put emphasis on "Proposal". Otherwise it is confusing to understand what is proposed, and what is the actual DORA 2.0 Or maybe it is confusing anyways. If I don't understand DORA, the proposal makes it even less clear.

Capabilities --> Performance --> Outcomes

I don't feel it is useful. Again, reminds me very much of any religion. For DevOps I would rather rather inverse the flow. Start with negative Outcomes then an arrow to measure --> Performance to debug issue and grow --> Capabilities to then again measure --> Outcomes. That's would be a good DevOps'ey feedback loop.

When drawing this feedback loop diagram, I would draw a circle for each box, and allow highlighting of problematic areas in red, so that the flow can be traced visually, and people could see some specific problem by concentration on one pathway at a time. I am not in the mood/position to draw it, but I hope you understand.

Detailed switch

I guess we don't have UX/UI people here, otherwise I would be interested to hear their professional opinion on this. :D

Everything else

If not mentioned then it is probably good. :D

[davidstanke]

Thanks for the feedback!

[kasiazazaza]

Pros

• simplifying the capabilities space - both in collapsed and detailed view, I actually like both visuals too. in V2 it's clear and easy to grasp. While the current live version is confusing with the main frame being Technical Capabilities, but then to items above predeceasing them and then 4 more coming after (are they a synthesis, or fore more items) but only two related to the main frame.
• a lot clearer item: deleting “Trunk-based development” (~replaced with Working in Small Batches)
• making a data driven decision on the arrows

Moreover, in our research, we’ve seen that the locations and magnitude of those effects varies throughout the years, so it’s difficult to pin down a canonical set of pathways.

Cons

• one thing I'm still lacking is: If metrics happen on a node of PERFORMANCE and they predict the OUTCOMES why are CAPABILITIES given the most attention (explained in the most detail) and why should (as a reader) care? When in stead all the measuring is indicated in "performance" I can capture the key metrics, rust it predicts organisation results and employee wellbeing and be done with it?

[davidstanke]

why are CAPABILITIES given the most attention

It's true that as you move from the left to the right (which corresponds to a flow of time -- from causes to effects), the visualization gets simpler. The outcomes on the right are the most important thing, and they're hard to achieve, but they're easy to describe: we want to be successful! Meanwhile, the left side represents the messy variety of behaviors, tools, and culture across the spectrum of diverse team contexts. So each team needs to find its own opportunities within the space of capabilities, which will help them deliver value according to a shared [within their organization] definition of success. This means that, yes, there's more stuff on the left than the right. However, I'd say that in the context of a group of people where this model is being applied, there's typically no shortage of attention given to the right side. Every organization wants success, and every organization should [IMHO!] want well-being. The question is how? And so this model helps to augment our intrinsic ends-based narratives with a framework for discovering the means to those ends.

[heimarvegaeci]

Hi, thanks for this update, some comments related to this.

I consider that some metrics could also be updated in each of the capabilities, something that I consider is needed

Capabilities or practices related to AI could be included, something that was mentioned a lot in the last DevOps days Medellín participated in

I gave a talk at this event about DevEx and SPACE as frameworks related to developer experience and productivity, I would like us to be able to include capabilities related to these topics since it is gaining a lot of strength.

[heimarvega]

Hi, thanks for this update, some comments related to this.

I consider that some metrics could also be updated in each of the capabilities, something that I consider is needed

Capabilities or practices related to AI could be included, something that was mentioned a lot in the last DevOps days Medellín participated in

I gave a talk at this event about DevEx and SPACE as frameworks related to developer experience and productivity, I would like us to be able to include capabilities related to these topics since it is gaining a lot of strength.

[davidstanke]

Thanks for the feedback! Agreed, AI is a very interesting topic, and it's one that we're actively researching right now. As per the rules for inclusion in the Core model, we haven't established enough research on AI to incorporate it into the model. More research is needed! And so, our 2024 survey includes several questions related to the use of AI in software development. You can help us learn about it! Visit dora.dev/survey and take 15 minutes to reflect on your experience on topics including AI, organizational culture, and more. We'll be publishing our findings later this year.

[stevemcghee]

I like it!

…

On Fri, Jun 7, 2024 at 15:00 Dave Stanke ***@***.***> wrote: image.png (view on web) <https://github.com/dora-team/dora.dev/assets/2166159/ddb50ffb-cbc4-477b-b8d3-8a3ee22b46cc> — Reply to this email directly, view it on GitHub <#582 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAERACM5F33V5L6R74PADYDZGIURTAVCNFSM6AAAAABGVWLHMWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMBXHA2TS> . You are receiving this because you commented.Message ID: <dora-team/dora. ***@***.***>

[davidstanke]

Work in progress (this page is visible only in draft/preview environments): https://doradotdev-staging--pr636-drafts-on-z7vjgsxg.web.app/core-v2/

EDIT: this is now available on prod (but unlinked): https://dora.dev/core-v2/

[davidstanke]

@steve-fenton-octopus Yes. Totes yes. But! The challenge is that, in order to have smooth animations via css transitions, both the start and end sizes must be specified (so we can't use height:auto). That makes everything a little more tricksy than I'd like. However, as an artifact, it's more important that it's readable and useable (in either state) than that the transition is smooth like butter. I think I was able to find a decent compromise[1], after much (probably too much) reimplementation. It's staged here. I'd love to hear your thoughts and further suggestions!

[1] instead of having each capability expand out from a zero-size element, the capabilities are always full-size (auto-sized in the grid). They're wrapped in a container [with overflow:hidden], and it's that container which starts at zero-size and expands in the transition.

[abitrolly]

@davidstanke to make it readable and useable reusable, I would implement it in https://observablehq.com/framework/ (if I was on a payroll (to answer non-existing "why "would"?" question)).

I don't have much experience with it. It is just an assumption that using good data visualization framework from people/person who've made D3.js a thing, is a much better solution both for collaboration and for animation/visual design, than dealing with plain HTML5 shenanigans.

[davidstanke]

Thanks for the recommendation! I'll take a look.

[black-snow]

@davidstanke weird things happen on staging when you have a detail dialogue / pop-up open and hit ESC ;)

[davidstanke]

Eek! That's a really insistent pop-up! Thanks for letting me know -- will fix!

[Winael]

I really love it :) I have a question now. Will the quickcheck be updated with question about reliability too ? Regards Le sam. 8 juin 2024, 01:03, Dave Stanke ***@***.***> a écrit :

…

Work in progress (this page is visible only in draft/preview environments): https://doradotdev-staging--pr636-drafts-on-z7vjgsxg.web.app/core-v2/ — Reply to this email directly, view it on GitHub <#582 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLB6GKYHESXDV44IVDTC2LZGI32JAVCNFSM6AAAAABGVWLHMWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMBYGI4TC> . You are receiving this because you commented.Message ID: <dora-team/dora. ***@***.***>

[davidstanke]

Glad you like it! As of now, we don't have plans to expand the quick check to include reliability (though we should consider it!). Meanwhile, if you're interested in asking more or different questions, you're welcome to make a survey using some of these.

[matthewskelton]

Any plans to move away from the "DORA" acronym? For many of us working with financial institutions, "DORA" now means the EU Digital Operational Resilience Act. We've had some very confused discussions with people at EU and UK banks :)

[black-snow]

Moving away from DORA would sure be confusing for me :D

[steve-fenton-octopus]

We've dealt with confusion before. We can do it again!

[nathenharvey]

I'm more inclined to "de-acronym" DORA than to move away from it entirely. Though that discussion is likely better in a different forum.

[abitrolly]

Google explained it to me. :D DORA is DORA, but EUDORA has dates.

[davidstanke]

A huge thank you to everyone who participated in this process! With your input, a lot has changed over the past couple months, and we've now arrived at something I feel very proud of. We weren't able to respond to every suggestion, but I'm hopeful that everyone who participated in the process can share my excitement about the launch of Core V2! As of today, it's live at https://dora.dev/research/ -- please share, discuss, and continue to offer feedback (either by posting here or opening issues in the dora.dev repo).

[black-snow]

Awesome! Congratz.

[gunta]

I noticed DORA v2 is quite similar to DX's DX25.

Can we have some background / comparison to highlight the differences between both?

[nathenharvey]

Imitation is the sincerest form of flattery and our friends at DX may have taken some inspiration from the design of DORA core as they built out their DX25. Both DX and DORA are meant to help teams improve the way technology-driven teams drive great outcomes and improve well-being so it's encouraging to see similar findings and advice from both teams.

[gunta]

@nathenharvey Thanks! Having trouble to decide between both for our organization, so it would be amazing to see an in depth comparison (or even merge) at some point :)

[Winael]

Hi everyone First, Congrats to DORA Team with the release of DORA Core V2, and welcome to the "new" capabilities (loosely coupled Teams, Pervasive Security, etc). All I have to do now is update my training materials. I noticed that Resilience Engineering haven't got its page yet, but I assume it will land very quickly Big thank you to everyone who worked on it. @Gunther, I've just had a look at the DX 25 model and even the shape is very similar to DORA. Thanks for sharing this framework, as an Agile Coach, I'm sure I'll find some things to discover in it. Cheers, Winael

…

On Thu, Jul 11, 2024 at 10:37 AM Gunther Brunner ***@***.***> wrote: I noticed DORA v2 is quite similar to DX's DX25 <https://getdx.com/research/dx25/>. Can we have some background / comparison to highlight the differences between both? — Reply to this email directly, view it on GitHub <#582 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLB6GJWZKBKFQ74HRRQO5DZLY725AVCNFSM6AAAAABGVWLHMWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBRHA2TENQ> . You are receiving this because you commented.Message ID: <dora-team/dora. ***@***.***>

-- Vincent JOBARD http://aliaz.com/winael

[davidstanke]

Check out @steve-fenton-octopus's LinkedIn post for additional discussion of Core V2, along with an absolutely amazing image of Steve's beautiful mind as he unravels the hidden mysteries of software delivery: https://www.linkedin.com/posts/stevefenton_when-you-look-at-the-models-from-devops-research-activity-7217076249603559425-cKfB