Delivering a new application can be stressful.
The build can fail with complex messages, deployment stuck, without talking about firewalls and security issues. And problems become harder when other people must be involved.
These issues leave software engineers with a set of fears in delivering software, attracting them into their comfort zone of local development, in their safehouse.
But delaying problems only makes them worse. In software, quality and speed are directly impacted by multiple reworks discovered late in the process.
Let’s see how Minimum Release Code can help in Quality Engineering, the paradigm constraining the entire software lifecycle to deliver Quality at Speed software.
Follow the QE Unit for more Quality Engineering from the community.
What is Minimum Releasable Code?
Minimum Release Code focuses on the “working software” of the agile manifesto.
It focuses on delivering early code to tackle non-functional and integration requirements, maximizing quality and speed.
Most teams are comfortable with Minimum Viable Products (MVP) or Minimum Viable Feature (MVF), that are oriented on the product value and end users.
The practices aim to deliver results after a few sprints iteration has been completed, letting time to craft the software foundations and first code elements.
At that stage, most teams leave code in a local or first testing environment. Why going further when there is so many features to build to create a valuable product?
That’s where technical debt starts to accumulate, to be repaid at one moment.
The moment is usually when product teams want to test the application with live users. They want it now, and need to adapt features, interfaces, and interactions.
Teams that did not deliver code early will have to solve a whole set of integration issues taking days, if not weeks—requiring them to “take (quality) shortcuts to go fast”.
To the contrary, other teams that deployed the application earlier, can have refactored the integration of components, allowing them to iterate fast without compromising quality.
Why using Minimum Releasable Code in Quality Engineering?
Quality Engineering is the paradigm constraining the entire software lifecycle to continuously deliver Quality at Speed software.
Its implementation relies on a systemic approach to software delivery on the five domains of MAMOS: Methods, Architecture, Management, Organization & Skills.
Minimum Releasable Code is a methodology enabling to constrain teams to confront integration issues early, improving their capability to deliver quality and speed later on.
How does Minimum Releasable Code contribute to Quality?
Teams have the challenge to deliver functional and non-functional quality attributes for software that are even more complex, critical, and with more stakeholders.
The pressure to actually create a minimum valuable feature or product requires first to be able to iterate fast without daily issues along the software lifecycle.
That’s precisely where Minimum Release Code fits in acting as a counterforce to address integration issues early on, unlocking to deliver better quality attributes afterward.
Minimum Releasable Code contribute to Quality being:
- Results-driven in delivering working software in specific stages
- Systematic being applicable to every software implementation and tasks
- Scalable in allowing to better evolve software increments among teams.
How does Minimum Releasable Code contribute to Speed?
Speed has different time horizons: short, mid, and long-term.
Quality Engineering aims to maximize all speed horizons by ensuring that quality is equally considered early in the process, avoiding negative effects of trading quality for speed.
The practice of Minimum Releasable Code lets teams solve integration issues and technical debt in the short-term, unlocking continuous velocity up to the mid and long-term.
Minimum Releasable Code contribute to Speed with:
- Focus in reaching a state of “working software”
- Rhythm by applying the method early and systematically in tasks
- Asynchronicity in letting teams iterate with more autonomy later
- Visibility by delivering working software that is concretely deployed.
How to start with Minimum Releasable Code in QE?
The practice of Minimum Releasable Code must be gradual in the organization to show early wins and let the teams adapt to the methodology.
The following principles must be shared to align the actors:
- Focus on releasing working software
- Integration is more important than features
- Tackle the most complex problems first
- Build the minimum to iterate fast on features
- Stop when you can deploy changes without errors
The implementation stages then rely on combining change management and transition management practices alongside with the method deployment.
Here’s how to deploy Minimum Releasable Code in Quality Engineering:
- Share the vision with the team
- Identify most valuable project(s)
- Define the objectives and scope
- Iterate until reaching the releasable state
- Identify improvements & scalability points.
Share the vision with the team
Aligning your team on the need for Minimum Releasable Code is essential as the actors will have different perspectives, opinions, and habits about the subject.
Some of them would argue that it is preferable to focus first on the features, and dedicate a sprint to the deployment aspect, or variation of that proposition.
At that stage, use the arguments described in the contribution to Quality at Speed adding relevant experiences of initiatives that failed without applying the methodology.
You can then align the principles, sharing that the initiative will be first implemented on the first project to demonstrate the value and adapt the process in your organization.
Identify most valuable project(s)
Implementing new practices require to focus on initiatives that will maximize the first results you will be able to deliver.
Organizational uncertainty and risks are the maximum when starting something new, reinforcing the need to minimize your initial effort on key projects.
Select a project that is important for your organization and in complexity in order to demonstrate the added value of the methodology.
A too simple project would not reveal the value and could in fact make it more complex when starting; and failing a critical business initiative is not an option.
Define the objectives and scope
Projects are similar from far, but different from nearby.
The objectives and scope of your Minimum Releasable Code depends on your product context and technical environment.
A pure back-end product consumed through APIs and services will requires a different integration focus than a front-end consuming existing and external APIs.
Use the following questions to help you identify the scope:
- Which part of the deployment pipeline seems more complex?
- What are the most unknown deployment areas?
- Which integration parts are unclear and seem risky?
- Which new technologies are part of the product?
- What are existing standards and tooling we can use?
These questions will let you with a scope of elements to tackle iteratively until you are able to effectively deploy your code.
Iterate until reaching the releasable state
All tasks can be implemented using the other Quality Engineering methodologies such as Kanban and DoD.
Iterate through the list by the most blocking, complex, and valuable items that make progress through the effective delivery of the code.
The goal is to maintain a strong focus in incrementally delivering the identified scope, limiting at a maximum the extra complexity that can settle in.
Good practices to maintain the rhythm are to follow-up the work in daily, regular reviews, and demos, also helping the team to navigate through issues they can face.
The implementation will lead you to reach a first state of Minimum Releasable Code where you solved the main integration issues, unlocking to iterate faster on features.
But that’s not the end in Quality Engineering.
Identify improvements & scalability points.
We usually collect the fruits of yesterday’s effort, not of today.
That’s the same in Quality Engineering: we can benefit from more Quality and Speed if we previously invested and planned to create such opportunities.
The different issues tackled during the Minimum Releasable Code are valuable in identifying bottlenecks that can be turned into future opportunities.
The best way to support such a process is to use the methodology of QE Notes to take notes during the entire process on pain-points, ideas of improvements.
Then at the end of the process, perform a consolidation exercise to identify which items should be kept documented and in the backlog for future iterations.
Staying ahead is required in Quality Engineering.
Minimum Release Code within Quality Engineering
The effective implementation of Minimum Releasable Code across the organization enables to shorten first cycles of iterations and to accelerate them afterward.
The methodology is pivotal in the Quality Engineering framework, performed at the implementation stage and before to reach an actual minimum viable product.
This practice is also scalable with the maturity of your organization. Release trains can be added, or QE Platform Foundations can be enriched with the QE Notes.
Accelerating the digital reinvention of organizations through software is not only about the features—minimal code changes must be rapidly deployed for fast iterations.
It’s about Quality Engineering.
References
Minimum Viable Product (MVP), Agile Alliance.
Minimum Marketable Feature (MMF), Tech Target.
Agile Manifesto, Agilemanifesto.org.