The Maturity Sequence

From my point of view the meta-philosophy of agile is iterative development and relies on the definition of capability and maturity provided by the Carnegie Mellon Capability Maturity Model. Scrum and Kanban provide a workshop full of tools and we choose certain ceremonies, processes and guidelines as our tools for building a workflow that fits the problem domain and specific problem.

This model has five levels of maturity and capability. Successful software can be made at any level, but it's more likely with a more mature software process. What I personally add to this is the concept that the level a software project should have is related to it's actual maturity. In other words, one is not seeking maximum maturity day on, that's developed iteratively. Less mature levels are appropriate for less mature code. We apply our full set of practices incrementally, over time.

The levels are as follows:

1. Initial - Otherwise known as heroic, where problems are daringly resolved, hopefully, through long hour antics and fire fighting incidents. A mature system should not be at level one, but a research or demonstration project may be.
2. Repeatable - The programmer's practices, such as installing software or giving a demonstration, are repeatable. This implies some notes and instructions, especially assuming repeatability by a team. However, some things are still only in the brains of the engineers working on the system. Some practices are ad hoc, the way a particular team naturally interacts, and will not translate forward easily as the team grows or transitions.
3. Defined - The repeatable processes are fully defined. In this day and age this definition is used to automate repeatable processes as through CI/CD, but also processes like sprints, right-sizing them, team size, creation, and breadth.
4. Capable - At this level there are metrics for the repeatability of all processes, from technical things like system deployment in the cloud, point capacity per sprint, and any other sprint metrics. This allows the team to accurately say how long a particular project will take and accurately schedule it in calendar time.
5. Efficient - All systems are continually refined according to metrics. These metrics will also be continually refined in terms of end results, like the popularity of the system with users, or costs. The metrics themselves thus become a focus of refinement as they now can drive the rest of the development process, but cannot be relied on forever. Over time the limitations of some metrics become clear, or the terrain changes requiring different metrics.

When starting a project, level 1 and 2 can come more or less simultaneously by documenting things, always... in other words by keeping notes and publishing them.  Comments in code can be the first notes, then that can be moved to READMEs, then also to wiki's and other document repos. When installing a system, always make notes, even the most crappy notes, so that next time you can read them. Seeing what they lack creates a better next draft. After a few times the instructions for the repeated activity will be complete. If the process is inherently complex, making the notes and documentation complex, this indicates that you should change the system to make it easier to document.

This initial level is appropriate to proof of concept, prototypes, initial development for libraries and tools, done by a single person. Level two projects emerge as projects are shared with other developers, the notes published, and the system can be reliably deployed and developed.

Level 3 should exist no later than the beginning of a team development effort, especially since we have tools such as kanban issue systems, sprint workflow tools, and the like, and what such tools provide is specifically level 3 definition. They are places to execute the defined actions, guiding all improvements and problem solving effort.

The fact is, a functional application, such as an internal tool or small site, can operate sustainably at level 3, but will falter when a major problem arises, which it eventually will. But some organizations will prefer to wait until that time, and then do a spike, and rebuild their system, and that effort can succeed at level 3 b/c of the freedom to just write new code and abandon old.

Serious software and enterprise software (even smaller scale) must operate at Level 4. Without the measuring, when the "major problem" arises mission critical software failure is likely, and at scale this cannot be solved with a spike in a reasonable time period, and the system is too complex to rewrite greenfield, and there would be no way to measure the results of the new effort in comparison to the last. Level 4 must be in place long before its needed.

If at Level 4, you should absolutely begin to act at Level 5. The metrics are there for you to have a basis against which to improve, or measure degradation as the software increases in capability. Ultimately there is little reason to have metrics unless you use them, and if you don't improve the metrics themselves, your gaze is fixed and isn't taking into account the changing environment which leads to the major problems we are trying to avoid.

Thanks for reading.