How architectural quality fertilizes customer satisfaction 

Architectional quality as crucial part for sustainable customer satisfaction

Does your team have a deep understanding on how to leverage quality requirements? Does your product backlog consist of infrastructure and quality requirements? Is your team aware of what drives customer satisfaction? 

 

If we did catch you with one of these questions, you should read our article in which we cross the bridge between technology and organizational development.  

 

We hope that the article itself helps to rethink your status quo and helps you personally on your learning journey. Let’s grow – your Agile Gardeners, Dominik & Michael 

 

Intro 

Part of our mission as Agile Gardeners is crossing the bridge between technology and organizational development to nutrisionize sustainable systems. Typically, we encounter three different scenarios when working in teams with digital products: 

• Scenario 1: The teams underestimate the leverage of quality requirements.  

• Scenario 2: The team’s backlog lacks room for infrastructure and system quality requirements although the team knows that they are poorly implemented. 

• Scenario 3: The team is not aware of what drives customer satisfaction. 

In this blog post, we address all three statements, evaluate the consequences, and propose approaches on how to deal with them. 

Scenario 1: The teams underestimate the leverage of quality requirements

  

Before we tackle this statement, we first want to understand: What is quality? 

Gerald M. Weinberg coined the statement  “Quality is value to some person.”  

Consequently, we have to collaborate with our stakeholders closely to understand what quality means to them.  

 

Product backlogs should therefore both include functional and non-functional requirements. In that context, we recommend enriching functional requirements with acceptance criteria with respect to quality. Value creation blossoms if both parts are well-balanced. 

 

Quality requirements only indicate but don’t guarantee the system’s ability to provide value and generate customer satisfaction. The ISO 25010 describes a quality model that collects some necessary system attributes. 

Software Product Quality: Taken from ISO 25010 Quality Model 

As agile Gardeners, we train teams, product owners, and all stakeholders in that context. As an important step, we create transparency of the quality requirements and foster communication about these properties with all stakeholders while empowering the development team. In the end, understanding technical debt as a huge source of opportunity costs is the key to growing the whole team in taking responsibility for quality requirements.  

Experienced behaviour: Changing Quality comes with exponential cost over maturity

Scenario 2: The team’s backlog lacks room for infrastructure and the system’s quality requirements

We often encounter product teams that have a strong focus on functional roadmaps with nearly no focus on infrastructure and architectural topics. This behavior often becomes visible in reflecting the number(absence?) of technical tickets in the team backlog.  

As Agile coaches, we see the potential conflict between building lightweight MVPs and building our features based on fundamental architectural quality requirements. As Agile Gardeners, we resolve this conflict by emphasizing and visualizing this conflict to the team and all stakeholders. Continuous backlog refinement of functional and quality requirements is crucial.  

This potential conflict is already deconstructed by agile principles written down in the agile manifesto itself: 

• “Our highest priority is to satisfy the customer through early and continuous delivery 
• of valuable software.” – this tells us to foster MVP approaches. 
• “Continuous attention to technical excellence and good design enhances agility.” -tells us not to forget technical improvements on the go. 
• “Welcome changing requirements, even late in development.”- Tells us that the whole team should also be open to basic technical improvements on the go.  

Therefore, we emphasize that agility needs continuous room for changing and reflecting software architectures. 

 

Modern software architecture approaches point out to start with quality requirements as they form fundamental, hardly revertible decisions about architectural design. This is why the arc42 template suggests describing quality goals at the start of any software architecture. Exploring them at an early stage and discovering possible trade-offs between competing quality requirements is key for a successful system design. Quality scenarios help to derive quality drivers by describing various usage, change, and failure scenarios.  

 

A quality tree breaks down the key quality drivers and assigns metrics for measuring them – because what you measure is what you get, and when you don’t measure anything, you won’t get to anything. Comparing these metrics against their target values will help your team prioritize the backlog and ensure that you always match up with your quality requirements.

Quality Tree Arc 42 https://docs.arc42.org/tips/10-2/

As agile Gardeners, we love to balance the named potential conflict. We moderate workshops to create quality trees and work out quality goals.  

We train development teams and Product Owners to work out the properties regularly on their own. We welcome to see building software architecture as an incremental approach to explore the best possible solution. On the journey, teams learn more about the required key properties. Therefore, we encourage the team to welcome the incremental development of the architecture. Product Owners need to master balancing technical topics besides functional improvements. 

In that context, the key is to manage expectations and consensus with all stakeholders. Building transparency as a first step and then integrating the topic in the Scrum learning loop of the team is the foundation of success.

Scenario 3: The team is not aware of what drives customer satisfaction. 

