Changing the Quality Conversation: Agile Delivery for Digital Enterprise
By Myron Parks, SAFe 5, CSM®, CSPO®, ICP-ENT, ICP-CAT and Rebecca Holland
Where does quality belong in the delivery pipeline? Hint: It’s not at the end.
More than ever, business leaders need to move beyond the traditional ideas about “QA” and embrace quality as a practice that facilitates delivery. More than just a checkpoint (and a check box) at the end of a project or product pipeline, quality practitioners are essential on your team from the beginning, working closely with product management to define the goals of the workflow, the steps for how to get there, and what a great output looks like at each stage along the way. Reframing quality means the role of the practitioner can change, too — you may not need a dedicated “QA person” on your team, as long as you have experts who can fill that role. Rather than a headcount, think of quality as a percentage of hours spent on the tasks that contribute to your product or service success.
This reframing works well in the context of Agile workflows. Agile frameworks offer the tools that can help you get to a successful end product, but it’s agility that matters more than the particular toolkit. For our purposes, we define ‘agility’ as the people, teams, processes and enabling technologies that accelerate change. If this sounds a lot like the definition of DevOps or DesignOps, that’s no mistake — because it’s easy to lose sight of the fact that Agile is just a framework(s), or the strategy that we use to get to agility. In an enterprise, merely using an Agile framework such as SaFE, LeSS, or Spotify Agile is not enough. Teams still encounter organizational hurdles that are solved by the operationalization of agility across the business.
What this means: No organization just wants to be Agile. They want to increase their organizational agility to accomplish some worthwhile goal for the enterprise. For example, capturing a large client project among competitors, launching new products, or achieving a set amount of profit.
What’s the role of quality as a discipline within delivery?
To compare the new way of working with the old, let’s start with the traditional role of a quality professional or a tester: Their key processes are verification and validation (making sure things work, and making sure the team is making the right thing).
What competencies should a quality practitioner have? They are people who excel at:
Test strategy: Understanding what it takes to build an overall verification and validation plan (they have to think about the end-to-end pipeline and ensure that the entire value stream is available to meet the business need or opportunity in the market).
Test design: Understanding how to perform verification and validation activities based on the actual enabling technology or actual implementation strategy. In other words, they have to both assess the job and equip themselves with the right tools to perform it.
Agile practices: Understanding how to use Agile frameworks within delivery teams to build features to feature-complete, to satisfy the definition of done.
Automated regression: Understanding how to use enabling technology to build and maintain delivery code, accelerating delivery within the pipeline.
Reframing quality as a percentage of total capacity spent on tasks, as we said in the introduction, is part of focusing on the key capabilities of the team. It’s important to note that we’re not doing away with the quality — We’re doing away with the quality silo to ensure better cross-functionality on your team, to improve their ability to launch the final product.
Quality practitioners (and those who can fill that function) have these capabilities that contribute to the pipeline:
- Can assess the end users or personae that are the target of the initiative, and the market opportunity, like a product manager.
- Can validate features before implementation by building and testing the behaviours of the specification (through ATDD and other methods).
- Can size the impact of these changes have on the value stream, and scope the delivery work, like a scrum master. The work can include types of testing, data, environments, functional regression suites, services that need to be mocked, APIs, and documentation of legacy features needed for verification.
- Can verify code post-implementation.
- Can facilitate the transition and launch of the product from feature-complete to actual launch. This typically includes a number of regression suites and collaboration with the product owner to ensure specifications, and any requirements to go live, including release strategy, production smoke testing, regulatory certification, etc.
With these skills, it’s easy to see how a quality practitioner can create a roadmap for the end-to-end delivery pipeline. Your quality practitioners can plan and direct the activities of your team because they have a deep understanding of a) Delivery strategy, and what the needs are before go-to-market; and b) All the roles on the team and their functions.
Understanding team roles
Because of this deep understanding, we’d like to make the case for rethinking QA or quality practitioners as Delivery Practitioners. They have the most comprehensive understanding of the roles within the team and tasks that each are responsible for. The roles might include a Solutions Architect, Developers, DevOps Practitioners, Product Managers, and/or Business Analysts. The delivery practitioner understands that defining the output and tasks needed to achieve that output is a way of forming a problem for the entire team to solve.
In a nutshell, they know:
The key things each person does
What the team needs to do in order to launch
In this case, when working on a delivery strategy, the team is trying to solve the following problem: How might we create an end-to-end delivery pipeline that enables an “Always Be Ready to Launch” client service model?
Once the team agrees on the goal, each role comes up with a strategy to accomplish it, as follows:
Quality Practitioner: Always knows what to do before the product is ready-to-launch.
Developer: If the tools don’t already exist, they know how they can build them.
Solution Architect: Oversees the creation of elegant software systems that scale delivery for the client.
DevOps: Facilitates the work of all parties “so that all of the work can happen”, thinking beyond tooling and architecture to processes, people and teamwork.
Product Managers: Knows how to capture the market opportunity, owns the vision and decision-making for success.
Working together on a team with a unified goal accelerates the overall delivery strategy in a meaningful way, while ensuring that the right product is delivered to compete or lead the market. A key aspect of every delivery strategy, the team must have a clear understanding of what is necessary to launch, particularly the needs between feature-complete code and the point that it is launched as a customer-facing product.
4 Considerations for Clarity
When you create a product or project team as a delivery practitioner, consider the following to inform your decision-making:
1. The value stream for each key persona, customer or vertical for your business
2. The systems, applications and features that enable that value
3. The minimum certification needs of each value stream, so each business unit has the necessary information for launch
4. Verification and validation of any marginal features involved in the launch, understanding the scope of the product in case any features are dropped last-minute
Agile delivery in phases
In our following framework, there are two phases of Agile delivery: Development from spec to feature complete (or commit code), and Delivery from feature complete to product launch (this is where the delivery practice really shines, as we’ve explained).
You may be wondering why there are separate phases between development and delivery. It’s important to note that there isn’t a specific amount of time allocated to any activity. Mature organizations with continuous delivery to production still perform these phases. However, the delivery team are typically building the enabling technology, and the product team are launching to production. The feature-complete state at the end of a sprint is the key milestone that separates these phases.
There are a number of activities and capabilities as part of the delivery phase. As an example, we’ve added one of the capabilities we perform on projects to shift validation and verification earlier in the life of the product, as well as regular practices that are done during delivery to build feature and delivery code.
To help conceptualize this split further, think of it this way: When Apple builds a laptop, they’re not building for its ultimate use case. In the current circumstances, that might be a teacher giving a lecture to a class remotely, or a live webinar for the Agile community. Apple builds the tool only. There must be the engagement of the learning institution to leverage that enabling technology for a sequence of learning activities.
However, we need to clearly understand the value stream before we implement a change to our value-delivering system. If Apple changes the keyboard, for example, they must ensure that the end users will still find the product appropriate or fit for use (such as teaching a class), post-launch.
The case for an evolved quality practice
A practice that focuses on delivery strategy is a key advantage. It emphasizes the cross-functional nature of delivery, which the most competitive firms are starting to master. Quality is a key discipline and set of capabilities within a strong delivery strategy. We can use this approach to create an environment where everyone contributes to delivering amazing products, while doing exciting and challenging work, aligning all roles and disciplines on the end goal, and launching value to the market. This is the goal of many Ops practices, but if you’re reading this as a practitioner in a technology company, you know that Ops can create unintended silos that are counterproductive to the stated goals. Working together as a delivery team, without prioritizing some practices over others, makes everyone successful.
A delivery strategy understands delivery code, associated with the delivery strategy, and includes the efforts of every role on the team. Delivery code and delivery work should be a part of every sprint. The teams need those activities and must-haves in the roadmap of the product. Working together in this way, you can deliver key features to the market with ownership and accountability for the end result.
