Why bother with methods for software?
A method is the quality of being well organized and systematic in thought or action in the Oxford dictionary. I confirm that I have seen many attempts to build and deliver software without methods: it failed miserably most of the time, with an enormous waste and debt when eventually delivered.
We usually see a back and forth in organization on methodologies. Some are added after failures to be systematically followed (or you are fired). But a few months later, as they are time-consuming and slowing down some projects, the team goes for a “leaner” approach. Until they fail again.
There is nothing wrong in adapting practices to the organization priorities and maturity. The issues lie in the time lost between the switches and in the waste accumulated from poor software delivery. The objective is to equilibrate the use of methods to constrain the software lifecycle to Quality at Speed.
This continuous force is precisely the Quality Engineering paradigm. It relies on the Quality Engineering Framework, MAMOS, with the five domains of Methods, Architecture, Management, Organization, and Skills. This article focuses on how the Methods contribute to Quality and Speed.
