Vielen Dank für deine ausführlichen Ergänzungen! Je besser dieses „owning“ passiert desto Verantwortlicher werden die Teams und desto besser wird die Qualität. Dennoch tun sich große Organisationen mit diesem scheinbaren Kontrollverlust sehr schwer.

Ja!

Das ist genau auch meine langjährige Erfahrung aus agilen Organisationen, dass es so funktioniert, dass so auch Ownership an den Standards entsteht: Menschen aus verschiedenen Teams oder eben eine Community of Practice setzt sich zusammen und schreibt den ersten Entwurf der Standards, ob das jetzt z.B. eine Coding Guideline ist, oder eine grundlegende Definition of Done für alle Teams und Produkte. Dann wenden alle diese Guideline an, und von Zeit zu Zeit werden neue Erkenntnisse diskutiert, aufgenommen, und wieder in den Teams verbreitet.

Was ich auch schon erlebt habe:

Wenn Entwickler sich weigern, miteinander Standards zu setzen, dann geschieht das, wenn sie keine Spielräume in der Organisation haben, diese auch umzusetzen. Wenn sie beispielsweise bestimmte Arten von Testautomatisierung für wichtig halten, aber keine Zeit bekommen, um sie auch zu implementieren, weil sie das „wie“ nicht wirklich in der Hand haben.

Das Thema deines Artikels geht natürlich noch weit über solche entwicklungsinternen Standards hinaus. Es geht ja um Governance, Risiko und Compliance-Prozesse, die auch in vielen Firmen, wo sich die Entwicklung oder IT für relativ agil/lean hält, noch bei ganz zentralen Einheiten liegen. Da ist es besonders wichtig, dass Themen wie IT-Sicherheit, Datenschutz usw. Teil des agilen Prozesses und Teil der Verantwortung der Produktteams werden, und die zentralen Einheiten sie nur dabei unterstützen, die Anforderungen zu verstehen. Wenn sie dagegen detailliert das „Wie“ der Umsatzung vorschreiben, kostet das oft Monate auf der Timeline, ohne dass dadurch bereits neueste technische Erkenntnisse oder Lösungen zu dem Thema eingeflossen wären.