The rest of the enterprise, especially departments who are responsible for creating processes that everyone must follow

they are just going to say that they need to run this new scanning process for all apps

Assuming that scanning is indeed a necessary condition of Done for all apps, why must they be the ones to do it?

I have to agree with Ian.

Back to your issue Steve: often times your only option is to make the consequences of such constraints transparent.

I like to use a Lean A3 Problem Solving sheet with a cause and effect diagram as 'supporting evidence'.

I have a different view.

Do you mean the "scanning process" refers to the "Code Scan"?

Do you make "deliver" and "release" the same thing?

Do you know the relationship between QA and QC?

Release planning and release preparation are not within the scope of Scrum. 

Perform related QC work such as Code Scan prior to release or deployment, the purpose is to conduct the audit of the final inspection.

For example, one of my Agile teams just told me that they won't be able to deliver next week because our Information Security department just created a new scanning process that has a 3 week lead time.

I'm not as experienced as others (Ian for instance), and to my mind, if work's done in accordance with your team's DoD, and is potentially releasable, then all good. But, in line of what Ian pointed out, how about updating the team's DoD to make it more strict so to speak and include scanning (code, vulnerability, whatever) in it, and have scanning performed within the sprint itself?

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”

they are just going to say that they need to run this new scanning process for all apps

Assuming that scanning is indeed a necessary condition of Done for all apps, why must they be the ones to do it?

@Ian, I thought the DoD is a team concept. Why would something external - other Scrum teams, other departments - impact a Scrum team's work and determine whether it's done or not when each team sets up its own DoD or follows the company's guidelines?  

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

So far I've never experienced a scenario where the increment is Done per team's Done, however it's not really Done because there's a review/approval process elsewhere in the org - hence my confusions. Could you please clarify, Ian?

 I thought the DoD is a team concept. Why would something external - other Scrum teams, other departments - impact a Scrum team's work and determine whether it's done or not when each team sets up its own DoD or follows the company's guidelines?

Each team must be able to satisfy the Definition of Done for the product they are working on, and that definition ought to be of release quality.

In the situation being considered, it appears that scanning is necessary for work to be of release quality. If so, then scanning ought to be stipulated as a condition of Done and the team should be able to meet it. I’d therefore question why a separate department would run any assocated scans.

@Ian,

This may be picking hairs, but I'd appreciate clarification on a position you are taking in regards to "release quality".

I fully agree that DoD should include an item being of Release Quality.   However, in working with teams, I have drawn a distinction between an item being ready for production, and an organization's ability to actually deploy it.   

Development Teams often do not have full control of the release process, and these procedures are usually a mainstay of past deployment practices.   Ideally, Scrum Teams would benefit from a continuous deployment pipeline, and not be hindered by antiquated and/or manual release processes that serve as toll gates or check points that impede timely release of software.

So, I guess my question is around the interpretation of "Release Quality", and whether a Scrum Team should feel that they cannot meet such an objective until an organization changes their release processes to accommodate a more dynamic deployment practice?

So, I guess my question is around the interpretation of "Release Quality", and whether a Scrum Team should feel that they cannot meet such an objective until an organization changes their release processes to accommodate a more dynamic deployment practice?

The Guide stipulates that "The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint."

Also:

"The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of 'Done'...Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it."

It's very common for teams to be in a position where they cannot meet the standard required for immediate release. They may be constrained by tooling (e.g. weak CI/CD) or by impediments caused by organizational structure or culture (e.g. a release process outside their authorization). The work they do will not then be Done, meaning it cannot be released immediately by the Product Owner. Most critically, empirical process control will not be achieved.

These are impediments to the team's ability to implement Scrum, and the situation ought to be made clear to all stakeholders including management. Transparency may include having the courage to assert "We are not yet a Scrum Team, we will not pretend we are until the deficit for release we have highlighted is closed, and we will limit any commitments we are prepared to make accordingly".

Strictly speaking a Development Team has the right to refuse to do any work if they cannot commit to completing it by the end of the Sprint. No-one can force them to take on what may amount to technical debt.

In practice, few teams feel themselves in a position to be so exacting or forthright. Hence they proceed on best efforts to a standard of Done which includes some sort of deficit for release. But it's important to put transparency over the problem even if it cannot be readily solved, and that means making it clear to all parties that Scrum is not yet being implemented for reasons which have at least been acknowledged and understood.

I already mentioned earlier.

Simply put, this is the difference between QA and QC.

Even through the strict system of lecturers and professional teaching materials, students who have completed the course (releasable) still have to pass the exam (scan, QC) to earn certification.

Okay, so it seems the concept is viewed differently. To my mind, releasable means that it has already passed all "exams" and is production-ready. It may or my not be released - as business (PO) decides, but it's nonetheless ready to be deployed on the production environments. This is how I practice.