In order to improve continuously cross-functional teams are encouraged to expand their Definition of Done constantly. It is true that often in large-scale product development competence requirements, test environment costs and many other restrictions could (in practice) make this expansion at least non-optimal. Many companies have started to solve this problem by adding supporting test teams that are actually xFT subordinate teams. I do not mean that all the testing is done by supporting teams, but for example in mobile network development the investment to have a dedicated e2e radio and core network for every team is not feasible. Still the aim must be that these tests are included in the xFT (and subordinating teams) Definition of Done. That makes it possible to expand DoD and embed more and more tests into xFT cadence. When this is supported by regular (1-2 month) Feature Chartering all the teams have same goals, and in optimal case are able to work daily and hourly with the same SW. This removes the need for handovers and when higher level tests are automated there is real context for scaling the development.
For User Stories there is always defined Acceptance Criteria. If xFT only consists up to functional testing then this criteria might not be wide enough. When we have also the supporting teams and their special competence available in Sprint Planning, we are starting to approach customer acceptance as well. Together with DoD this acceptance criteria should be seen as the main requirement for the User Story (and for the whole sprint in this example). This leads us to acceptance Test Driven Development, aTDD. When full organizational competence and whole development chain is available in planning, we are actually removing organizational impediments towards the flow. And tests are defined and implemented in the beginning of sprint, which leads to situation that they become clear requirements for team´s work. This is supported by the fact that teams have clear goals, they share the same context and most importantly everyone in the organization is working with the highest value adding items. These business-facing acceptance tests must be automated in order to have them available for all teams in the coming sprints and therefore expanding DoD.
Definition of Done and Acceptance Criteria are also possible to implement on feature and release level according to same principles. This gives whole enterprise same process and language and therefore further removes impediments and automatically makes enterprise more Agile. This kind of thinking is often against what has been done previously; long check lists and documented handovers that very often lead to slow development. We believe that it will take years for very large Companies to get into this level, but the rewards are worth trying.
Conclusion is that Agile gives also enterprises the guidance how to scale and how to make whole organization work according to same goals. In order to get this working most of the low-level impediments need to be removed first and when expanding DoD also higher level (organizational) impediment removal follows. Things become visible and organization needs to act in order to improve. This is what counts and will make the difference towards true Agile Enterprise.