Reference Architecture vs. Reference Implementation

In this clip from TriAgile 2019, Mike Cottmeyer is explaining the difference between Reference Architecture and Reference Implementation and why understanding the base patterns of Agility are so important to the success of your Agile Transformation.

Reference Architecture vs. Reference Implementation Transcript

Does anybody in the room believe that you’re supposed to take everything in the SAFe guide and to deploy it in your organization verbatim? No? Right. We all kind of agree it’s designed to be tailored, right? On what principles do you tailor it? Right. Does everybody have a really clear idea of what is non-negotiable versus negotiable when they’re tailoring their methodology? Like what things could you leave out and still have it not work or still have it work? Right? Okay, so when, one of the things that we’ve been distinguishing between quite a bit lately is this idea of what we call reference architecture versus a reference implementation. What we’ve found useful is this idea that there’s a bunch of base patterns that we believe transcend any of the methodologies. You can find them in LeSS, you can find them in SAFe, you can find them in Disciplined, Agile Delivery. In the small, you can find them in Scrum, you can find them in XP.

The reference architecture holds universally. The reference implementation is what is negotiable. So understanding the base patterns that you can’t violate, it’s like a really big deal, right? And so as you think about it, right, so we understand our business case, we understand what levers we want to pull. We’re going to start articulating a strategy for how we get there. The reference architecture is going to help us understand what it is that we’re pointing at. What are we moving towards? Cause here’s another interesting thing. As you move from an early stage Transformation to a late stage Transformation, your methodology’s actually going to change. You’re going to have to do things to manage dependencies early that you won’t necessarily have to do after you start breaking dependencies. So if our reference architecture, if the underlying patterns stay the same, we can start to tailor the methodology without breaking it as we move from higher control to lower control through the course of the Transformation.

Okay? So the reference architecture gives us a guide as to what we are shooting towards. And getting into this whole reference architecture, reference implementation. If you look at like the teaming strategies within a SAFe and the teaming strategies within Large Scale Scrum, or the teaming strategies within Disciplined Agile Delivery, or even in the small with Scrum, you will find that what I said about teams, backlogs, working tested software I think holds true in all of them, right? They have different tools and techniques for how they want you to scale. Large Scale Scrum basically assumes less dependencies. SAFe assumes more dependencies, but I don’t think fully respects all of the dependencies in the ecosystem. So sometimes we’re even going to put in more controls than SAFe recommends. But if you can start to recognize this team’s backlogs, working tests and software pattern dependency management patterns, right?

As you start to improve your ability to form teams, create backlogs, and produce working tested software, often through the progressive elimination of dependencies within the organization, then you can start to deprecate some of the control. And so what you find is that SAFe is often insufficient for highly dependent environments, and it’s actually sometimes too heavy when there’s not a lot of dependencies, right? There are other ways you can do it for less, in the presence of dependencies, or in the absence of dependencies. Okay? So understanding where you’re at on that continuum will absolutely inform your methodology. So the holy grail here, right, is to be able to articulate a strategy for this is how we’re going to form teams and this is how we’re going to govern. And then as we start to break dependencies and reduce organizational dysfunction over time, what controls do we have in place that we can begin to start to deprecate? Okay? So that’s why it’s so important to understand these fundamentals from the theory and approach and to understand what your fundamental reference architecture is because your practices are going to evolve as you improve the system. You want to lighten the practices as you improve your system.