Large organizations who move towards and Agile delivery model may struggle with how to scale any governance model.
I think if you polled most Agilists about governance in general, you would tend to get a shutter and an ugly stare. Indeed we want to address technical excellence during our sprints but what we often fail to understand is that software engineers are not omniscient when it comes to all of the areas of technical acumen related to performance, security and other compliance type efforts.
As an organization grows and becomes more and more global it finds itself dealing with many different governing bodies that each have different requirements for how we deal with data protection, which in turn relates to how we develop our software.
Having run PCI compliance for a large organization I know first hand that providing specific information to developers with respect to what to look for just in a code review is an important first step.
Governance is needed for most organizations as a first defense when something happens with respect to security/privacy. Organizations need processes in place to provide evidence to governing bodies, courts and legal inquires regarding how we protect our product our customers information.
Governance can include both standards and artifacts. For example PCI compliance requires that we provide evidence of compliance with respect to their 13 security requirements. From a software development standpoint these include such activities as code reviews that are focused on security, software development cycle, evidence of secure development and test practices in addition other efforts such as Penetration testing and other monitoring capabilities.
In Agile we need to think of this in a light weight manner. At one organization we implemented a set of standardized stories, non-functional, that were to be included into a teams feature development sprints. For teams that are working on several sprint efforts before going into production this can work very well as the team is addressing this as part of the planning and estimation. When the code is delivered to production the completed and accepted user stories (which have context as to what was completed) serve as the artifact for the PCI compliance (or other) auditors.
The engineers liked this because they were creating artifacts as they developed and from an organization standpoint we gained confidence in the fact that our code was being developed against high quality standards.
For Governance activities that relate to more ongoing product sustainment efforts the same standards need to apply however the manner in which we apply them within each sprint may be different that new product type efforts. Automated testing and monitoring form a larger basis of maintaining the standard levels that we established in earlier cycles.
Recently I heard a statistic that said 90% of attacks can be mitigated by the basic block and tackle work that teams can do on a regular basis.
Governance doesn't have to be a bad name in the Agile space, we need to view it as part of our technical excellence efforts that form the basis of high performing Agile teams.
I think Governance is an area in Agile that is ripe for development especially at scale.