Quality in Agile: Whose Role is it Anyways?

If your Agile Transformation treats quality as an afterthought, you’re not alone. 

We often hear our customers say they want to become more agile in their approach to delivering solutions. They want development to release value at the end of each sprint, and they want their business stakeholders to have a seat at the table. But what about quality? Without quality solutions, you’re bound to run into challenges you wish you could have seen sooner, and with the right strategy, you can ensure that quality has a seat at the table from the inception of your transition into Agile ways of working. 

Let's take a deeper look into how quality fits in Agile:

What does the Scrum Guide say?

In the Scrum Guide, and Scrum in general, there are three main components, which consist of roles, artifacts, and ceremonies. When you dig deeper into the roles, they describe what they call the ‘Development Team’, or Dev Team for short.  They define this as a team of cross-functional individuals with no titles and no sub-teams (like testing).  They recognize that individual development team members might have specialized skills and areas of focus, but most people run with the notion that everyone must be cross-trained. 

What does SAFe (Scaled Agile) say?

SAFe takes a more straightforward approach, complementing itself to the hierarchy of large organizations by saying that they are cross-functional (as a team), self-organizing entities that can plan, do, check, and adjust (PDCA).  They only have two roles prescribed, which are the Scrum Master and Product Owner.  The assumption is that the ‘team’ is made up of those cross-functional abilities it takes to deliver value. 

What we see and hear clients doing

This is where we see quality get left in the dust because they’re not always organizationally equipped to handle the focus a team would require to continuously test user stories and features prior to the time-boxed sprint ending, so what we see more times than not is what I refer to as a ‘Wagile’ or scrum-fall approach.  All of the development work gets done in a sprint, only to be carried over so that testing and validation can be completed by the quality team prior to deployment. 

Sometimes, in very large organizations, all of the stories and feature development gets completed with the last sprint reserved for verification and validation (also known as the ‘hardening sprint’).  Or if you’re in a Scaled Agile (SAFe) environment, you might be using your Innovation & Planning Iteration (IP).  But who wants to sacrifice an opportunity to be innovative with the urgency of having to focus on testing and bug fixes before going back into Program Increment (PI) Planning. 

4 Steps to Prepare your Strategy for Agile Transformations

In the above about what we’re hearing and seeing, there is an inference that the quality organizations we normally work with are immature when it comes to Quality Engineering practices.  It’s not to say that they don’t possess the skills and people necessary, they just haven’t been educated or coached to think about how they can leverage cutting edge software and new approaches to incrementally addressing how quality is leveraged in an organization.  I often find myself in conversations with architects and product managers who want this ability, but don’t know how to get there.  Quality Engineering practices can appear aspirational at the surface if you come at it from the approach of trying to boil the ocean before you boil a pot of water. 

This is why I try to bestow these tips and techniques (adopted from SAFe and Agile principles)

1. Establish Nonfunctional Requirements

Also referred to as the ‘ilities’ are things like: 

• Security
• Reliability
• Performance
• Maintainability
• Scalability and
• Usability
• Safety
• Documentation
• Compliance
• Capacity

Nonfunctional Requirements will help drive developers to ensure that they are meeting the acceptance criteria applied to all features and user stories being developed in the backlog.  Failure to meet any of them can result in unsatisfied requirements imposed by regulatory or standards organizations or even worse, legal issues (ie. data privacy) 

2. Establish Architectural Runway

Establishing an architectural runway for incremental progress of Quality Engineering capabilities.  When I refer to the architectural runway, what I really mean is the existing code, components, and technical infrastructure needed to implement near-term features and user stories.  It also: 

• Includes a roadmap of enablers that will help the agile teams and programs 
  • deploy more frequently, 
  • with higher quality, 
  • with more predictability, and not to mention, 
  • the ability to do this in a low-risk manner.  
  • Setting up a test infrastructure can help with this.  
• The goal is to continually invest in your architecture and it is extended by the use of enablers.  (automated testing could be an enabler on the runway) 
• This can be prioritized through your Agile Program Management Office or your Agile Coach who will help balance trade-offs with your product management team so that the value of this enablement will resonate with their business needs as well.  
• Some enablers will fix existing problems, while others will provide a foundation used to support future functionality.

3. Embrace Innovation and Hackathons 

This is an area that we could talk volumes about.  Some organizations foster and welcome these opportunities to think outside of the box, while others shy away and focus on their near term goals and objectives.  Both can be argued, but for the organizations that do incubate this innovation, culture seem to reap the most benefit.  Deming famously quoted that “Everyone is already doing their best, the problems are with the system… Only management can change the system.”  So, how does a leader or manager go about doing that? 

• Embracing an innovation culture (There’s no such thing as a bad idea) 
• Gemba (Go See) walks 
• Conducting innovation/hackathon workshops 
• Encouraging Proof of Concepts & Proof of Values 

4. Lead the Cultural Change 

I left the most challenging topic for last because culture is the largest challenge you’ll face in any transformation, period.  If you don’t anchor new approaches in your organization, then any new ideas will be chewed up and spit out without hesitation.  This is why we feel that Organizational Change Management is what will make or break your transformation.  Some of the key areas to focus on when transforming your organization include:

• Leadership support - you have to walk and talk it. 
• Training / educating everyone
  • Foundational and Role based 
  • Hackathons and time for innovation 
• Transparency 
  • Role changes
  • Ways of working
  • Communities of Practice 
  • Messaging
• Connecting silos within the organization
  • Bringing teams together to reduce hand-offs and accelerate value delivery
• Common Tooling
• Value-driven decisions validated by real data 
  • Becoming more empirical and resisting the urge to use vanity metrics 
• Quality Organization Participation
  • This one is HUGE 
  • Invite them to the table as soon as possible
  • Look at SOP’s and regulatory guidelines to address early and when needed 
  • Support upfront and as features are ready vs ongoing engagement

Have you integrated quality into your Agile Transformation strategy? 

BCforward has supported many organizations - from beginning their Agile Transformations to providing a fresh set of eyes to challenge them and think in new ways. Our Agile, DevOps, and OCM consultants partner with organizations to help plan and execute your strategy to deliver valuable solutions and outcomes aligned to your strategic objectives.

If you would like to learn more about how Quality can enhance your Agile projects, we’d love to chat.

Chad Manley is an experienced Lean-Agile transformation consultant, holding the SPC, RTE, ICC-ACC, CSM, PSM1 and PMP certifications. At BCforward, Chad is the Enterprise Agile Coach and works with large corporations to help them gain fluency in scaling agile, understanding the DevOPs mindset, and moving from a project management to Agile product management.