Focus on quality – key to customer success
Our organizations are like living organisms, constantly evolving to adapt to the environment. Like it or not, our business environments today are more chaotic and disruptive than ever experienced before.
So, if our organization is regarded as a living organism, our IT landscape must be the nervous systems of this organism. You can ́t have business agility without technical agility. The whole system needs to work smoothly together to be able to deliver on customer demands.
SAFe constantly reminds us of the importance of innovating our products & services and being able to scale fast when a business opportunity occurs. This is still a true challenge for most organizations.
Product management´s ability to build the right things and the ability to empower stream-aligned teams to build things right is key to customer satisfaction. Delivering product value faster and more frequently with a continuous focus on quality is more important than ever to ensure customer success.
Teams should build quality into the product and also into the product development process. The traditional quality checks and controls can be downsized since those often tend to slow down the development pace.
Basic agile quality practices
Some basic agile quality practices are highlighted in SAFe 6.0, embracing both business agility and team & technical agility:
Shift learning left – this practice is built on the approach of mastering shorter planning and execution cycles, ensuring fast feedback and through that having a quicker learning process. If we reveal a problem sooner, we can take actions with less impact. This is an important part of building our organization’s team & technical agility. Shift left origins from the DevOps community encouraging us to build DevOps pipelines where we move testing, quality, and performance evaluation earlier in the development process, often before any code is written.
But we can also adapt this mindset to our organization’s business agility. If we spend enough time on refining our backlogs to identify proper MVP ́s and MMF ́s (minimum viable products and minimum marketable feature) we qualify to get earlier feedback from the customer and then learn fast to adjust our product and services accordingly.
Pairing and Peer review – this practice is very much about collaboration, utilizing multiple viewpoints on a problem but also supporting knowledge sharing within a team. The classical set up of a pairing session to improve your technical agility is pairing two programmers – one is writing code and one is navigating and reviewing. Another pairing set up is two testers reviewing current testing strategies or a programmer and a tester having a dialogue on how to optimize the testing process.
A pairing set up to align business and technical agility could be the product owner and the tester writing stories together. Or the product owner pairing with a programmer, most efficient when requirements are complex or vague. It could also be two product managers analyzing business opportunities within a certain business domain. Only your fantasy sets the limits for the collaboration that boosts your value creation.
Collective ownership and T-shaped skills – this is very much related to the team’s collective intelligence as well as the culture of helping each other out – to stay goal focused, not task focused. Firstly, it is about responsibility – if everybody feels ownership of the running code there is a good base for built-in quality. Any person in the team should be able to take the initiative to refactor code, improve design, fix errors, and add new functionality.
In a way roles in a stream-aligned team overlaps, a tester must know about certain developer principles and a developer must know the rudiments of testing. A tester is often very skilled at writing both business and technical requirements. A developer should not only unit test but also do other forms of controls and reviews before shipping the code. A developer should work close to operation to be able to deploy and utilize operational metrics and monitoring.
Think business and technical agility here as well. How can we build this into the team and avoid dependencies on certain individuals. This more flexible way of working very much contributes to the team’s built-in quality mindset. To proactively focus on T-shaped skills in the team will not only enable flow and reduce bottlenecks it will also facilitate the realignment of a team.
Artifact standards and definition of done – Clarifying standards and quality attributes for a product is part of describing its characteristics and a true prerequisite to ensure that a work item is complete and correct. If you can’t describe it, you can’t change it! To describe the product’s criteria both from the business angle and the technical angle is most relevant, even when you do agile development. But you do this in smaller cycles and teams should always focus on creating well-designed solutions that support current and future business needs.
It could be a business artefact that needs to be clarified by product management, such as clarifying customer interaction, product behaviour, a business rule or a master data concept that affects the solution design. To continuously ensure that the solution is aligned to an agreed system intent and an intentional architecture including important technical artefacts sets the base for built-in quality. Technical standards could be set for APIs, container configurations, interactions between microservices or be based on any important quality attribute described as non-functional requirements (such as security, usability or reliability).
Defining acceptance criteria at an early stage mitigates implementation risk and should be used to clarify the expectations of a feature among different stakeholders of the solution, such as product owners, system architects, testers, operations, and other stakeholders. Describing Definition of Done of a work item helps teams, trains and the organization to agree on expected deliveries.
Workflow automation – handoffs and several manual steps in the development pipeline should be avoided to prevent lack of quality generated by human mistakes. Automation of workflows also reduces execution costs and increases adherence to standards. Test automation of repetitive and complex testing tasks as well as release automation for shipping code are two typical examples of workflow that ought to be automated as part of boosting the technical agility.
When it comes to business agility the implementation of a modern QMS (quality management system) that utilizes digital tools to create organizational flexibility is a way of automating the quality management process and build the solution and compliance incrementally. A lean-agile QMS provides support for regulatory requirements and helps to achieve flexibility and transparency.
I hope this blog post gives you some more input around the highlighted quality practices in SAFe 6.0.
Never underestimate the time needed for the team’s continuous learning around built-in quality (training, reflection, measures) to be able to fully master the above practices and by that achieving maximum efficiency and optimal product quality.
Read more what SAFe 6.0 says about built-in quality in this article: https://scaledagileframework.com/built-In-quality/
