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.
Follow the QE Unit for more exclusive Quality Engineering from the community.
How do Methods contribute to Quality
Crafting software is the consequence of a cross-functional collaboration. Their focus, perception and priorities directly impact what matters for them, and what will be built in the team. Increasing the value they can deliver does not require more software, it requires a high-standard organization.
A team efficiently leveraging methodologies improve its contribution to Quality by meeting the expected milestones and results. Over-time, such teams will incorporate methods as part of their daily process, building up a set of systematic practices, accelerating value delivery that can scale later on.