How about creating a definition of your engineering approach to share good practice & enable engineer collaboration (using Kotter and also an anti-fragile approach to knowledge - encourage challenge). The business customer needs us to be responsive, disruptive, reliable and professional - call it an "iron square" of the industry today. Our engineers need to be able to tap into knowledge & support networks instantly. This is important for any engineering department in a large company - do you know what your value-proposition is?
Engineering also have significant Cloud Challenges - microServices, polyglot, emergent architecture, 12 factor, Cloud First, build to scale..etc... Things are moving fast.
The LIT.method is our approach (which can be replicated) and we have been inspired by some of the HSD & Cynefin approaches to balance alignment and autonomy. The perfect pull system for a 500+ person organization.
The grass-roots Roll-out was via openSpace, lean coffee & conversation. We made a conscious decision to flip top-down comms and practice radical transparency.
FINAL STATEWe build for end-Customer Impact & align with the internal-Customer, but need to retain XP discipline - Customer focus & collaboration is everything. We decided to make it real and share real experience, not theory or abstracts (with a solid system of principles as a foundation). We found that working engineers don't need high-brow principles or theory, just techniques and experience they can use today. The LIT.method() is the way we have accelerated collaboration with a clear goal of "internal-customer" satisfaction (via a high standard of engineering).
We did not use any scaling frameworks (but we inter-operate with several), we have real business on the line so have been very pragmatic, we are presenting real results, metrics & experiences. We have used Hypothesis & Product thinking to inform our approach (which has taken many turns).
