Our experience in helping organizations implement frameworks and maturity models (TMMi, CMMI) has been nothing short of positive. Maturity models are useful devices to guide understanding for a large, organized group of professionals working together. So, what about using maturity levels within a SAFe implementation? Why? In order to help different release trains (groups of people) be incentivized to improve.
On the surface, this seems reasonable and the intention sincere. However, the maturity level designation is inappropriate for the scaled Agile environment. A maturity level is a static point in time. It is a declaration of compliance or conformity. Conformity is not a core Agile value, adaptability to purpose is, which is about getting work done as fast as possible within immediate, observable timeframes.
Now the intention to provide incentives to improve is commendable. Retrospectives built into the process (within Agile and SAFe) are designed to accomplish that. Immediate impediments are addressed on a short horizon. Enterprise-level obstacles are identified but may take some time to address. Having an appraisal, inspecting artifacts and declaring an achievement of compliance does not add value. Again, in the SAFe environment, maturity level compliance is incongruous.
Incentives, in Agile, can be tied to many things. In SAFe, tying them to value delivered ultimately respects the organizing principle of the Value Stream, elemental to SAFe. Creating and publishing value delivery metrics on a per-release-train basis calls back to factory production lines. Positive peer pressure works. It’s a core principle at the team level and it is scalable.
Designing the right value delivery metrics, that not only incentivize, but also inform the organization as to throughput, capability and potential issues is a worthy internal discussion to have. What do you think?