Toyota’s employees can stop manufacturing lines.
The responsibility and costs involved are high, but that’s how teams are empowered to embed quality and fix defects as soon as possible.
Delivering software has similarities with a manufacturing line and can also suffer from defects added by inadvertence during the process.
But rare are the teams that stop the flow.
Quality Engineering “Stop The Line” is a method aiming to empower your teams to fix defects early and at lower costs when issues are not automatically detected.
Follow the QE Unit for more Quality Engineering from the community.
What is Quality Engineering “Stop The Line”
Quality Engineering “Stop The Line” is a methodology allowing team members to raise a blocker in a particular software delivery pipeline from issues they encounter.
The key elements of Quality Engineering “Stop The Line” are to:
- Allow people working on a software pipeline to raise a stop
- The stopper is confirmed if more than 2 people or a sponsor vote for it
- The validation stop of the software delivery lane and allocate resources
- The blocked can be applied to any stage of the life cycle
- A dedicated resolution organization and communication until fixed
- A QE Retrospective is recommended following the exercise.
This methodology is not conceptual; its actionability has a direct impact on the current flow of features, expected dates of delivery and other commitments.
But it’s there for a good reason: ensuring Quality at Speed software.
The practice clarifies the need to ensure quality is injected through the lifecycle, and if it’s not the case or a defect is detected, it must be fixed in priority.
Making this method part of the organizational culture also fosters an environment where the mantra “quality is everyone’s responsibility” becomes concrete.
Quality Engineering “Stop The Line” should not be mixed with incident, problem or crisis management—one of these processes can be used after the blocker but they are different.
Let’s see how it contributes to Quality Engineering
Why use “Stop The Line” in Quality Engineering?
Quality Engineering is the paradigm constraining the entire software lifecycle to continuously deliver valuable software to its users.
Its application relies on MAMOS, the Quality Engineering framework, structured on the five domains of Methods, Architecture, Management, Organization, and Skills.
The implementation leverages progressive and incremental practices to accelerate Quality at Speed software delivery according to the organization’s maturity.
While organizations push for a continuous flow of value delivery powered by Quality Engineering, they need a way to manage quality exceptions.
That’s exactly the reason for Quality Engineering “Stop The Line”.
How does Quality Engineering “Stop The Line” contribute to Quality?
Ensuring the quality requirements of software is a complex task that Quality Engineering helps to organize, but can still fail in the execution.
Similarly to the capability to rollback a failed software change, Quality Engineering “Stop The Line” is a methodology to manage exceptional cases that can happen during implementation.
And like a fire alarm, it must be used with parsimony to keep its full value and legitimacy to the rest of the teams as well as the organization.
Quality Engineering “Stop The Line” contributes to Quality being:
- Result-driven in fixing a major quality issue encountered
- Systematic applicable to all critical problems identified
- Scalable as deployable across the entire organization and teams.
How does Quality Engineering “Stop The Line” contribute to Speed?
Stopping a software delivery lane with an entire set of features in progress can seem like a crazy action delaying an entire flow of value.
But if we step back, the costs of fixing an issue increases by a factor of x10 along the software lifecycle, and can lead to more costly rework, delays and team focus.
That’s why it is important to stick to the principle of fixing problems early, before they become bigger and create a worst situation like a customer or business crisis.
Quality Engineering “Stop The Line” contributes to Speed with:
- Focus in solving a critical problem encountered and raised by the team
- Rhythm in accelerating the resolution and getting the flow back
- Visibility expliciting the importance of quality requirements and responsibility.
How to start with Quality Engineering “Stop The Line” in QE?
Quality Engineering “Stop The Line” can be implemented progressively across the organization starting by the teams working on most valuable software pipelines.
Make sure to share the main guidelines of Quality Engineering “Stop The Line”:
- Anyone can raise a quality issue along the software lifecycle
- Validation is done by 2 team members or 1 sponsor
- Once validated, the issue becomes the only team priority.
You can then implement the methodology using these steps:
- Select the team and pipelines where applicable
- Align with the team and stakeholders the method
- Setup the temporary organization upon validation
- Keep a continuous focus and communication
- Perform a retrospective after the resolution.
Select the team and pipelines where applicable
Deploying a new practice within an organization is best done with an incremental approach to effectively manage the transition.
Select a team meeting the following criteria:
- Software components are of significant value for the company
- The teams is open to new practice and would see benefits
- There is a probability to generate early wins for the pipeline
- The team has one or more ambassadors to capitalize for deployment.
You can even formalize the possibility to use such practice in your referential of applications or incident management tools, with a flag set for the defined scope.
Align with the team and stakeholders the method
The application of the methodology impacts a variety of stakeholders that if not informed and aligned, can generate a whole set of issues for you and the organization.
Rely on the shared definition and principles adding relevant examples from your own context, like previous crises or major incidents.
Exemplify how the methodology could have helped the organization, how it is helping other organizations, and the curve of defects fixing.
Make sure to clarify the rules of the game so that everyone understands the peer review validation and the exceptional nature of the process.
Setup the temporary organization upon validation
Once an issue is raised and validated by two persons or a sponsor, you can activate the temporary organization to exclusively focus on the problem.
At that moment, follow these steps:
- Make sure the issue is clearly stated
- Confirm people available and allocate them fully
- Set the roles of coordinator and communicator
- Send out a first communication sharing the issue and stopping the flow
- Iterate through issue hypotheses, analysis and testing to solve the issue.
This last step is a repetitive set of tasks to perform until the solution is found. It can involve adding other resources or outside expertise as needed, led by the coordinator.
During that time, the communicator has the important role of communication.
Keep a continuous focus and communication
The communicator role must act as a proxy avoiding external pressure to reach the team and respond to solicitations or questions.
His role is to keep a regular communication up-to-date with:
- A clear issue statement and validated by whom
- The current customer and business impacts of the issue
- A macro status of the investigation and resolution timeline
- An explicit list of pending actions and next communication time.
In case the service is partially restored but underlying issues require more time to fix, evaluate to let back the flow of features and use problem management.
Once the issue is solved, the temporary organization has to be formally closed for the team and use the communication list to align stakeholders.
It is then time to schedule the QE Retrospective with the involved team members and most relevant stakeholders to learn and adapt from this experience.
An important task is to review quarterly the various Quality Engineering “Stop The Line” raised as it could lead to prioritizing specific themes in the team’s planning.
Quality Engineering “Stop The Line” within MAMOS
Implementing Quality Engineering requires the successful implementation of progressive practices that can scale across the organization.
Quality Engineering “Stop The Line” is no exception and must start gradually to demonstrate its results before being deployed more broadly, becoming part of the organizational culture.
Quality Engineering is not only about integrating technology in the software pipeline; it’s about injecting Quality in the entire software delivery system.
And systems failures are a golden opportunity to discover and fix underlying issues to improve even more towards resilient and scalable Quality Engineering.
Ready to “Stop The Line”?
References
Alex Novkov, Stop the Line: No Compromise on Quality. Kanbanize.