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.
Methodologies are used to reach specific objectives in an efficient manner. In the same mindset of Quality Engineering, the goal is to quickly deliver a valuable deliverable. One essential quality contribution of methods is therefore to bring that focus and result-orientation to the team.
Actors with different backgrounds, interactions and individual priorities will tend to shift their attention from the common goal of Quality at Speed software. A software engineer will optimize code during hours even if the product owner asks to remove it in the next sprint as not used by customers.
Methodologies like Objective Key Results (OKR) focus the team on achieving common objectives with explicit results in a defined timeframe. The Definition of Done (DoD) and Definition of Ready (DoR) also contributes to Quality by ensuring specific results are delivered each time, systematically.
Humans are not robots. Even if with training they can master a set of tasks with a very low rate of errors, the probability is still there. And software requiring the collaboration of various actors of different backgrounds and levels, the error-prone probability is exponentially increasing.
Systematic approaches like checklists or processes drastically improve the quality of the execution. Actors within different teams can collaborate better even with varying maturity levels following a set of repeatable standards. Additionally, it facilitates switching members and scaling practices.
A set of systematic practices has been emerging in the software industry. Some of them from the Agile world like the Scrum framework with Sprint Planning and Sprint Retrospective. For a day-to-day application, the previously mentioned Definition of Done are Definition of Ready are equally useful.
A high-performing cross-functional team directly contributes to Quality in an organization. The challenge is that organizations possess multiple teams that must reach the high-standard of software quality to deliver Quality at Speed software on the different parts of the product.
Being systematic and result-oriented, methodologies force the formalization of processes. When the organization grows, it can capitalize on its best-practices, solving similar problems in a coherent way. Combined, methods help to capture both economies of scale and equally important of speed.
OKR, Definition of Done, Definition of Ready are all methodologies that can rapidly be replicated in different software teams. Other methods along the software lifecycle follow the same logic. That’s the case of peer review (requirements, architecture, code, …), sprint planning, retrospective, etc.
How do Methods contribute to Speed
The perception of Speed in Quality Engineering requires the right perspective. If we consider the short-term from an individual perspective, just doing the work fast alone is the best way to do it. But delivering Quality at Speed software requires the speed of collaboration in the mid to long-term.
The focus of methodologies shortens the time to solve a particular problem, channels the energy of the actors and limit rework. Using such frameworks also gives a rhythm to the team, essential to keep iterating at speed. The step-by-step clarity also facilitates asynchronous collaboration and visibility.
Similarly to the result-orientation, actors without a common objective will tend to work on their local priorities, shifting their attention from Quality at Speed software. Methodologies explicit goals to achieve in an efficient manner, shortening the time to perform the necessary activities.
Defined frameworks provide a ready-to-go structure to stop reinventing the wheel. Like a scientific study presenting its results in a book, the actors can directly use the actionable principles without doing the entire study. Additionally, the familiarity of methods accelerates collaboration.
Let’s take the example of OKR combined with a Kanban, or Scrumban. The OKR defines the key priorities to work on and contributes to move items out of the scope. The Kanban or Scrumban then limit the work in progress to deliver as fast as possible the expected deliverables, with focus.
Activities without milestones or regular reviews fall apart (think about new year resolutions, sport habits, or a last meeting where a “key priority” is already forgotten a week after). Giving a rhythm in software enables to keep the actors’ energy funneled to build and deliver Quality at Speed software.
Methodologies give the rhythm with shared rituals and a clear sequence of activities. By collaborating at the same pace, the actors have shared milestones to be reached regularly. Over-time, the requirement for continuous iterations becomes part of the culture, supporting the speed.
The majority of software teams work in time-boxed sprints. The value of such a method is to identify milestones achievable in a shorter time frame, reduce the work-in-progress, and avoid working on nice-to-have features. The actors are constrained by the methods to deliver Quality at Speed on time.
We cannot produce anything if we are always synchronizing with the team. This “death-by-meeting” syndrome is common for teams that fail to work asynchronously. Their common trait is to be very slow, failing to deliver Quality at Speed software. And remote work only increased that challenge.
Methods that are well understood, documented and shared enable an organization to expand much more quickly its best practices. As organizations relying on methodologies are able to follow up with the company’s growth by sharing asynchronously while keeping their alignment.
Asynchronous methods can be architecture principles or Merge Requests. This last one enables software engineers to review code in a short time-frame at their own convenience. It is much easier than planning a regular meeting that will not be needed half the time, and will be much faster.
Our context of digitalization has low predictability and is the reality we have to adapt to. The challenge of rapidly changing plans is to identify the impacts beforehand to avoid making things worse or create another set of problems. That’s where the visibility of methods help to react faster.
Methods provide the full picture of steps to follow. This step-by-step visibility enables them to identify which actions are still remaining when the team is already in the execution. We can directly visualize what is remaining, not losing sight of the possible impacts of the changes we had in mind.
For example, if all the tasks are correctly boxed within a Sprint with a limited work in progress, you can clarify that items must be removed if a new one has to enter. Plus, you also have the view of the upcoming backlog with new features, improvements and technical debt items you can impact.
The Methods of Quality Engineering for Quality at Speed software
Methodologies are one the five essential pillars of Quality Engineering. Like for a chef or a doctor, even the highest level of technical expertise will lack impact without methodologies. Methods are therefore critical to success in a software life cycle full of challenges and evolution.
More content on the paradigm of Quality Engineering, its principles and framework is available in the ebook dedicated to that theme. Find the full perspective of Quality Engineering in On Defining Quality Engineering: Thrive your business with Quality at Speed software.
It is one thing to be convinced by the necessity of methods for Quality at Speed. Another one is implementing them within an organization to make the difference. And there are so many choices that one can get lost in what to do. That’s why we worked at defining the first step you can take.