Go to your team and simply ask “What does the customer think about your product”. With a good chance, you will get some inconsistent or meaningless answer because too many teams don’t work customer-centrically. This may be an issue due to the misleading focus on product delivery when applying Scrum because it does not say anything about how to integrate product discovery and aim for a high user experience.  
An evaluation of the customer satisfaction drivers combined with a quality tree can assist with product backlog prioritization of features and quality requirements. Here you have an example of the Kano satisfaction model: 

Model: Taken from Val Yonchev 2018 

https://openpracticelibrary.com/practice/kano-model/ 

KANO Step 1: Question Survey template

KANO Question Survey	I like it	I expect it/ Must-be	I am neutral	I can tolerate it	I dislike it
Functional
How would you feel if the product had ...?  if the app has 2-factor authentication, how do you feel?
How would you feel if there was more of ...?
Dysfunctional
How would you feel if the product did not have ...?  e.g., if the app does not have 2-factor authorization, how do you feel?
How would you feel if there was less of ...?

Own image; KANO survey template 

 

KANO Step 2: KANO Evaluation & KANO evaluation example "2-Factor Authorization"

In terms of KANO, functionality here refers to the degree of fulfillment of customer requirements (be it functional or non-functional (aka quality) requirements). 

In Xu, Q et al (2009), Must-be/Must-be and Tolerate/Tolerate are marked as “Indifferent”, although it seems contradictory to us. We, therefore, marked it as “Questionable”.  

The Q-Categorization (Questionable) controls for an incorrect understanding or a reckless answering process. 

KANO Step 3: Categorization of requirements into KANO satisfaction drivers

Own table: KANO scores for continuous categorization 

 

By calculating the average for each functional and dysfunctional question form, you get the y (functional) and x (dysfunctional) coordinates for localizing the feature in the matrix. This continuous analysis (based on average) is superior to the discrete analysis (based on mode) because less information is lost in the visualization.

Own diagram: Example for KANO continuous requirement categorization 

 

In the discrete analysis, you assign the feature category to the one with the highest consensus (mode) among the responses1 – this approach is problematic if you have high variance in your answers.

Own diagram: Example for KANO discrete requirement categorization 

 As agile Gardeners, we love to grow customer orientation in Teams. Besides personal coaching and working out things like why the team works together, there are multiple methods that foster progress. We use retrospectives to deep dive into topics like Value Proposition Canvas, Business Model Canvas, Vision Statements, Personas,  

Further, we encourage building formats that integrate real customer feedback like demos, interviews, or data reports based on the interaction of the client with the product. A deep dive into the KANO model can both leverage product Owners to the next level for prioritization and also mature a whole development team, when it understands, that everyone is needed to work out relevant requirements.  

 

Summary 

Imagine living in a team that solved all these three challenges. You would work in a context where teams value the high importance of quality requirements and therefore have a clear understanding of them communicated properly to all stakeholders. The same teams would give infrastructure topics and quality requirements the deserved space in backlogs. Most crucial: These teams won’t get lost in working out quality standards only, but learn to validate what drives customer satisfaction and therefore overall prioritize the customers’ good. 

 

What are your impulses to the topic? 

Which of the named methods are part of your methods? 

What inspired you and contributed to your growth? 

We are happy if you comment under the article or contact us. 

 

We learned that it’s possible to grow these teams. In our experience these teams blossom, their products become extraordinarily successful, and mostly the whole organization gets inspired by them. We hope that you enjoyed reading the article and that the impulses help your team on that journey. All the best and let’s grow,  

Agile Gardeners Dominik & Michael 

 

Bibliography 

Agile Manifesto. https://agilemanifesto.org/. Accessed 18.11.2023 

arc42 Documentation. Home | arc42 Documentation. Accessed 18.11.2023. 

ISO 25010 Quality Model. ISO 25010 (iso25000.com). Accessed 18.11.2023. 

Amy G. Application of the Kano Model in Understanding Consumer Preferences and Product Attributes in the Vacation Ownership Industry. JOJ scin. 2021; 2(4): 555592. DOI: 10.19080/JOJS.2021.01.555592 

DuMouchel, “Thoughts on graphical and continuous analysis.” Center for Quality of Management Journal 2.2 (1993) 

Fong, “Using the self-stated importance questionnaire to interpret Kano questionnaire results.”, The Center for Quality Management Journal 5.3 (1996) 

N. Kano, N. Seraku, F. Takahashi, S. Tsuji: Attractive Quality and Must-be Quality. In: Journal of the Japanese Society for Quality Control. 14(2) 1984, S. 147–156. 

Val Yonchev. Kano Model: Easily visualize and explain the impact and priority of different features.https://openpracticelibrary.com/practice/kano-model/ (2018). Accessed 18.11.2023. 

Xu, Q., Jiao, R. J., Yang, X., Helander, M., Khalid, H. M., & Opperud, A. (2009). An analytical Kano model for customer need analysis. Design studies, 30(1), 87–110.