{"id":1863,"date":"2026-11-03T05:50:00","date_gmt":"2026-11-03T05:50:00","guid":{"rendered":"https:\/\/devopsschool.org\/blog\/maturity-assessment-methods-compared\/"},"modified":"2026-11-03T05:50:00","modified_gmt":"2026-11-03T05:50:00","slug":"maturity-assessment-methods-compared","status":"publish","type":"post","link":"https:\/\/devopsschool.org\/blog\/maturity-assessment-methods-compared\/","title":{"rendered":"Three Ways to Assess Delivery Maturity, Compared Honestly"},"content":{"rendered":"

Sooner or later every engineering organisation asks the same question: how mature is our delivery practice, really? There are three serious ways to answer a maturity assessment question, and they produce very different artifacts at very different costs. This comparison sets the self-run review, the external expert audit, and the platform-based periodic assessment side by side \u2014 on rigour, repeatability, cost, speed, and what each one does to a team’s behaviour \u2014 so you can match the method to your situation rather than to a vendor’s pitch. For learners and certification candidates, there is a career dimension too, covered at the end.<\/p>\n

The three contenders, defined<\/h2>\n

Method A \u2014 the self-run review.<\/strong> The team writes its own questions (or borrows a public model), scores itself in a workshop, and produces a findings document. Cost: a day or two of team time. Owner: usually a lead or engineering manager.<\/p>\n

Method B \u2014 the external expert audit.<\/strong> Specialists spend days or weeks inside your organisation, interview people, inspect systems, and deliver a bespoke report with recommendations. Cost: consulting rates. Owner: whoever signed the engagement.<\/p>\n

Method C \u2014 the platform-based periodic assessment.<\/strong> A standing instrument administered through software on a schedule. The reference example is SCMGalaxy OS, the governance platform from training-and-consulting company SCMGalaxy<\/a>: one hundred fixed questions spanning the delivery lifecycle, scores engineered to be identical for identical answers, prioritised findings, improvement plans staged at 30, 90 and 180 days, and built-in re-assessment. Cost: it opens with a free sitting; the real investment is the remediation work between sittings.<\/p>\n

Round 1: Rigour of the findings<\/h2>\n

Method B wins on depth per finding. A good external auditor notices what no questionnaire asks \u2014 the political reason a deployment gate gets bypassed, the tribal workaround nobody thinks to mention. Method C wins on coverage: a hundred-question instrument refuses to skip the dull areas, and dull areas are where risk compounds. Method A loses this round structurally, not through laziness: teams writing their own questions unconsciously write ones they pass. The practice of grading how code moves through review before it merges, for instance, appears in every serious external instrument and almost no self-written one \u2014 because every team believes its review culture is fine.<\/p>\n

Round 2: Repeatability<\/h2>\n

This round is not close. Method C exists because of it: deterministic scoring means the June sitting and the January sitting differ only by what the organisation changed, which is the entire analytic value of measuring twice. Method B is weakly repeatable \u2014 hire the same firm twice and you still get different consultants, different emphases, different prose. Method A sits between: a frozen self-instrument can be repeatable in principle, but in practice teams tinker with their questions every cycle, quietly severing the trend line. If your goal is benchmarking \u2014 against your own past, or across teams \u2014 repeatability is disqualifying, and only one method has it by construction.<\/p>\n

Round 3: Cost and speed<\/h2>\n

Method A is nearly free and done in a week. Method C costs little to begin and returns a scored baseline in days. Method B costs the most and takes the longest \u2014 justified when the question is genuinely bespoke (an acquisition’s due diligence, a regulated migration), wasteful when the question is the ordinary “where do we stand and what should we fix first”, which a standardised instrument answers for a fraction of the price. A pragmatic reading: B is a scalpel; buying it for a routine check-up is paying surgical rates for a thermometer.<\/p>\n

Round 4: What each method does to behaviour<\/h2>\n

The underrated round. Method A builds reflection habits but invites self-flattery; without an external scale, scores drift upward as morale demands. Method B creates a flurry of post-report energy that decays once the consultants leave \u2014 the report belongs to the sponsor, not the team. Method C changes behaviour through the booked re-sit: teams that know the same hundred questions return in six months start maintaining evidence continuously \u2014 rehearsing restores, keeping review stats \u2014 because the next sitting will ask. The instrument becomes a quiet standing incentive, which no one-off method replicates.<\/p>\n

Round 5: Ownership of the result<\/h2>\n

Who holds the artifact when the exercise ends determines whether anything happens next. Method B’s report is addressed to leadership; teams experience it as something done to them, and remediation becomes a compliance chore. Method A’s findings belong entirely to the team \u2014 maximum buy-in, minimum authority, so items die the moment a deadline looms. Method C splits ownership usefully: the instrument and trend data sit at organisational level (platforms arrange assessments into workspaces and projects precisely so multiple teams can be tracked without sharing spreadsheets), while each team owns its own scores and its own staged plan. That split is what lets a head of engineering compare trajectories without flattening every team onto one defensive average.<\/p>\n

The verdict, by situation<\/h2>\n