Software process improvement and the CMMI

The thinking move: improve the process you have, at the level you are at

Process improvement fails most often not because the target process was wrong but because it was the wrong distance away. A team that cannot reliably manage its requirements will not be rescued by statistical process control; it will be buried by it. The judgement that examiners reward is the ability to say where an organisation currently is, what the next rung actually offers, and what adopting a rung two above would cost.

SPI and its process

Software process improvement (SPI) is a deliberate, assessed effort to make an organisation's software process more capable, applied iteratively rather than once. Pressman's road map has five activities and each is a common-sense instruction: assessment and gap analysis (look in the mirror — you cannot improve a process you have not honestly characterised), education and training (get smarter, so the next choice is an informed one), selection and justification (choose the process model and technology elements that fit this organisation, and be able to defend the choice financially), installation and migration (instantiate the choice into the real operating environment and culture, which is where most SPI dies), and evaluation (measure what actually changed). The cycle repeats. SPI has its own risks and needs its own risk management, and it must show a realistic return on investment — fewer delivered defects, less rework, lower maintenance cost, faster time to market — or it will not be funded twice.

Maturity models and the CMMI

A maturity model provides an overall indication of the process maturity an organisation exhibits — the quality of its process, how well practitioners understand and apply it, and the general state of its practice — on an ordinal scale. Its value is that it gives an easily understood snapshot to benchmark improvement against, not that a level number is intrinsically meaningful.

The Capability Maturity Model Integration (CMMI) is the best-known example, expressed both as a continuous model, which rates capability separately for each process area, and as a staged model, which rates the organisation as a whole. The five levels, in order and by name: initial — ad hoc, results depend on individuals; managed — work is planned, monitored, controlled and reviewed against a policy, with adequate resources and involved stakeholders; defined — the process is tailored from the organisation's standard process set and feeds work products and measures back into organisational assets; quantitatively managed — the process is controlled using measurement, with quantitative objectives for quality and performance used as management criteria; and optimizing — the process is adapted and improved by quantitative means to meet changing needs. Two facts are examinable on their own: level 4 is the level where statistics enter, and level 5 is continuous improvement, not perfection.

SPI is most effective when aimed at the umbrella activities, because they are the most stable part of any process — measurement, configuration management, quality assurance and risk management look much the same whatever model a project uses, so improving them pays off across every project rather than one.

Worked example — BorrowBox at level 1, and the two-rung rule

The five-person BorrowBox team is honestly at level 1. Releases happen because two people stay late; there is no written policy, and whether a change gets reviewed depends on who made it. An assessment and gap analysis would find three concrete gaps: requirements arrive as chat messages and are never baselined, configuration management exists only as a source repository, and nothing is measured except the release date.

The useful move is level 2, and specifically its most stable practices: requirements management, configuration management, and measurement and analysis. Those three are exactly the umbrella activities, they are cheap for five people, and each has a visible payoff — a requirements baseline stops the silent scope drift that made release 2 late, and the four telemetry metrics chosen in the last lesson cost nothing to keep.

What the team should explicitly refuse is level 4. Statistical control of a process needs enough repetitions to have a distribution, and a five-person team shipping three releases a year does not have one; adopting it would produce ceremony that consumes the capacity the improvement was meant to release. Saying "if a specific SPI approach feels like overkill for your organisation, it probably is" out loud is not a cop-out — it is the judgement the question is testing.